In-App Bidding vs Waterfall: How Mediation Picks an Ad

In-app bidding vs waterfall: what is the difference?

In a waterfall, your mediation platform calls ad networks one after another, in an order based on the eCPM you or the platform estimated for each, until one returns an ad. In in-app bidding, the platform asks every bidding network at the same moment, each one bids what this impression is worth to it, and the highest bid wins. Most apps now run a hybrid: bidders compete in a real-time auction, and networks that cannot bid still sit in a waterfall next to them.

The rest of this page explains how each model picks the winner, how Google AdMob, AppLovin MAX and Unity LevelPlay combine them, and what changes for speed, maintenance and what you can actually see. If you are new to the topic, start with what ad mediation is; this article goes one level deeper.

How a mediation waterfall works

A waterfall is an ordered list. When your app requests an ad, the mediation SDK tries the first network on the list. If that network has no ad at the required price, the request falls to the next one, and so on, until a network fills it or the list runs out.

The order is the important part, and it is not based on what a network would pay for this exact user. Google’s AdMob bidding overview contrasts bidding with waterfall mediation, which relies on eCPM values or historical data and calls ad sources one at a time. AppLovin’s MAX ad unit guide describes non-bidding networks as networks that “sequentially respond to an ad request in a waterfall, prioritized by the highest CPM price.”

To get more out of a waterfall, publishers usually add the same network several times at different prices. Unity LevelPlay calls each entry an instance and lets you give it a manual rate. Its mediation management docs are clear about what that rate is: “Rate is used only to prioritize the instance in your waterfall. This value is not sent back to the network and does not affect revenue reporting.” In other words, the number that decides the order is your estimate, not a price anyone has agreed to pay.

That creates three weaknesses:

• Averages hide individual users. A network that would pay a lot for one specific user may sit below a network that pays more on average but values that user less.
• Each step takes time. Every network that passes adds another request and wait before the next one is asked.
• Upkeep never stops. Prices drift by country, season and format, so the order and the price points need regular review, often per country group.

How in-app bidding works

In-app bidding replaces the ordered list with a single auction. When an ad request comes in, the platform asks every participating bidder at the same time, each bidder returns a price for this impression, and the highest bid wins. Google’s AdMob overview puts it as bidding that “calls all participating ad sources simultaneously” so they compete in a real-time auction. Unity’s LevelPlay in-app bidding page describes ad sources that “simultaneously bid for each impression in real time.”

The phrase “unified auction” means all of these bidders compete in the same auction rather than in separate rounds. AppLovin’s MAX auction dynamics page calls its exchange “a first-price, fair and transparent, unified first-price auction in which the highest bidder wins,” and says all SDK bidders and DSPs have equal access to each impression. First-price means the winner pays what it bid, not one cent above the second-highest bid.

The same idea exists on the web as header bidding, where several demand sources bid before the ad server decides. In apps, the bidders are usually ad network SDKs and exchanges; what an ad exchange is and DSP vs SSP explain who is on the other side of those bids.

Bidding does not remove the need for every SDK. Bidding networks still need their adapters in your app, and LevelPlay, for example, notes that bidding is supported from LevelPlay SDK 6.10.0 and that each bidding network also needs a minimum adapter version.

Hybrid setups: how platforms merge bidding and waterfall

Not every network can bid, so most real setups are hybrids. The three big mediation platforms each describe the merge differently, which is worth knowing when you read your reports:

• Google AdMob: the bidding auction runs first, and the winning bid is placed in the mediation waterfall according to its eCPM. If it ranks first, it serves. If a waterfall ad source has a higher eCPM value, that source is called first. AdMob also lets one ad source act as a bidding source and a waterfall source at the same time.
• AppLovin MAX: the auction server collects bids and then merges them with the non-bidding demand sources in your waterfall, resolving the auction by the highest CPM value. MAX also says its default waterfall is managed through “a combination of in-app bidding and CPM updating.”
• Unity LevelPlay: you can run only bidders, only non-bidding sources, or both. In the hybrid model, “both bidding and non-bidding sources are competing for all ad impressions,” with non-bidding sources represented by eCPM based on historical performance. You can also set a floor price per group; bidders that bid below it are left out of the auction.

Google has pushed its own demand toward bidding. Its AdMob Network in bidding page records that Google Ads stopped buying on multicall waterfall requests that do not contain a bidding ad unit (update of December 14, 2023), said it would stop answering multicall requests in hybrid setups as well from January 2024, and that Display & Video 360 would stop bidding on multiple waterfall calls from October 23, 2024. When you use AdMob Mediation, the AdMob Network is added automatically as a bidding source. Checked on November 4, 2026.

Waterfall vs bidding vs hybrid at a glance

Latency: why the number of calls matters

Latency is the time between your app asking for an ad and an ad being ready to show. In a waterfall, it grows with every network that passes, because each one is asked only after the previous one said no. In bidding, all bidders are asked in parallel, so the auction takes about as long as the slowest bidder the platform waits for. AppLovin’s auction page notes that bidders return their bids within a maximum timeout threshold it calls tmax.

Latency matters most for formats the player waits for. A rewarded video that is not ready when the player taps “watch” is a missed impression and a worse experience, which is why many apps preload ads. Fewer sequential calls make preloading easier but do not replace it.

Transparency: what you can and cannot see

Bidding is often described as more transparent, and in one narrow sense it is: the price that wins is a real bid for that impression, not an estimate you typed. Beyond that, keep your expectations specific:

• Waterfall prices are yours. As the LevelPlay docs say, a manual rate only orders the waterfall and is not sent to the network. Revenue in reports comes from what the network actually paid, which can differ from the rate you set.
• The auctioneer may also bid. Mediation platforms run the auction and often have their own demand in it. AdMob adds the AdMob Network as a bidder automatically, and MAX states that all bidders have equal access to each impression. Read each platform’s own auction rules rather than assuming them.
• Losing bids are usually not your data. You see what won and what it paid. How much detail you get on bids that lost depends on the platform’s reports.
• Some traffic cannot be auctioned. Google’s bidding overview notes that bidding ad sources currently do not serve ads for child-directed apps or ad requests, so a kids app may still depend on a waterfall.

The practical answer is to judge any setup by results you control: revenue per daily active user, fill rate, and how often an ad is ready when it is needed. ARPDAU and eCPM vs RPM explain the formulas.

Which platforms support what

Facts from each platform’s own documentation, checked on November 4, 2026. Which individual networks can bid on each platform changes often, so check the platform’s current network list before you plan a migration. For a broader comparison of the three, see AppLovin MAX vs ironSource vs AdMob.

When a waterfall still makes sense, and how to move to bidding

A pure waterfall is now rare, but waterfall entries still earn their place when:

• a network that pays well for your audience does not support bidding on your platform;
• you have a direct deal at a fixed price that needs its own position;
• part of your traffic, such as child-directed requests, is not eligible for bidding.

If you are moving from a waterfall to bidding, a careful path looks like this:

1. List every network and check whether it can bid on your mediation platform today.
2. Update the mediation SDK and the adapters to the versions bidding needs.
3. Turn on bidding for a test group of users or one ad unit, using your platform’s A/B testing tool if it has one.
4. Compare revenue per daily active user, fill rate and ad-ready rate, not eCPM alone.
5. Remove waterfall instances that now rarely fill, and keep only the ones that still win.

Where an offerwall fits

Everything above is about formats sold per impression: banners, interstitials and rewarded video. An offerwall is different. It is a separate, opt-in placement where users choose an offer, such as installing a game and reaching a level, and the publisher is paid per completed result. It does not enter the bidding auction or the waterfall, and it is not programmatic: nobody bids on the impression. In practice it sits next to your mediation stack, for example as a “get more coins” screen beside your rewarded video button. Offerwall vs rewarded video compares the two, and best rewarded ad networks covers the video side.

Frequently asked questions