Header bidding explained for publishers

Header bidding changed the way a digital publication sells its ad inventory: instead of offering each slot to one buyer after another, it offers it to all of them at once. Here is the problem it came to solve, how it works inside, and what it takes to put it in place.

Before header bidding: the waterfall

For years, a digital publication sold its advertising in order of preference. The ad server —the software that decides which ad appears in each slot, Google Ad Manager being the most widespread— kept an ordered list of buyers. The slot was offered first to the one at the top. If that buyer did not want it, or did not reach the minimum price set, it moved to the second. And so on down the list until someone bought. That ordered list is what the industry calls the waterfall.

The order was not decided impression by impression, but on historical averages. The publisher —the owner of the site selling its ad space— put the network that had paid the most on average at the top, and the ones that paid less below.

Why the waterfall wasted money

An average says nothing about one specific impression. The network sitting in third place might have paid, for that particular reader at that particular moment, considerably more than the one in first. Nobody ever found out: the first buyer accepted and the sale ended there. The publisher got a price that was good enough, not the best one available.

• The waterfall compares historical averages, not real bids for the impression being served right now.
• The calls are sequential: every step down the list adds waiting time before the ad appears.
• Buyers at the bottom of the list only ever saw what the ones above had turned down.

The unified auction

Header bidding reverses the approach. Instead of asking buyers one after another, it asks all of them at the same time, before the ad server decides anything. The name comes from where the code was originally placed: in the header of the HTML, so that it would run as the page started loading.

The result is a unified auction: every connected buyer bids on the same impression, at the same time and under the same conditions. The winning bid enters the ad server as a concrete price and competes there with whatever the publication has sold directly.

The waterfall asks who usually pays the most. The unified auction asks who pays the most for this impression.

How the auction unfolds

The page starts loading and the header bidding code fires a request to each demand partner with the details of the slot: size, position, page address, and whatever audience signals the reader's consent allows it to send. Each partner replies with a bid or does not reply at all. There is a time limit set by the publisher; anyone who does not answer within it is left out of that auction.

Once the wait is over, the code keeps the highest bid and hands it to the ad server as one more piece of data. The server compares it with its other sources of demand and serves the winning ad. The partners doing the bidding are usually SSPs (supply-side platforms), platforms on the supply side that pool the demand of many advertisers and set it to compete for the publication's inventory.

Client-side header bidding

In the client-side variant, that whole auction happens in the reader's browser. Their device opens a connection to each partner, waits for the answers and does the maths. The advantage is that the browser cookies live there, which is what lets buyers recognise the user and bid with more information. On top of that, the publisher sees every bid in their own logs: transparency is complete.

The cost is that the work is done by the reader's device. Every partner added is another simultaneous connection, and browsers limit how many can be open at once. Past a certain number of partners, adding one more stops paying off.

Server-side header bidding

In the server-side variant, the browser makes a single call to an intermediate server. That server queries all the partners and returns only the winner. The page loads far less code and opens far fewer connections, so considerably more buyers can be connected without punishing performance.

Two things are lost in exchange. User identification gets worse, because browser cookies do not travel the same way between different domains and the matching between identifiers is imperfect. And you have to trust a third party that acts as referee and sees every bid before you do. That is why many publications end up with a mixed setup: the partners that contribute most stay on the client side and the rest move to the server.

What Prebid is

Prebid is the open source project that became the de facto standard for header bidding. It is not a company that buys inventory: it is the infrastructure that organises the auction. Prebid.js is the library installed on the page that coordinates the bidding on the client side; Prebid Server does the equivalent on the server side. It is maintained by Prebid.org, a non-profit organisation supported by companies in the industry.

Its practical value is that each demand partner writes an adapter for Prebid, and the publisher switches it on from the configuration instead of integrating each one separately. Because it is open, anyone can read the code and check how the auction is resolved.

What it costs in speed

Header bidding is not free in performance terms. The auction happens while the page loads, and it has to be waited for. Wait too long and the reader sees empty slots or a page that takes a while to settle. Wait too little and the slow partners are left out, losing bids that would have been good.

• The timeout is the main control. It is set by looking at how many partners manage to answer within it.
• The script is loaded asynchronously, so that it does not block the article content from appearing.
• Partners get pruned: one that almost never wins still costs every reader loading time.
• Slots further down the page are auctioned when the reader approaches them, not at the start.

What it takes to implement it

The first requirement is an ad server of your own, normally Google Ad Manager, with the pricing structure configured to receive the bids. A publication monetising only with AdSense cannot add header bidding without taking that step first. Then you need demand partners willing to integrate, and traffic volume weighs here: SSPs do not open an account for just any site.

And then there is maintenance, which is where this either pays off or does not. Timeouts have to be reviewed, partners brought in and taken out, and the share of slots that go unfilled watched. Many publications delegate that operation to a monetisation partner that provides the infrastructure and runs it. In house or outsourced, the question worth settling before starting is the same: who adjusts this when it stops working.