Header Bidding

Better Monetisation with Header Bidding

Increase ad revenue by simultaneously collecting multiple bids from a variety of demand sources each time a new impression is available

Header Bidding

A Simpler Guide to The Header Bidding Technology

Despite the rising adoption of the technology, header bidding still remains somewhere between a buzzword and an enigma to people not directly involved in its implementation.

In this post, we explain how it works in three parts: How header bidding technology emerged, how it works including its pros and cons, and what lies ahead in the future.

Here’s a comprehensive header bidding guide.

The Origins of Header Bidding

Medium and large publishers typically offer their inventory to multiple networks to increase their overall revenue — they do this by offering their impressions to the network that pays the most, pushing the unsold impressions to the next network in the value chain, and so on — this is called the publisher waterfall or daisy chaining.

There can be direct deals before the waterfall starts and the remnant inventory towards the end can be used to serve house ads or ads from GDN (Google Display Network).

waterfall method

Sounds like a great setup, but there are problems:

  • High ad latency: All this shuffling around of inventory across multiple networks means that inefficiency is pretty much built within the design of publisher waterfall.
  • Revenue leakage: It doesn’t matter how you set up the waterfall, there’s no guarantee that a network higher up the chain will necessarily pay higher for every impression.
  • Resource intensive: Setting up a waterfall that works requires a competent team, time, effort, and continuous experimentation, otherwise, you might as well not even bother.

So while the waterfall worked, people were already working on other ideas and systems that could eventually replace it, one such idea came from Brian O’Kelley and his team at AppNexus back in 2009 — this solution, initially designed to help break the monopoly of GDN and AdX on the market, came to be known as header bidding or pre-bidding.

What is Header Bidding and How Does it Work

Instead of the piecemeal manner in which impressions are sold in a waterfall setup, Header Bidding allows multiple demand partners to bid for impressions simultaneously in real-time — this saves time and ensures that every impression is always sold to the highest bidder.

Header bidding is a much cleaner and better tech integration between revenue partners, ad tech companies and publishers compared to what’s going on currently.

— Jonathan Mendez, CEO, Yieldbot

One crucial difference between the waterfall setup and header bidding is that while the former happens server-side, most of the header bidding action happens within the user’s browser — it’s the browser that collects all the bids and then makes a request call to the ad server that made the highest bid. It should be evident by now that the reason it’s called “header bidding” is because the code that makes it works resides within the header of the publisher’s website.

Want to know more about Header Bidding? Click here.

The entire idea of this system is to eliminate the need for pushing inventory back and forth, which is inefficient and wasteful.

— Shani Higgins, CEO, Technorati

header bidding

There are many advantages to implementing header bidding:

  • Higher revenue: The auction of each impression is conducted more efficiently and adding one additional demand partner can increase the overall revenue by up to 10%.
  • Faster ad serving: Everything moves faster in header bidding when compared to a waterfall structure and there’s usually a cut-off time for the entire process.
  • More transparency: You have advanced confirmation that a bid has been placed on the impression along with the exact price of each bid.
  • Lower management: Compared to a waterfall structure, there are less variables to set, tweak, and manage on an ongoing basis.

All that said, header bidding is not perfect either:

  • Difficult setup: The initial setup of header bidding will require a higher level of technical know-how as there are no graphical interfaces available to make the process simpler.
  • Slower page load: Since header bidding works from within the user’s browser, page latency increases and the user has to wait longer for the page to load, this is a major dealbreaker for many publishers not willing to sacrifice their user experience.
  • Yield risk: At some point, the market may adapt and the average price of bids placed by buyers may see a correction, counteracting any potential revenue gains.

What’s Next?

Ad tech companies and developers understand that while header bidding is a great solution in principle, it has a fundamental latency problem stemming from it being a client-side technology, i.e., calls are taking place in the browser and slowing the page down.

While speculations have been made about the evolution and alternative uses for header bidding, the most concrete shift seems to be the move towards server-side header bidding. The idea is to just move the heavy lifting to a remote server instead of the user’s browser.

In contrast to browser-side solutions, server-side containers sit on the provider’s server. A piece of code on the user’s page calls the server, after which the process is no longer dependent on the internet connection between the user and each partner, removing the burden from the browser. Calling each demand partner from the server using a lightning quick connection reduces latency and speeds up page load times, significantly improving the user experience.

Just as with client-side solutions, server-side containers reduce operational complexity, making it easy to bring in new partners, or pause or remove existing partners. But they also reduce technical complexity by leveraging OpenRTB standards that are already well-known and understood throughout the industry. This also makes server-side solutions more reliable, as OpenRTB has a proven track record.

— Andrew Buckman, MD EMEA, OpenX

Further details about how exactly this works are still somewhat sketchy as server-side technology specific to this context is still being actively developed by Google, Amazon, Media.net, and many other SSPs; cooperation is difficult due to intense competition in the ad tech space, case in point, AppNexus’ point-blank refusal to work with Google on any project.

Nevertheless, this seems to be the direction in which header bidding is headed. A positive step forward in evolution of Header Bidding was when Brian O’Kelley of AppNexus announced (at 2017 IAB Annual Leadership Meet) that Index Exchange, Pubmatic, and AppNexus will now mutually support their header connections to ensure unbiased and easy access to partners, without vendor-lock in or creation of “walled gardens”.

But since this industry is so fragmented, it might take a few years before server-to-server becomes the norm. After all, it took header bidding 8 years to get where it has. As of now, it’s a race to who develops the technology first and rolls it out faster with better partnerships and integrations.

AdPushup’s Header Bidding Solution

Merely deploying header bidding in your ad stack isn’t enough. Consistently optimizing it with technical improvements is the need of the hour. This is what AdPushup’s header bidding solution does. Through our multiple optimization features using data science and machine learning, we help publishers maximize their yield. 

With our header bidding solution, you get: 

  • Automatic demand partner selection according to optimum requirements
  • Smart timeout management
  • Freedom to bring your own demand
  • Bid monitoring and discrepancy resolution 

Read more about our product capability: Header Bidding