Header bidding. Every publisher has heard about it, brags about it or hates it. The one thing that every person will agree on is it’s complexity. As a pub, how many times have you heard “we bring full transparency to your tech stack”, “we offer the highest yielding header bidding solution”, or “we maximize every impression”. It’s tough to verify these bold statements with each header bidding solution being chalked full of punchy marketing slogans. But how many people actually understand it? How can you determine which ad networks deliver on their promises? Below we take a look at what’s really going on behind the scenes.

Life Before Header Bidding

Long before header bidding came to be, publishers were forced to live and die by the “waterfall”. The waterfall is aptly named for it’s step by step descent down the list of demand sources in search of the next best CPM. Whatever doesn’t get “filled” simply defaults with the next demand partners’ ads, trickling down to the last one with the lowest CPM offer. With this downward descent comes an inherent race to the bottom as you bounce downward from one exchange to the next in search of the next highest paying customer.  If you’re in digital publishing, you can recall the challenge felt during waterfall construction and modification.

A Quick Header Bidding History

The true genesis of header bidding is tough to trace but the CEO of Appnexus lays claim as the sole inventor all the way back in 2009. Others will tell you that a small group of publisher side ad-tech platforms were the creators. While we don’t know exactly who is behind the earliest rendition we do know that they were seeking better yield. They knew that if they could make calls to each exchange in the waterfall all at the same time they would ultimately earn the most revenue. They did this by allowing outsiders in to play with Google’s DFP, and fairly at that.

ELI5 (Explain It Like I’m 5)

Imagine yourself sitting at an auction and the auctioneer rattles off the current bid and openly accepts new bids. Each bidder argues back and forth as the seller waits in anticipation.The process takes some time and makes for a long day.

This is exactly how the first version of header bidding worked. The header script made calls out to exchanges one by one, returned bids and compared those bids with all of the others. This process led to a lot of latency, or delay, creating a less than amazing user experience.

Now imagine this, you’re at an auction and the auctioneer accepts all of the bids at the exact same time. The bids are reviewed and the highest bidder wins.

This refined process is called parallel calling. The header script – the code that runs header bidding – collects bids from every exchange at the same time. This drastically cuts down on latency issues and subsequently enhances user experience.

To improve the user experience even further publishers are beginning to move to server-side header bidding. Server-side bidding conducts the auction away from the browser, putting the task of bidding onto the supply-side SSPs.  This further evolution is helping publishers chase away any possible latency and user experience problems.

The Pros and Cons of Header Bidding

Like every single thing ever created, header bidding has a host of pros and cons.

The pros of header bidding:

• Flatten your waterfall – managing the order in which partners gain access to inventory is no longer necessary because each demand partner declares how they value the impression up front
• Better yield management – tag based integrations create inefficiency because they force an average rate to compete with the impression level bids of AdX (if the publisher is on DFP). This setup leaves money on the table with both the SSP and AdX. Consider this: if the SSP is bidding anywhere between $0.50 and $5, but averaging $2, then AdX will win every impression over $2.00, even if the SSP would have paid far more, because there’s no way to know what the SSP would have paid. Similarly, any impression where AdX would pay less than $2 but the SSP would not fill at all, or would fill far below their average is lost revenue as well. Header bidding solves this inefficiency.
• Reduce discrepancies – discrepancies arise through latency, and multi-partner waterfalls are inherently latent.

The cons:

• Operational setup – Header tag integrations require a much more involved set-up process. It can sometimes be technical too, and require you to hire someone with greater technical skills. However the benefit is that once setup, publishers likely won’t need to touch those line items in the future like they do to manage the waterfall with a tag setup.
• Longer page load – publishers need to watch their page load times like a hawk because even fractional improvements in page load result in better user engagement. Header tag integrations therefore require some partnership with IT resources to both implement and manage.
• Yield risk  (compression of profits) – the biggest risk we see for publishers is that it could decrease bids from buyers (yes, believe it). That flattening the waterfall results in greater bid density and demand liquidity, leading to greater revenue and ultimate nirvana? Yes, the risk is that buyers identify which pre-bid partner allows them to buy for the lowest price and move their demand there. In other words, buyers optimize to the platforms of lowest bid density. Remember, header tag integrations don’t allow the publisher to run their own second price auction across all platforms; they just let the publisher pick the best result out of many second price auctions.

Are you using header bidding? Are you waiting to get paid? Find out if you qualify for accelerated ad revenue payments.