Learn

← Track A: Foundations
L2

A3

Header bidding vs waterfall vs unified auction

In this lesson you will
  • Define header bidding as a pre-auction held in the page header before the ad-server call.
  • Contrast it with the open-auction-only waterfall and with Dynamic Allocation.
  • Explain why header bidding exists: to let multiple demand sources compete simultaneously on price for the same impression.

The waterfall’s flaw was simple: it asked buyers one at a time, in a frozen order. Header bidding fixes it with one move. Ask every buyer at once, and let the highest real bid win.

More precisely: header bidding is a pre-auction held in the page before the ad server is called. Several SSPs bid on the same impression at the same time, and the single best bid is handed to the ad server to compete with everything else.

Versus the waterfall

The auction is parallel and price-based, not sequential and order-based. Every wired partner gets a fair shot at every impression, and the highest real bid wins rather than the first one that happens to fill.

Quick check

In one sentence, why does asking all buyers at once beat asking them one at a time?

Versus Dynamic Allocation

Google’s Dynamic Allocation already let one source, Google’s own AdX, bid in real time against the ad server’s other line items. The catch was that only AdX could do it, which gave Google a structural advantage. Header bidding generalized that same real-time competition to many non-Google SSPs, neutralizing the advantage of being the only demand that could bid dynamically.

Key idea

Header bidding’s historical purpose: let demand sources other than AdX compete on price, in real time, for the same impression, before the ad server decides.

Two pieces that make it work

  • The wrapper. Managing many SSP tags by hand is unworkable. A wrapper (Prebid.js, the focus of Track B) runs the parallel auction, enforces one global timeout, and normalizes every bid response into a common shape.
  • The ad-server translation layer. The ad server does not understand raw bids, so the wrapper writes the winning price into key-values (for example hb_pb=2.50) that the ad server’s line items target. That is how a header bid becomes something the ad server can compare.

The end-state everyone is moving toward is the unified auction: one auction where header demand and the ad server’s own demand compete on equal footing. First-price auctions and server-side bidding are both steps in that direction.

Note

In any Bidcliq Academy audit, the SSP count is the number of header-bidding demand partners a publisher has wired in. More partners is more competition, but only if each one is authorized and resolves cleanly, which is the whole point of Track C.

Key concepts
Parallel (not sequential) auctionThe wrapperThe ad-server translation layer (key-values)"Unified auction" as the conceptual end-state
Going deeper

To really lock this in: write a short essay on why header bidding emerged and what advantage it neutralized, plus a compare-table fill-in.

Where this leads
ANALYZE

The SSP count in any Bidcliq Academy audit is the number of header-bidding demand partners a publisher has wired in. Correlate it with the quantity axis.

Open →
Bidcliq Academy · A3: Header bidding vs waterfall vs unified auction