Header Bidding Explained
The Problem It Replaced: Waterfalls
Before header bidding, publishers sold programmatic inventory through a waterfall: the ad server would offer an impression to demand sources sequentially, in a pre-set priority order, moving to the next source only if the current one declined or bid below a set price floor. This meant lower-priority demand sources never got a real shot at competing on price — they only saw what higher-priority sources had already passed on, and the publisher had no way to run a true simultaneous auction across all demand.
Header bidding (also called 'advance bidding' or 'pre-bidding') fixes this by having a JavaScript wrapper, loaded in the page's <head>, send simultaneous real-time bid requests to multiple demand partners *before* the ad server call happens, then passing the highest bid into the ad server as a competing line item against the publisher's own direct-sold and programmatic guaranteed deals.
How the Auction Actually Runs
On page load, the header bidding wrapper (most commonly Prebid.js, an open-source project, though publishers also run proprietary wrappers) fires simultaneous bid requests to every configured SSP/exchange partner, each with a short timeout (typically 500ms-1500ms). As responses come back, the wrapper collects all valid bids, then passes the winning bid's price as a targeting key-value into the publisher's primary ad server (commonly Google Ad Manager) via its standard ad call. GAM then runs its own unified auction, comparing that header bidding price against direct-sold line items and Google's own Open Bidding/AdX demand, and the single highest-value line item wins the slot.
pbjs.setConfig({
priceGranularity: "dense",
bidderTimeout: 1200,
});
pbjs.addAdUnits([
{
code: "div-leaderboard-top",
mediaTypes: {
banner: { sizes: [[728, 90], [970, 250]] },
},
bids: [
{ bidder: "ix", params: { siteId: "123456", size: [728, 90] } },
{ bidder: "openx", params: { unit: "987654321", delDomain: "publisher-d.openx.net" } },
{ bidder: "pubmatic", params: { publisherId: "55555", adSlot: "728x90@top" } },
],
},
]);
pbjs.requestBids({
bidsBackHandler: function (bidResponses) {
pbjs.setTargetingForGPTAsync();
googletag.pubads().refresh();
},
});Client-Side vs. Server-Side Header Bidding
Waterfall vs. Header Bidding
| Dimension | Waterfall | Header Bidding |
|---|---|---|
| Demand competition | Sequential, priority-ordered | Simultaneous, true auction |
| Price discovery | Poor — lower sources never see true market price | Strong — all sources bid against real market conditions |
| Latency impact | Lower, but only because fewer sources get called | Higher, mitigated by timeouts and server-side variants |
| Publisher revenue impact | Generally lower yield | Documented yield increases, often double-digit percentage |
Costs of Header Bidding You Shouldn't Ignore
The yield gains come with real costs: added page latency from extra network requests (directly hurting Core Web Vitals if timeouts aren't tightly managed), increased ad-ops complexity (floor pricing, line-item priority, and key-value mapping all need careful configuration to avoid header bidding demand cannibalizing direct-sold deals), and a meaningful rise in duplicate/redundant bid requests across the broader ecosystem, which is a direct driver of the supply path optimization problem buyers now have to manage on the demand side.
Too Many Bidders Hurts More Than It Helps
What's Next?
Header bidding set the stage for private marketplaces and programmatic guaranteed deals, which let publishers reserve premium inventory for trusted buyers outside the open, latency-sensitive auction entirely.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.