Adtech aims at streamlining the deals between the advertisers and publishers. Despite the advances in the industry, the digital advertising market still lacks coordination. Thus, publishers have to juggle various platforms and monetization sources to get the most out of their ad inventory.
Header bidding platforms emerged as a solution to combat this discontinuity. It provides a more effective mechanism for publishers to monetize their ad inventory. In the past years, header-bidding got prominence and massive adoption. Yet, the inner-workings of the system still cause confusion.
- What is header bidding?
- Header bidding vs waterfall vs RTB
- How does header bidding work?
- Client-side header bidding process
- Client-side vs. server-side header bidding
- Header bidding pros
- Higher yields
- Higher fill rates
- Cookie matching
- Control and transparency
- Header bidding cons
- Latency issues
- Limited ad requests
- Compatibility
- Wrapping up
What is header bidding?
Header bidding is an automated auction technology, allowing publishers to feature their inventory on many DSPs and receive bids from multiple advertisers simultaneously. It is an auction, where all DSPs have equal access to bidding, in contrast to waterfalling and open RTB where they enter the auction in turns.
Header bidding removes the informational asymmetry between publisher and advertiser about the traffic value. It allows publishers to get a fair demand-based price for their ad space.
Owners of Admixer.Network white-label solutions can now use a full potential of header bidding technology, bringing more earnings to publishers and increasing the overall efficiency of programmatic buying.
Header bidding vs waterfall vs RTB
Before the introduction of the header bidding model, publishers sold their inventory almost through waterfall auctions and open RTB.
Waterfalling, also known as daisy-chaining or waterfall tags, is a method of selling publishers assets in a sequential manner, invoking one demand source at a time. In this scenario, the publisher establishes preferred order for ad networks and advertisers, and sets a price floor, a minimum acceptable amount for particular ad placement.
Publisher offers the inventory sequentially to the demand partners in the established order, according to their historical yield. As soon as a specific advertiser meets the price floor, the impression is sold.
In open RTB, publishers use similar model, but daisy-chain ad exchange and SSP auctions instead. Fundamentally, publishers run a succession of real-time auctions until all of their ad inventory is bought. Open RTB utilizes the second-price auction model. The winning bidder pays the price offered by the second-highest bidder plus $0.01.
We’ve previously explained in detail why header bidding has become a preferred model among publishers.
How does header bidding work?
Header bidding executes through the string of JavaScript code embedded into the header of publishers’ websites. The header is an HTML element invisible for the reader; it usually stores navigation links, authorship information, etc.
The string of code connects the website to various sources interested in buying the ad inventory. With every page load, demand sources can bid on each impression on that page.
This procedure increases the transparency allowing supply-side platforms or SSPs (such as Admixer.SSP) to know which demand platforms are bidding, and the value of their bids, maximizing the CPM.
Client-side header bidding process
- A user enters the publisher’s website.
- A JavaScript wrapper in the header of the webpage activates and forwards a user request to multiple SSPs, and demand sources (DSPs and Ad Exchanges).
- SSPs conduct auction with their demand sources, determine winning bids and return them to the page.
- Demand sources return their bids to the page.
- The JavaScript wrapper page conducts a header auction between the received bids in the browser and send the winning bid to the ad server.
- The ad server serves the creative of the winning bid on the page.
The user sees the ad of the highest bidder. Everything happens within milliseconds.
Client-side vs. server-side header bidding
The process described above is an example of client-side header bidding, while there is also another variety of this technology with server-side implementation.
Server-side header bidding follows a similar procedure as the client-side, with one notable exception. Instead of sending the ad requests directly to the ad tech platform, server-side header bidding forwards the ad request to a separate server. Only after that, the server sends requests to the ad exchanges. After the server receives the bid, it sends it back to the browser.
The server-side model resolves the main problem with header bidding, page latency, because bidding occurs in a dedicated server instead of the browser.
Yet, this model lacks transparency. Since the bidding happens in the server, publishers may have trouble assessing the results of the auction. Moreover, since the bidding is removed from the browser, cookies can be lost, making it hard for advertisers to identify users.
Header bidding pros
Higher yields
Instead of relying on the previous data to set the price floor, the header-bidding allows seeing how much advertisers are willing to pay for the impression in advance before the placement of the ad. The publisher determines how much the ad impression is worth to a multitude of advertisers at once. The highest-bidding demand source ultimately wins the impressions.
Liz Tokareva, VP Client Services at SmartyAds, puts it this way:
“Header bidding is a hot topic in programmatic since it allows publishers to increase control over their inventory and trades, and therefore generate more revenue. With header bidding, publishers can find the best buyer for each impression, monetize their content, and provide it to the readers almost or absolutely for free.
This shift in inventory management provides publishers with hefty benefits, but it also requires quick and informed decisions. Integrated end-to-end solutions are crucial for making them, especially when it comes to reporting and analytics capabilities.”
Higher fill rates
Besides the higher yields from the ad inventory, header bidding also ensures the higher fill rates, where no impressions are left unattended. The publisher is aware if the SSP will deliver the impressions in full or not. Header bidding eliminates the fill risk associated with sequential bidding on multiple levels by reducing it to the unified auction where SSP fills all the provided inventory. With header bidding platforms like Admixer.HB+, there is no manual work of setting up daisy-chains or waterfalls on the publisher’s side.
Cookie matching
Since the bidding process takes place in the browser, SSP and DSP can sync their cookies, enabling advertisers to identify the user on the website of the publisher.
The ability to trace the user history let advertiser run targeted campaigns and retargeting ads, having a better grip on the audience. At the same time, publishers collect more revenue from the in-demand audiences.
Control and transparency
The string of the JavaScript in the header works as a management system for a publisher.
With the help of this header bidding wrapper, publishers can effortlessly set timeframe for the bids, as well as remove and add new demand partners.
Nevertheless, changing the wrapper is not a menial task and requires expertise in this complex set up. However, the header bidding wrapper or tag grant greater transparency for the publisher in terms of pricing and control over demand sources.
Header bidding cons
Latency issues
Header bidding was designed to alleviate the inefficiency of the waterfall auctions, most notably passback. However, the implementation of header bidding is not flawless.
Header bidding adds more scripts to the header of the page, increasing page-load time, damaging the user experience, and resulting in fewer displayed impressions.
Also, because header bidding entails numerous connections with servers and platforms, it causes a slower internet connection – an additional negative factor for user experience.
Limited ad requests
The number of requests that the browser can make in one turn is limited, meaning that the header bidding wrapper also can send a limited amount of ad requests. Due to this fact, the number of demand partners that can bid on the ad space is also restricted.
Compatibility
Since the header bidding works through the browser, it needs to be backward-compatible with different browsers and versions, which can create additional roadblocks. Certain browsers may have a low priority for external pixels. As a result, they may block them completely, rendering header-bidding auctions inefficient.
Wrapping up
By implementing header bidding, publishers receive more bids from a more diverse pool of advertisers. This results in higher aggregate demand that drives up the price for the ad placement and the revenue for publishers.
Yet, the header wrapper setup is more complicated than a simple ad tag, so you’ll need to choose a tech partner wisely.
Header bidding is becoming a new standard of the industry, while open RTB remains a viable strategy for publishers who want to prioritize a specific pool of advertisers. If you want to get the best of both worlds, Admixer offers a hybrid model that integrates header bidding and open RTB.
If you’re considering the implementation of header bidding, contact Elena Podshuvejt, CPO at Admixer: epodshuvejt@admixer.net