At $1.80 CPM versus $1.40 CPM, a waterfall ranking can still miss the better bid. Header bidding applies to mobile apps in a different form: multiple demand sources compete simultaneously through mediation. The implementation and terminology vary by platform, but the underlying concept carries over. This guide connects web header bidding to the SDK, waterfall, and auction behavior app developers manage in production.
Web Header Bidding: Context
In web display, the original waterfall had the publisher ad server assess demand in a fixed order, usually direct-sold inventory first and programmatic buyers afterward. Header bidding emerged around 2015-2016 so multiple programmatic buyers could compete before the ad server decided. Its name came from JavaScript in the HTML tag collecting bids before the page rendered.
Prebid.js became the leading open-source web header bidding solution. Publishers saw eCPM gains because inventory reached multiple buyers at once. The Google Ad Manager, formerly DFP, waterfall that gave Google's AdX a structural advantage now faced external bidders on a more level surface.
Mobile apps have no HTML headers, so the concept was rebuilt as an in-app SDK mechanism. Mediation platforms provide that mechanism.
How Mobile Waterfalls Work
In a mobile waterfall, the mediation SDK stores a prioritized demand partner list. When the app requests an ad, the SDK contacts the first partner. If it fills at or above the configured CPM threshold, it wins. Otherwise, the SDK moves to the second partner, then the third, until one fills or the list ends.
The list is static and usually updated manually from recent CPM results. If Network A averages $1.80 CPM and Network B averages $1.40 CPM, A ranks above B. But those averages do not show the price for this impression, now, in this geography. B might have outbid A if given the opportunity. A waterfall never gives it that opportunity.
Waterfalls also add latency one request at a time. Each pass to a lower-priority partner adds another round-trip network call. A five-tier waterfall that fills at tier four has paid for three failed calls before reaching the winner.
In-App Bidding: Mobile Header Bidding
In-app bidding, the mobile term for header bidding in apps, sends the impression opportunity to every configured demand partner at once. Each returns a real-time bid within a fixed timeout. The mediation SDK gathers the bids, chooses the highest one above the publisher's floor price, and serves that creative.
The terminology depends on the platform. Google's Bidding, formerly Open Bidding in Google Ad Manager, uses a server-side approach. Some platforms say "unified auction." Adrop uses client-side parallel bidding, with the SDK sending bid requests from the device to all configured partners. Regardless of the name, every partner gets the chance to bid before selection.
For the app developer, the code is unchanged. Call the mediation SDK's ad request method for the ad unit, and the SDK runs the parallel auction. The callback returns either a filled creative or no-fill. Auction logic stays in the mediation layer, not in app code.
The Practical Difference in Numbers
Parallel bidding improves yield over a waterfall mainly through competition and latency. Impressions once sent to Network A at its reserved CPM can reach every partner, and some may bid above A's historical average. Latency is also bounded by the timeout window instead of growing with each sequential hop.
We do not present universal percentage lift figures because results depend heavily on the existing setup. A single-network integration has no waterfall to improve, so adding competing demand provides the full benefit. A well-managed five-network waterfall using current CPM data was already reasonably competitive, so switching to parallel bidding produces a smaller incremental gain.
In-app bidding is most compelling when two or more demand partners sit in a waterfall with stale ranking data. The ranking then likely misses current market values, while sequential access suppresses lower-ranked partners that could bid aggressively for particular impression types.
Technical Considerations for App Developers
In-app bidding adds technical considerations that a waterfall does not:
Timeout management: a parallel auction needs a timeout window. If it is too short, some partners miss the auction and competition falls. If it is too long, ad load time becomes noticeable. Most mediation platforms recommend 100 to 200 milliseconds for bid collection, within the range users do not notice for interstitial and rewarded formats when requests are prefetched before the ad moment.
Prefetching matters more: waterfall requests usually fire at or just before display. With concurrent bidding, requesting earlier helps the full auction finish before the user reaches the placement. An interstitial between game levels should ideally be requested 10 to 15 seconds before the level ends, rather than at the transition. That timing belongs to the app's ad request design, not SDK configuration.
No-fill handling: concurrent bidding can return no-fill just as a waterfall does when no bid reaches the floor price or inventory is thin. Handle the callback the same way: degrade gracefully, avoid a broken ad container, and retry after a sensible delay.
What to Look for in a Mediation Layer
"Supporting in-app bidding" can describe materially different implementations. Check whether the auction is client-side, with the SDK collecting bids on-device, or server-side, with the provider collecting bids and returning only the winning creative. Both can work well. Server-side adds dependency on provider infrastructure latency, while client-side keeps the auction closer to the impression moment.
Also check which demand partners actually support real-time bidding in that implementation. A platform may list 15 demand partners while only three join the parallel auction and the rest remain waterfall fallback. The share of configured partners actively bidding matters more than the total listed.
The web ecosystem showed that auction structure matters as much as participant count, and mobile follows the same pattern. Five genuinely competing partners in a well-structured parallel auction will typically beat a long waterfall where only the top two bid in real time. Count active bidders, not the entire partner list.
[/BODY-HTML]