Header Bidding Explained

The Problem Header Bidding Solved

Before header bidding, publishers used a waterfall model: offer inventory to demand partners in a ranked sequence, accepting the first bid that met the floor price. The problem: the first bidder in the sequence had an advantage regardless of actual value, and publishers systematically undermonetised their inventory because higher bids from lower-priority partners were never seen.

Header bidding solves this by running a simultaneous auction across all demand partners before the ad server is called. Every eligible buyer sees the impression and submits their best bid. The highest bid wins — regardless of where the demand source sits in any hierarchy.

How Header Bidding Works

The header bidding wrapper (typically Prebid.js) sits in the publisher's page header and fires bid requests to multiple SSPs and demand partners simultaneously when a page loads. Partners respond with bids within a defined timeout (typically 300-500ms). The winning bid enters the publisher's ad server as a line item, where it competes with direct-sold campaigns and other programmatic demand.

Server-side header bidding moves this auction off the browser and onto a server, reducing page latency — at the cost of some bid signal quality and potentially lower match rates.

Implications for Buyers

Header bidding increased competition for premium inventory, which generally increased CPMs for publishers. For buyers, the implication is that low bids that might have won in a waterfall are less likely to win in a header bidding auction with 10+ competing partners.

Bid shading (bidding below the clearing price in first-price auctions) became important as programmatic shifted to first-price auctions alongside header bidding adoption. DSPs that bid-shade intelligently reduce spend waste.

Client-Side, Server-Side, and the Trade You Are Making

Header bidding comes in two architectures and the choice is a straight trade between revenue and page speed.

Client-side runs the auction in the visitor's browser. Every demand partner gets a genuine look, cookie matching works because the call comes from the browser itself, and match rates stay high. The cost is latency that scales with the number of partners, paid by the visitor. Each additional partner adds requests to a page that is also trying to render.

Server-side moves the auction to a server. One call leaves the browser, latency stops scaling with partner count, and you can add demand without punishing the page. The cost is cookie matching — the server is a third party to both the browser and the bidder, so match rates fall, and a bidder that cannot identify the user bids lower or not at all.

Most publishers at scale run both: high-value partners client-side where match rates matter, the long tail server-side where they do not. That hybrid is the standard answer, not a compromise nobody chose.

What It Does Not Fix

Header bidding solves a sequencing problem: it lets demand sources compete simultaneously rather than in a waterfall. It does not solve any of the following, and expecting it to is the usual source of disappointment.

It does not create demand. If three partners want your inventory, adding a fourth auction mechanism does not make it four. Revenue lift comes from competition that was previously suppressed by the waterfall, and that lift is finite.

It does not fix inventory quality. Below-the-fold placements with poor viewability bid poorly in a unified auction for the same reason they bid poorly in a waterfall.

It does not reduce fees — it relocates them. Every additional intermediary in the chain takes a margin, and a publisher who adds partners without auditing the chain can increase gross revenue and reduce net.

And it adds an operational burden that is permanent. Timeouts, price floors and partner performance need ongoing attention. A configuration that was correct a year ago is a configuration nobody has looked at.

Sources

What each claim on this page rests on. Entries are typed so you can see which are primary.