Header Bidding 101

Both buyers and sellers of digital inventory have long lamented the “waterfalls” publishers relied on to fill impressions not sold by their direct sales teams. In recent years header bidding entered the ecosystem, and it has since gone mainstream. Today, about 20% of the Alexa 2000 sites have implemented header bidding.

GumGum has embraced header bidding because it offers tremendous benefits to our publisher partners, and it allows us to compete for impressions on behalf of our clients that may out of reach in a waterfall set up.

If you’ve heard a lot about header bidding but aren’t quite sure what it’s about, read on! This blog post is a 101 of this critically important development.

What is Header Bidding?

The easiest way to explain header bidding is that it’s a way for publishers to create super auctions in their visitors’ browsers. It allows all of a publisher’s demand sources – RTB buyers, ad networks, direct campaigns – to compete simultaneously for available impressions. Any demand partner (e.g. GumGum) that’s compliant with the publisher’s header-bidding wrapper can compete for an impression.

How does that differ from waterfalls, and more importantly, why is it better than waterfalls?

With a waterfall, all the decisioning occurs in the publisher’s ad servers: Once an impression becomes available, the ad server typically checks to see if it’s needed for a direct campaign. If not, it searches for another buyer, but the tools it has to to do so are quite blunt. Generally speaking, the ad server requests a bid from a real-time buyer and compares it to the cost of the top ad network in its waterfall. If the RTB bid is higher, then that buyer wins the impression. If the network’s price is higher, then the bid goes to the network. At which point nightmare of ad network defaults and waterfalling begins.

Ad networks are free to reject an impression and send it back to the ad server (i.e. “default”). The ad server must then find another buyer, which is the next ad network in the waterfall, and if that network defaults, the ad server sends it to the next one, and so on. The result is a lot of latency and revenue loss if the user gets tired of waiting for the page to load and clicks away. Worse, with each hop from one ad network to the next, up to 10% of impressions are lost due to discrepancies. That’s a lot of revenue lost.

Generally speaking (there are exceptions of course!), due to technical reasons, once an ad server goes down the ad-network waterfall it typically must stay there. In other words, after a network defaults it can’t go back to the RTB and offer it up again.

And here’s why the loss of revenue is compounded even more: It may very well be that the initial RTB bid is higher than what the first network may actually be willing to pay, unbeknownst to the ad server. You see, ad servers often require publishers to enter a fixed CPM for each ad network in order to serve traffic them. That cost is a placeholder, and typically represents that average CPM paid by that network. But in reality, ad networks pay different rates for impressions, depending on the campaigns they have active at any given moment. So let’s say the average CPM Network A pays is $5.00 and that’s the price entered into the ad server. Now let’s say an impression becomes available, and the ad server receives an RTB bid for $5.25. The ad server will award the impression to the RTB buyer because it believes that it is $.25 higher than what Network A is willing to pay. But what if Network A is acquiring inventory for retargeting campaign for a premium auto manufacturer and is willing to pay a $15 CPM? This isn’t an unlikely scenario, in fact it’s quite common.

Spread out over billions impressions per month it’s easy to see how the waterfall costs the publishers a lot of money. Header bidding, on the other hand, adds significant efficiency the publisher’s monetization efforts, because it allows the publisher to assess the price each buyer is willing to pay simultaneously, and award it to the one who is willing to pay the most.

It also greatly reduces page load latency and discrepancies, so fewer users click away from the page and squander the opportunity to monetize altogether.

I can see how Header Bidding benefits publishers, but how does it benefit buyers when it will cost them more money?

Header bidding offers a critical benefit to buyers by allowing them to compete for impressions that are likely to be off limits to them in a waterfall. For instance, GumGum has the ability to compete for super premium impressions that, with a waterfall, are likely to be reserved for a direct campaign. And even if those impressions are available to third-party demand sources, for reasons explained above, we may be prevented from competing for them, even if we are willing to pay more.

Are there downsides to Header Bidding?

Anytime there is advertising there will be latency issues, and header bidding is no exception. It takes time to host an auction, select a buyer and serve the ad. That said, the latency that results from header bidding is just a fraction of that caused by a waterfall.

By way of comparison, some studies show that 78% of header bidding transactions are under 200 milliseconds, while just 12% of waterfall transactions 2. Why? Because everyone is bidding simultaneously.

You mentioned that Header Bidding is possible as long as the publisher has a wrapper, what's that?

A wrapper is a piece of code that holds the tags for all of a publisher’s header bidding demand partners. The wrapper makes it easy for publishers to add partners on an ongoing basis. Wrappers also include important technical and operational functions, such as AdOpsInsider explains, “Typical and expected features of a wrapper include asynchronous container to ensure all partners have their bid requests triggered at the same time, a universal timeout setting to manage how long the browser waits for bidders to respond, and partner specific “adaptors” that allow the wrapper to translate all bids into a common key value for the ad server.” 3

Buyers must be in compliance with the wrappers implemented by the publisher in order to compete in their auctions.

Who creates Header Bidding wrappers?

It used to be that publishers created their own wrappers but now there are many open source systems for header bidding wrappers developed by tech companies like AppNexus and OpenX. Managing a wrapper on an ongoing basis was a burden for publishers, which is why the tech companies stepped in, creating wrappers that streamline the process.4 As AppNexus explains: “The wrapper is a single piece of code that holds the tags for all of a publisher’s header bidding demand partners, making it easy for publishers to add partners according to their needs and manage the integrations on an ongoing basis.”5

Which Header Bidding does GumGum use?

GumGum has built a pre-bid wrapper that is compliant with prebid.js, a free header bidding wrapper that was developed and incubated by AppNexus. This means we can deliver demand to -- i.e. compete in super auctions for -- any publisher that uses prebid.js. Click here for more information on prebid.js. Which types of inventory does header bidding support? Header bidding can be used to compete for any inventory that resides on a web page, through to date it is mostly used for display ad units. That’s changing, however, as publishers get comfortable with header bidding. Some predict that digital video, and even in-app ad units, will see header bidding in 2018.6

-------------------------------------------------

1 https://dev.serverbid.com/v1.0/docs/hbix-sept-2017

2 https://martechtoday.com/martech-landscape-what-is-header-bidding-and-why-should-publishers-care-157065

3 http://www.adopsinsider.com/header-bidding/guide-header-bidding-wrappers/

4 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/

5 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/

6 https://performancein.com/news/2017/10/17/header-bidding-next-evolution/

‍