How Header Bidding Works

Header bidding runs a simultaneous open auction across all demand partners before GAM is called, ensuring every buyer competes fairly rather than getting structural last-look.

Header bidding is the auction mechanism that powers Advlume's revenue stack. Understanding how it works helps you make better decisions about placement, sizing, and timeout configuration — and explains why you'll earn more than you would with a traditional waterfall setup.

The problem header bidding solves

Before header bidding, publishers used a waterfall: ad networks were ranked in order. The top network got first look; if it didn't fill at the floor price, the impression passed to the second network, and so on. The ad server — almost always Google Ad Manager — sat at the top and gave AdSense/AdX a structural advantage: it always got to bid last, after seeing all other bids, which meant it could win by just one cent over a competitor even if another buyer would have paid significantly more.

Header bidding fixes this by running a simultaneous, open auction across all demand sources before the page even asks GAM for an ad.

How it works step by step

1. Page loads, script initialises

When a visitor lands on your page, the browser loads hb.js from the CDN. The script reads your site config (slot keys, sizes, active bidders) from the Advlume edge cache and sets up the ad slots in Google Publisher Tags (GPT) — but intentionally holds off on requesting ads from GAM yet.

2. Bid requests go out simultaneously

Prebid.js fires bid requests to every active demand partner (Adform, AdKernel, Nexx360, and the rest) all at the same time. Each bidder's adapter submits a bid to its own SSP/DSP and returns a CPM within the auction timeout window (typically 1,500–2,000 ms).

3. Bids are collected and ranked

When the timeout fires, Prebid collects all responses received so far. Late bids are discarded. The winning Prebid bid is identified — the highest CPM across all demand partners.

4. Bid key-values are written to GPT

Prebid writes the winning bid's price and bidder identity as key-value targeting on the GPT slot — for example:

hb_bidder = adformOpenRTB
hb_pb     = 1.50
hb_size   = 728x90

The hb_pb value is price-bucketed (rounded down to the nearest granularity tier, e.g. $1.50 instead of $1.53) to keep the number of line items manageable in GAM.

5. GAM runs its own auction

GPT now fires the ad request to Google Ad Manager. GAM sees the hb_pb key-value and checks it against price-priority line items — one line item exists for each price bucket (e.g. $1.50, $1.55, $1.60…). If the Prebid bid's price bucket matches a line item, that line item wins and serves the Prebid creative, which calls back to Prebid to render the actual winning ad.

6. AdX gets dynamic allocation

While running this check, GAM also gives Google Ad Exchange a real-time look at the impression via dynamic allocation. If AdX can beat the Prebid floor price, it wins instead. This means AdX competes on a level playing field rather than getting structural last-look.

7. Creative renders

Whichever source wins — a Prebid bidder or AdX — GAM signals GPT to render the creative in the ad slot on your page. The Advlume wrapper logs the result: via=lineItem (Prebid won) or via=adx (AdX dynamic allocation won).

Why this earns more than AdSense alone

More competition. AdSense/AdX has to win on merit against 10+ SSPs per impression, not just get free last-look.
Higher floor prices. Prebid lets you set and communicate price floors to buyers. A buyer knows you won't accept under $1.00, which anchors their bidding higher.
Demand diversity. Some buyers — particularly in certain verticals or geos — bid aggressively on one SSP but not another. Running multiple SSPs simultaneously captures that spend.
No impression leakage. Waterfall setups often drop impressions that fall through every network. Header bidding with AdX backfill has near-100% fill — if nobody beats the floor, AdX serves a house ad or collapses the unit.

Lazy loading and smart refresh

Advlume's wrapper doesn't run the full auction for every slot on page load. Slots outside the viewport are held until the user scrolls within 800px of them (lazy loading), which means buyers get fresher, more viewable impressions and your viewability metrics improve. Once a slot has served and the user stays on the page, it refreshes every 30 seconds while 50% or more of it is in view — this is called smart refresh and multiplies revenue per session.

See Lazy Loading & Smart Refresh for full details.

Timeouts and latency

The auction timeout is the maximum time Prebid waits for bid responses before closing the auction and proceeding. Longer timeouts collect more bids; shorter timeouts reduce ad latency for the user. Advlume calibrates this per-account based on your traffic profile. Typical values:

Timeout	Typical value	Effect
Bid timeout	1,500 ms	How long Prebid waits for SSP responses
Failsafe timeout	3,000 ms	How long before GAM forces a refresh on stuck slots

Bids that arrive after the timeout are not used for the current impression but can inform future bid shading on the buyer side.

What Advlume handles for you

Running header bidding correctly requires maintaining Prebid adapters, GAM line items, price-priority orders, AdX creative configurations, and a real-time ingest pipeline. Advlume manages all of this:

Prebid.js is built and hosted on our CDN with only the adapters relevant to your account
GAM price-priority line items are created and maintained automatically when you add a site
AdX Ad Exchange line items and creatives are provisioned per-domain
Bid data is ingested from the edge and aggregated into your revenue reports