The waterfall is not stupid — it was a reasonable design for an era when browsers were slower and there was no standard way to run a client-side auction. But two of its assumptions turned out to be badly wrong.
Problem one: average CPM is a bad ranking signal
A waterfall ranks partners by what they paid on average last month. But the variance within a partner is far larger than the difference between partners. An SSP with a $1.20 average will pay $8 for the right user on the right page and $0.15 for the wrong one.
When you offer an impression to the $1.40 partner first and they take it at their floor, you never find out that the $1.20 partner would have paid $6 for that specific impression. The waterfall structurally cannot discover that, because it stops as soon as someone says yes.
Problem two: every step costs real time
Each waterfall level is a network round trip that has to complete and fail before the next one starts. Four levels at 300 ms each is 1.2 seconds of nothing happening, and that is a good case. Meanwhile the user is scrolling, and an ad that renders after the user has moved past the slot is worth close to nothing regardless of what it sold for.
A parallel auction collapses that. Ten simultaneous requests finish in roughly the time of the slowest one, not the sum of all ten.
Side by side
- Order of operations — waterfall: sequential, stops at first fill. Header bidding: simultaneous, always resolves to the highest bid.
- Pricing basis — waterfall: historical average per partner. Header bidding: an actual bid for that specific impression.
- Latency growth — waterfall: adds up with every level. Header bidding: roughly flat as you add bidders, bounded by the timeout.
- Price transparency — waterfall: you see what filled, not what you left behind. Header bidding: you see every bid, including the losers, which is what makes floor analysis possible.
- Failure mode — waterfall: a slow partner blocks everyone behind them. Header bidding: a slow partner simply misses the timeout and the auction continues.
Where the waterfall still has a place
One narrow case survives: what to do after the auction has already failed. If no bidder wanted the impression and your ad server has nothing to serve, you have an unfilled slot, and working through fallback options in order of value is exactly right there. That is a waterfall, but it runs on inventory nobody bid on, so its latency cost is paid out of an impression that was worth zero anyway.
A useful sanity check on any setup: ask what your unfilled rate is. If nobody can tell you, the reporting is not good enough to manage yield with.
Related questions
Is a waterfall always worse than header bidding?
For the primary auction, yes — sequential offers priced on historical averages cannot beat a simultaneous auction priced per impression. The one legitimate use of waterfall logic is downstream of a failed auction, deciding what to do with an impression that nobody bid on, where the latency cost is paid out of inventory already worth zero.
Can I run header bidding and a waterfall at the same time?
Yes, and most publishers effectively do. Header bidding resolves the auction, and whatever remains unfilled falls through to backup demand in priority order. The mistake is keeping legacy waterfall partners as passbacks in the primary path, where they add latency to impressions that were already going to fill.
Why do some vendors still sell waterfall mediation?
Mostly in-app, where client-side header bidding is harder and mediation SDKs came first, and in legacy setups where migration cost is high. On the web there is no strong technical case left. If a web vendor proposes a sequential passback chain as your primary demand path, ask them to justify the latency.
Try it on your own site
Free up to 1 million ad impressions a month. You keep your Ad Manager account and your SSP contracts.
Start free