Header bidding vs waterfall: which one pays publishers more?

A waterfall offers each impression to demand sources in a fixed order, one after another, until someone takes it. Header bidding asks them all at the same time, before the ad server call, and lets them bid against each other.

The consequence is priced in every impression you sell. In a waterfall, a buyer sitting fifth in the queue never gets to bid on an impression that the third source accepted at a lower price, so you left money on the table without ever seeing it. In an auction, that buyer competes, and competition is what sets the price.

Because order is not price. A waterfall is built on historical average CPMs, so it assumes the source that paid best last month will pay best for this impression. That assumption breaks constantly: value depends on the individual user, the moment, the campaign in flight and the geography.

It also fails at the end of the queue. When no source accepts, the impression goes unsold or falls to backfill at a fraction of its worth, and that is exactly what a low fill rate is telling you.

It is not free, and three cases regularly disappoint:

• Small inventory volumes. Bidders need scale to bother competing, so a low-traffic site can add partners and see the same prices with more latency.
• Too many partners. Each one adds weight to the auction. Past a point you are paying latency, and therefore lost impressions, for bids that never win.
• Slow pages. If your auction times out before bids arrive, you get the waterfall outcome with the header bidding overhead.

Latency is the tax, and it is worth measuring in revenue rather than in milliseconds: an impression that arrives after the reader scrolled past is worth nothing regardless of who won the auction.

Judge on revenue per thousand page views rather than on CPM, because CPM alone hides both fill and latency effects.

1. Measure your current revenue per thousand page views, your fill rate and your page speed, for a full week.
2. Add header bidding with a small number of partners, three to five, not everything available.
3. Compare against the baseline, and watch the auction timeout as closely as the price.
4. Add or remove partners one at a time, keeping only the ones that win often enough to justify their latency.

The healthiest setup for most independent publishers is a small header bidding stack plus the ad server's own demand, with the waterfall kept only as backfill.

Both models answer the same question: who buys this impression. Neither can answer a different one, which is what happens when the impression never exists.

When a visitor's ad blocker stops your ad library from loading, no auction runs. No header bidding partner is asked, no waterfall step is attempted, and nothing appears as unsold, because there was never a request. Your fill rate stays healthy while that revenue is simply absent from the report.

This is why yield work can plateau for reasons that have nothing to do with yield. You can tune floors, add partners and shave latency, and still watch revenue per session drift down, because the share of page views that reach the auction at all is shrinking underneath you.

Optimizing an auction improves the price of the impressions you sell. Recovering blocked page views increases how many impressions you have to sell, and it compounds with everything else: every recovered visit then flows through the same header bidding stack you just tuned.

The practical order is to measure the blocked share first, because it sizes both problems at once and it is the cheapest number to get. If it turns out to be small, spend your time on the auction. If it turns out to be a fifth of your traffic, that is where the money is.

Our script measures exactly that with a one-line install: detections, recoveries and recovered revenue per site, with network-level blocking separated out so the recoverable share is not overstated. What adblock costs publishers covers how to turn it into a business case, and fill rate and viewability explains why your current metrics hide the loss.