What is Header Bidding?
Header bidding is the practice of offering impression opportunities to multiple partners simultaneously before a publisher makes a call to their ad server. It started as a means to solve the inherent inefficiencies of the ad server waterfall tiering/priority system and increase competition, ultimately resulting in higher publisher revenue.
Header bidding auctions occur outside the standard ad server and, depending on the implementation, enable exchanges and supply-side platforms (SSPs) to compete for inventory on even ground with direct-sold campaigns.
The Ad Server Waterfall and the Rise of Header Bidding
Prior to the widespread adoption of header bidding, many publishers used waterfalls to organize their inventory sales into tiers. Usually this involved prioritizing direct sold inventory in the top tier, and sorting various demand sources such as SSPs and exchanges into lower tiers based on expected returns. When a bid was returned that met the publisher’s price floor, that bid would win, which resulted in the waterfall ending and the tiers below not being called. See below for an example:
- Page loads, player loads and ad server offers impression opportunity to Tier 1 partners.
- Tier 1 partners reject opportunity or fail to return an impression to the ad server.
- Ad server offers impression opportunity to Tier 2 partners.
- A bid that meets the price floor is made and returned to the ad server.
- The waterfall ends without calling Tier 3, and the ad server plays the winning bidder’s ad.
In a world driven by direct-sold inventory, waterfalls make sense; put your primary partners in the top tier, and organize everything else based on expected returns. The rise of programmatic, however, upended the waterfall.
The biggest problem with the tiering system is that only competing a few partners at once, i.e. competing partners tier by tier, suppresses competition which, in turn, reduces impression prices. Take the scenario above, three tiers with three partners. It could have possibly looked like this:
Partner 1 | Partner 2 | Partner 3 | |
Tier 1 Bids | Fulfilled | Ineligible due to competitive separation | Ineligible due to targeting requirements |
Tier 2 Bids | $22.13 | $13.47 | $17.00 |
Tier 3 Bids (Uncalled) | $22.74 | $7.00 | $32.37 |
In this example, even though Tier 3 would have out-bid Tier 2, those partners were never called and the publisher missed out on the extra revenue as a result.
Prior to the rise of programmatic, tiering inefficiencies were less severe since partners were organized based on expected yield, and real-time bidding (RTB) marketplaces were typically seen as a way to monetize remnant inventory which typically commanded a lower price. However, CPMs began to rise as data-enabled targeting increased the value of the audience in the minds of advertisers. As use of programmatic continued to grow, it became increasingly likely that publishers were leaving money on the table by not competing all their demand partners as once.
Another factor that contributed to the rise of header bidding was Google’s Dynamic Allocation feature. If a publisher used Google Ad Manager (FKA DoubleClick for Publishers), as their primary ad server and had Dynamic Allocation enabled, Google’s proprietary ad exchange could pre-empt the waterfall, including direct-sold inventory, as long as it offered a price higher than the expected returns from direct or programmatic deals. In other words, Google would take the CPM of direct-sold deals (while adjusting based on pacing, i.e. if delivery was lagging it would temporarily increase CPM and vice versa) and average CPM of exchanges, and, if it outbid them, Google could unilaterally swoop in and snag the impression before the waterfall started.
Unsurprisingly, since Google was the ad server and the exchange, it had plenty of information to determine how much it was willing to pay for each bid. Since Dynamic Allocation allowed Google to win before the auction occurred, there was no way to tell if publishers’ were actually maximizing yield. Since Google only had to beat minimums for direct deals and average bids from exchanges, Google could lowball impressions that would’ve otherwise commanded above average bids from exchange partners.
In light of these sorts of scenarios, many publishers and ad tech vendors felt Dynamic Allocation stacked the deck in Google’s favor. Since then, Google launched Exchange Bidding and opened up Dynamic Allocation to other exchanges. However, that wasn’t enough to stop header bidding’s momentum as it spread through the marketplace.
What are the Benefits of Header Bidding?
Kevin Hunt, SpotX’s SVP of Global Marketing, summarizes the benefits by saying that header bidding “allows media owners to attract more bids on their ad inventory and allows media buyers to access inventory that is typically unavailable to them through programmatic infrastructure. It’s a win-win.”
In a standard waterfall scenario, supply-side platforms and exchanges are traditionally relegated to the bottom of the waterfall or close to it. This meant that the inventory these platforms/companies were receiving was typically of lower value since higher value inventory was likely sold before these platforms even received a bid request. However, since header bidding auctions take place outside of the ad server, header bidding opens up opportunities for these demand sources to bid on and win more premium inventory – including inventory that would otherwise have gone to direct-sold deals. As such, header bidding allows publishers to increase demand and maximize yield by increasing competition for their inventory.
How Does Header Bidding Work in Display vs. Video
While header bidding emerged as a key trend for display in 2015, it took a bit longer for it to spread into video. Given the inherent complexities associated with video, that was to be expected. It’s those complexities that dictate how header bidding for video is different from display.
That said, as you can see below, the overall workflow of header bidding in display and video are very similar:

Display Header Bidding:
|
Video Header Bidding:
|
However, what happens on the back end of video header bidding is decidedly different than display. To begin with, there is no header in a video player. While the header on a page in display advertising is what houses the code that enables partners to transact programmatically, the header doesn’t play that role in video. Instead, typically the video player houses code and acts as an intermediary between the publisher’s website and demand sources.
In addition to the backend mechanics being different, there is another notable area of difference, and concern, for video header bidding vs. display: latency.
Maintaining fast, efficient trading can already be arduous even with a simpler format like display. Video introduces a completely new set of variables to consider, increasing complexity and difficulty in managing efficiency. For example, video ad creatives can easily be 1,000 times larger than display creatives, which makes it suboptimal to manage the process in the same way.
Further, oftentimes the video header bidding auction doesn’t occur until the user clicks the play button. This means the auction occurs while the video player is loading, not while the header loads. As such, while display has the opportunity to execute its header bidding process while the page loads, video doesn’t have that luxury.
Latency is further compounded by the fact that with header bidding, upward of ten concurrent transactions can occur, in real time, after the user clicks the play button. This comes in addition to the fact that those transactions are competing with the video content that is also downloading. All these concurrent processes slow down video initiation and may ultimately result in a poor user experience. In some cases, this can even result in page abandonment, causing the publisher to lose the opportunity all together. This latency makes it all the more important for publishers to work with partners they trust who are dedicated to mutual success and creating a positive user experience.
Server-Side vs. Client-Side Header Bidding
Since latency issues are exacerbated in video header bidding, a standard, client-side implementation that might work for display simply isn’t optimal for video. See below for a typical client-side header bidding workflow:

- After the page loads, the video player and header bidder container (HBC) code load.
- The HBC includes each header bidding partners’ (HBPs) code, each of which fires the opportunity to their respective servers.
- HBPs send the opportunity to their demand partners.
- Upon receiving responses, HBPs conduct server-side auctions, select winners and send the winning ads back to the HBC.
- The HBC mediates among the respective submissions from each HBP, selects the winner and instructs the ad server on which line item to return.
- The ad server determines the final line item to serve and sends the corresponding line item to the player, which plays the ad.
The crux of the issue is that client-side implementations require all of the heavy lifting to be done from a user’s browser. Publishers working with multiple header bidding partners need to send a call from the browser to each partner individually, and then wait for their responses before the page can finish loading. While a client-side implementation may suffice for display bidding, larger creative sizes compounded with the lack of a header in video players make these issues unacceptable for video header bidding.
In a server-side header bidding scenario, publishers rely on a lightweight execution of JavaScript to bring the programmatic auction server-side between integrated supply- and demand-side platforms (DSPs). As a result, only one call is made to a header bidding partner mediator, which then executes the rest of the auctions outside of the user’s browser client. When the auctions are finished, only the winning bid is returned for execution. This method results in a number of benefits, these include:
- More control over latency, which is a serious concern for video header bidding.
- Moving the complexity from the client to the server. This allows website owners to shift the responsibility of managing complex code from themselves to their header bidding provider. Managing that complex code is part of the domain expertise that a header bidding provider offers, alleviating the burden from the website owner.
- Mitigating some of the risk of user abandonment and/or user adoption of an ad blocker. When header bidding is executed client side, all the calls out to demand partners are made client-side, making them visible to these users. If a website owner has ten header bidding partners integrated, that user is going to see ten calls being made. In a recent HubSpot survey, 39% of respondents that had installed an ad blocker cited doing so because ads created security concerns. By moving the calls server-side, users get a cleaner experience.
Here is how the server-side model works:

- Page loads, player loads, the header bidder mediator’s (HBM) code loads and fires the opportunity to its server.
- HBM sends the opportunity to other header bidder partners’ servers as well as to its own demand partners.
- Each HBP sends the opportunity to their demand partners.
- Upon receiving responses, HBPs and the mediator each conduct a server side auction, select a winner and send the winning ad back to the HBM. The HBM mediates the responses from each of the HBPs’ auctions and its own, on its server.
- HBM sends the winning ad back to its code on page.
- HBM’s code on page instructs the ad server on which line item to return.
- The ad server reviews the line items, including the one submitted by the HBM. The ad server selects the final line item based on eligibility and delivery of contractually obligated impressions (e.g. direct-sold deals) and sends it to the player, which plays the ad.
Does Video Header Bidding Make Sense for You?
While header bidding is a useful tool in a publisher’s arsenal, it comes at the potential cost of negatively impacting the user experience. Fortunately, there are other options. In the past decade, a number of modern ad servers have been developed for the programmatic world where competing demand from all sources simultaneously is a given, not an afterthought. This idea of embedding real-time bidding functionality straight into the ad server is known as holistic ad serving.
Working with an ad server that automatically competes all demand sources – including direct sold and programmatic – solves the problem header bidding was intended to fix. Since all demand is competed simultaneously anyway, there is no waterfall effect. Tiers can be effectively separated by business priorities and reliability instead of expected (and diminishing) yield.
Of course, it’s easy to say “just change your ad server!” Executionally, it can be a heavy lift. Maybe you have contractual obligations or technological limitations that make it impossible to switch ad servers in the near future. If that’s the case, header bidding can be a great option.
Header Bidding Best Practices
As with many things in ad tech, header bidding can quickly become a headache if implemented improperly or ineffectively. Here are a few tips to keep in mind when setting up your header bidding strategy:
- Be selective about your header bidding partners. It’s easy to fall into the “more is more” trap. While it’s true that from a bidding economics standpoint having more partners is beneficial as it leads to more bids and higher yield, every additional header bidding partner poses an increased risk of latency. Make sure to balance yield with user experience.
- Use a wrapper if you are working with several header bidding partners. Used to manage header bidding partners, wrappers organize buyers and set rules for programmatic auctions, minimizing the added code and complexity introduced with each new header bidding partner. Using a wrapper ensures that all partners have their bid requests triggered at the same time and include a universal timeout setting to manage how long the browser waits for bidders to respond.
- Compete direct and programmatic campaigns. Header bidding is just one piece of the monetization puzzle. Haphazardly adding partners onto your page isn’t necessarily going to drive yield. To make the most of header bidding, ensure that priority levels in other platforms are set in a way that drives the most competition. Competing direct and programmatic campaigns is often the best way to maximize yield.
Impact of Header Bidding
The arrival of header bidding completely changed the ad server auction dynamic. Header bidding gave publishers much more control over their inventory sales process, and as it continues to evolve, it continues to shape the ad tech industry as a whole.
One of the largest ramifications of header bidding on the ad tech industry is its effect on infrastructure costs which disproportionately affect buyers. When participating in header auctions, SSPs see a huge influx of ad requests. As they send the subsequent bid requests to their DSP partners DSPs often see the same impression opportunity multiple times, each offered by different SSPs. While SSPs may see around twice as many impressions, DSPs will see multitudes more. These bid requests stack up and wear down servers over time, and there’s nothing to show for it unless you win the auction.
The second major impact of header bidding on the industry is the beginning shift toward first-price auctions instead of the second-price auctions we commonly see today outside of header bidding scenarios. Within header bidding when an SSP receives an ad request, it fires off bid requests to all its demand partners and holds its own auction. The winning bid of the SSP’s auction is then reduced to the second highest and submitted to the ad server auction. Because of this, even though a bidder may have had the highest original bid, it could still lose to a lower bid in the final auction as a result of its initial reduction in the SSP auction.

Due to the aforementioned rising infrastructure costs and the greater allocation of premium inventory in header bidding, it’s worth everyone’s while to win in these auctions. First-price auctions, where bids are actually reflective of what buyers and advertisers are willing to pay, greatly even the playing field for buyers and drive additional yield for publishers.
Header Bidding with SpotX
As a holistic, modern ad serving platform, SpotX has options. Below, we’ve detailed the processes involved with using SpotX as your primary ad server with and without the SpotX Header Bidding Wrapper in use. Take a look and decide which solution is best for you.

No wrapper:
|
With wrapper:
|
Further, SpotX has setup a one-click integration with JW Player. If you currently use or are interested in using JW Player as your online video player and would like to explore header bidding, this integration is completely seamless. Publishers who take advantage of this integration do not need to make any changes on their side; header bidding auctions can start being run and monetized at the click of a button.
If you’re interested in learning more about using SpotX as your primary ad server or our header bidding wrapper, reach out to us. For even more information on the topic, check out our header bidding page.