The Benefits of Header Bidding

Of course the simplest explanation of waterfall vs. header bidding is that in a waterfall, bids are called sequentially, and with header bidding, they are called in a single, unified auction.

To me, one of the main differences lies in real-time price bidding.

With a waterfall set up, a publisher would have to set up multiple tags, from multiple demand partners, in separate line items, with different rates, with different targeting, and with different passback tags. Once all that setup was done, those partners would then have to manage those tags and update rates and targeting and change the passbacks. It was a lot of work and required a full ad ops team, or for one VERY busy person.

In comes header bidding. Header bidding enables a one-time setup by the publisher, giving them real-time price competition by multiple demand partners in a unified auction. With the introduction of header bidding, really what changed with the waterfall setup was the ability for your demand partners to be able to put forth (and compete on) the price that they feel that the inventory is worth.

With a waterfall setup, all prices in the ad server are static and out of date. With the introduction of header bidding and the ability to have competition on penny increments, it changed who the big players were in the market and it made the biggest demand partner work harder and pay more to win an impression.

I think the biggest benefit is real time pricing, but there are other benefits as well. A waterfall setup takes a lot of time and hands-on management to look into discrepancies between the ad server and the tags the publisher trafficked. It is also a lot of management of passback tags when the demand partners don’t fill.

Header bidding removes these issues. There are still some discrepancy checks, but for the most part header bidding discrepancies are low, less than 5%.

Additionally, with a waterfall approach, the multiple tags led to increased latency on the site or app. Header bidding’s simultaneous call improves latency for most publishers and helps alleviate the time that tags take to call back and forth.

The biggest advantage of header bidding is being able to see all of the available inventory for the publisher, not just what is being sent to them in the waterfall. With a header bidder implementation, demand partners get what we call a “first look” which gives them access to see the most valuable users that their advertisers are looking for. So I think the main benefit is the opening up of inventory that they did not have access to in the past.

There are certain header bidding containers out there that are run by specific SSPs, let’s say, and those header bidders kind of give preference to some demand partners in the stack.

Prebid is an open source solution, which makes it easy for publishers to trust the actual code itself since it’s not biased towards a specific demand partner.

So when implementing a header bidder like Prebid, the publisher has access to hundreds if not thousands of various adapters that are out there in demand sources that can be implemented on page or in app.

Additionally, since Prebid is a single source of code, publishers can pass specific parameters to all demand partners (like floor price or supply chain). This is useful information for buyers, and helps them submit the best possible price.

eCPMs also tend to be higher with a header bidding solution, because demand partners are able to submit bids based on a real-time price of what they’re willing to pay, and bids are called together, not sequentially, which means the highest of all the bids can win.

So I think the main reason is the up-front cost, honestly. For app inventory, the only way you can really implement a header bidding solution is through a server implementation, and servers cost money. In order to have a Prebid Server connection, you need to either host your own server and have the auction run within that server, or pay for a third-party hosted server. Both of these options require an investment (though self-hosted servers are more costly, since they require overhead, hosting costs, and maintenance).

We’ve seen a lot of third parties come out recently on hosting their own third-party solutions for Prebid, and as a result, we’re starting to see more header bidding adoption.

I think in addition to the cost, Prebid server did not have as much initial adoption from the demand partners and therefore didn’t have many adapters built out. That has since changed. As adoption improves with demand partners, publisher adoption is increasing, as well. I think we will see a lot more adoption of Prebid server in 2022, especially as the many revenue-boosting benefits of the header bidding solution can outweigh the cost to implement.

Like all SSP is out in the market, we have our own adapter for both client and service side prebid headers. We are also connected to other third-party header bidding solutions. I won’t name any names but there are other ones out there in the market that we do have connections to as well. So if you were trying to get into a header bidding implementation we can help you with your Prebid or those other third parties.

We also have our own header bidding solution, called Unified Bidding, which is built into our SDK. We make it simple for publishers to switch from a waterfall to a header bidding solution, gaining much more access to quality, global demand.