How In-App Bidding is Replacing the Traditional Mobile Waterfall
A waterfall sells each in-app impression to the first ad source in a fixed chain that answers the call, at whatever price that source pays. An in-app auction sells the same impression to whichever source bids the most for it at that moment. The distance between those two sentences is the whole case for in-app bidding, and none of it depends on demand quality: the same buyers sit on both sides of the comparison. What changes is the pricing signal that routes the impression.
What a waterfall actually optimizes
A waterfall is an ordering exercise. You rank ad sources by the average eCPM each one reported over a trailing period, and the mediation layer calls them one at a time from the top of the list. The first source that wants the impression takes it, and no source below the fill point learns the impression existed.
Google states the limitation without softening it: waterfall mediation calls ad sources one-by-one based on the average eCPM the publisher sets, not what the ad source is willing to pay, while bidding sources place bids in real time and compete in a single, unified auction. That sentence comes from AdMob's mediation guide, and it should anchor the migration brief you hand to your app team. When the vendor that runs the mediation layer concedes the pricing flaw, the debate is over and the remaining work is operational.
Make the failure concrete with a hypothetical chain. You rank one video source first because it reported an average eCPM of 2.10, and you rank a second source third because its trailing average sits lower. On a given call, the first source has a matching campaign and fills at 2.10. The third source had a buyer willing to pay 4.00 for that exact user at that exact moment, and the chain never asks it. Your own ranking then works as a standing discount, impression by impression.
Three structural problems follow from the design, and no amount of chain tuning fixes all three:
- Stale pricing. The order encodes trailing averages, and a trailing average describes the past mix of a source's demand, not its willingness to pay on this call.
- Invisible demand. Sources below the fill point never see the request, so they cannot bid up to win it, and you never learn what they would have paid.
- Sequential latency. Each call waits on the one above it, so depth in the chain costs load time, and the usual fix, a shorter timeout, cuts the depth you were buying.
Chain tuning has a ceiling here. Reordering sources and re-keying their historical eCPMs can improve a chain's performance, but the mechanism itself is the ceiling: the chain prices by position, and position carries no information about this user, this moment or this buyer's budget.

What in-app bidding changes at the request level
In-app header bidding keeps your ad server and mediation stack in place and changes what happens before the ad request. The Prebid Mobile overview describes an open-source library for iOS and Android that provides an end-to-end header bidding solution for mobile app publishers. Prebid Server runs the auction among the demand partners you preconfigure, and the SDK sets key-value targeting for each ad slot through the Google Mobile Ads SDK.
Prebid Mobile turns that into a fixed, inspectable sequence. From app open to creative render, five steps run every time:
- The app initializes the SDK and registers each ad unit with its configuration ID.
- The SDK requests bids from Prebid Server, which runs the auction across your preconfigured demand partners.
- The SDK caches the winning bid and writes price key-values onto the ad slot through the Google Mobile Ads SDK.
- The app fires its normal ad request, and your ad server compares the header bidding line item against network line items and direct campaigns.
- The highest price wins the slot. If the header bidding line item wins, the creative renders from the cached bid; if it loses, reporting shows which line item won instead.

Two properties separate this from a faster waterfall. First, the bids compete with your other demand, ad networks and direct campaigns alike, using real-time bid prices instead of static estimates. Second, every bidder sees the same request at the same time, so demand that trails your historical averages can still surface a price when a specific user is worth more than the average suggests.
That second property is where the revenue case concentrates. A waterfall's blind spots cluster on impressions where the clearing price exceeds the historical average, because a fixed order does the most damage exactly there. In-app bidding does not conjure new demand; it stops you from underpricing the demand you already have.
Open Bidding: the server-to-server route
Prebid Mobile ships demand through your own app. Ad Manager's Open Bidding takes the other road: a server-to-server integration where demand partners connect behind Google's infrastructure, and no per-partner SDK bloats your binary.
In Open Bidding's unified auction, Ad Manager compares the best line item rate, the expected mediation yields and the yield partner bids at the same time, and the top bid wins. Your direct deals, house campaigns and price priority line items compete against exchange demand in a single comparison instead of a negotiated pecking order. The auction, not the integration order, prices the impression.
The mediation detail deserves attention. When a mediation yield partner wins the unified auction, Google returns a mediation chain that includes partners with CPMs higher than the best Authorized Buyers or Open Bidding bid. Read that twice: mediation survives inside Open Bidding, but only after the partner has already outbid every other source in the unified auction. The entry decision is auction-based, and the internal chain is the partner's own business. A publisher holding a mediation stack loses nothing at the entry point, because the highest external bid still sets the bar.
Choose between the routes on control versus maintenance. Prebid Mobile gives you the partner list, the floor strategy and the first-party data in each bid request, at the cost of shipping SDK changes through app releases. Open Bidding requires no client work per partner, at the cost of routing those auctions through a single counterparty and reading them in that counterparty's reporting. The routes also coexist: an app can run Prebid Mobile for its curated demand and Open Bidding for Google-connected partners on the same ad unit.
Hybrid mediation is the migration path
Google officially supports mixed mediation groups that combine bidding and waterfall ad sources, and that support should shape the rollout plan. Few portfolios can move every format, every network and every app version inside one release cycle, so the hybrid group is the state you operate in for months. Treat it as a configuration to manage, not a compromise to apologize for.
Sequence the rollout so each step isolates one variable. This order holds up in production:
- Start with one format where single-impression prices run highest, interstitials or rewarded video, and enable bidding for every partner that supports it there.
- Leave partners without bidding interfaces in the waterfall beneath the auction, and re-price their configured eCPMs from current tests instead of historical highs.
- Release to a percentage of users, then compare matched cohorts on eCPM, fill rate and time-to-render before widening the rollout.
- Segment every comparison by SDK version. Users on old app versions keep the waterfall path for months after a release, and blended averages will hide the difference.
- Repeat per format, banners last, and retire a waterfall position only when a bidding source covers the demand it carried.
Holdout discipline matters more in-app than on the web, because release cadence is slow. Once a build ships, you live with its configuration until the next release reaches your users, so instrument the comparison before you need it.
Floors and first-price dynamics in the auction
Moving from a chain to an auction changes what a floor does. In a waterfall, each source's configured eCPM acts as a price ladder: raise it and the source fills less often, lower it and it fills more. In an auction, the reserve price meets live bids, and buyers respond strategically to the competition they expect.
Two dynamics do most of the work. Under first-price clearing, buyers shade bids below their true ceiling, and the size of the shading tracks how much competition they expect. Under expected-value ranking, the ad server weighs the likely clearing price of each path, so a floor set above realistic clearing levels does more than lose auctions one at a time: it changes which line items enter the comparison at all. Our auction mechanics and bid shading reference covers expected-value ranking, first-price clearing and reserve price strategy in detail.
Once the auction runs, floors need their own discipline. Three rules cover most of it:
- Set floors per ad unit and geography, not per app. Auction density differs by format and market, and a single global floor averages away the spread you are trying to capture.
- Revisit floors on a schedule tied to bid depth and win rate, not on a hunch after one bad week.
- Keep the configured eCPMs of leftover waterfall sources honest. Inside the chain they still decide the order, and inflated values rebuild the original problem inside the backfill path.
Floor work does not end with the migration. The auction reprices every impression on its own; the floors are the one price control you keep, and they only work on a review cadence.
Where the demand connects
The auction layer only pays what the seats behind it bid, so integration questions dominate the migration. At OnlyMedia, we integrate OpenRTB 2.6 seats and Prebid for header and server-side demand, which means one request reaches client-side and server-side buyers without a second build on your side. Our SSP's unified auction runs one auction per impression across AdX via MCM, Prebid and OpenRTB seats, under managed floors we adjust per ad unit and geography.
We are an ad network, an SSP and an agency in one company, and that shape matters operationally: the team advising the migration also holds the seats, so recommendations and outcomes land in one P&L instead of across three vendors. Payment terms follow the same logic. We pay publishers Net 30, CPM based: no chasing, no sliding terms, and the demand behind those invoices comes from our curated programmatic demand network. We work with thousands of publishers, each above one million monthly pageviews, and the migration pattern above is work we run every week.
What to measure during the migration
Auction mechanics fail quietly, so build the reporting plan before the release ships. Instrument these cuts from day one:
- Bid depth: how many partners bid per auction, per ad unit. Depth drives price discovery, and a thin auction reproduces the waterfall's pricing problem with extra steps.
- Match rate: the share of bid requests that return at least one bid. A low match rate points at floors, geographies or consent configuration before it points at demand.
- Win rate by partner: which seats clear at which floors tells you where to move managed floors next.
- eCPM by format and ad unit, with the waterfall cohort as the control group for the release window.
- Time-to-render by SDK version, because the latency you removed from the chain can reappear inside a slow auction call.
Segment everything by format and consent regime. Interstitials, rewarded video, banners and mobile web placements clear at different levels with different bidder density, and blended averages will hide the formats that actually moved. In EEA traffic, pass the TCF consent string into every bid request; without it, most partners return no bid, and the match rate collapses for exactly the users who price highest. Device-level reporting closes the loop, and our in-app and mobile web formats page details the interstitial, rewarded video and banner inventory we run along with the device-level cuts we report on.
Where the waterfall still earns a slot
Retiring the chain entirely is rarely the right first move. Some regional networks and specialized SDKs offer no bidding interface, some house campaigns price above what the auction clears, and some formats in some geographies draw thin bid depth. Hybrid mediation exists for exactly this reason, which is why Google ships mixed groups as a supported configuration rather than a workaround.
Set the operating rule accordingly. The auction prices the impression, the chain backfills what the auction leaves unfilled, and every source inside the chain carries an honest configured eCPM. Under that rule the waterfall stops costing you the spread between what a buyer pays and what a buyer would have paid, and that spread is exactly what in-app bidding recovers.