What is Header Bidding?

Header bidding (pre-bidding) is a way to sell an ad impression in which the publisher asks several demand sources — exchanges, SSPs, and direct DSPs — for bids before calling the ad server, then awards the slot to the winner. Partners compete for the same impression in one window instead of waiting in a line-item queue. The practice spread in the mid-2010s as a fix for waterfall yield in Google Ad Manager and similar servers; in the CIS the same setup is often wired through Yandex Adfox.

Header bidding vs waterfall

In a classic waterfall (daisy chain) the ad server walks partners in order: the highest-priority network or SSP gets first look; if the slot is empty, the next partner is called. If the first buyer clears the impression at $1.50, a second buyer willing to pay $3 never sees it. The publisher loses yield; demand further down the chain gets leftovers.

Header bidding breaks that queue. A page (or server) wrapper sends bid requests in parallel, collects answers within a timeout, and passes prices into the ad server as key-values. Those bids then compete with direct campaigns and remnant demand. The higher bid wins, not the place in the list. Publishers see higher CPM and eCPM; buyers get a fairer shot at the same display or video slot.

Why header bidding is not the same as RTB

RTB (real-time bidding) is the protocol and mechanics of auctioning one impression in milliseconds. Header bidding is orchestration: several of those calls (often OpenRTB) run in parallel, then the ad server picks a winner. One partner may run a normal RTB auction inside its call; another may return a fixed programmatic-guaranteed price. Do not treat “RTB” and “header bidding” as synonyms: the first is how an impression is priced, the second is when and how many demand sources see it at once. The buying stack around both is programmatic advertising. Also keep it distinct from RTB feed traffic, where a buyer purchases an XML/API feed as a traffic source rather than bidding in the publisher’s auction.

Wrappers: Prebid, server-side, Adfox

A client-side wrapper is JavaScript in the page <head>. The open default is Prebid.js (Prebid.org): adapters for dozens of SSPs and exchanges, a shared timeout, and analytics. Commercial wrappers include Amazon TAM / Unified Ad Marketplace, major SSP suites, and local ad servers.

Server-side setups (Prebid Server, Google Open Bidding, and peers) move the parallel calls off the user’s device onto publisher or Google infrastructure. Pages load faster and the browser does less work, but cookie matching is weaker: some demand cannot recognize the user and bids lower. Hybrids are common — some partners in the browser, some server-side.

In the CIS, header bidding is usually attached to Yandex Adfox: the wrapper collects bids, Adfox runs the auction against direct campaigns and Yandex demand. Configuration covers partner list, timeout, floors, and IAB slot sizes. If the wrapper ↔ Adfox link is wrong, bids never enter the auction and the stack falls back to a waterfall.

What happens on one impression

  1. The page loads the wrapper; the slot is still empty.
  2. The wrapper calls connected partners in parallel (typical timeout 800–1500 ms).
  3. Respondents return a bid, creative ID, and metadata.
  4. The ad server (GAM, Adfox) compares those bids with direct line items and residual demand.
  5. The winning creative renders; losing responses are dropped.

A late response is a lost bid, not a second queue. That creates a hard trade-off: a longer timeout can raise fill and CPM but hurts Speed Index and Core Web Vitals.

What it means for buyers

For a media buyer in a DSP (DV360, The Trade Desk, and others), header bidding means the same URL is more often auctioned in several demand paths at once. Bids and bid strategy compete not only in the open auction but with other wrapper partners. Competition lifts CPM; in return there is less cheap remnant inventory from the bottom of a waterfall. Review domain/app, deal ID, viewability, and post-click CR in the tracker — not only win rate in the DSP. Direct PMPs via header bidding are more predictable than blind open exchange.

Limits

Too many client-side adapters add latency and raise the chance the user leaves before the ad shows. Count gaps between SSP, ad server, and DSP are expected when timeouts and creative filters drop responses. Identity (cookies, ID graphs) is weaker after browser limits and ATT on the client, and weaker still server-side without a login. Header bidding does not replace quality filters: bot traffic, domain spoofing, and low viewability stay demand-side problems.

See also: programmatic advertising, RTB, SSP, DSP, DV360.