Mediation vs Bidding In App Monetization: What's The Difference

Waterfall Mediation, Mechanically Explained

Waterfall mediation works off a fixed priority list. You, or your mediation SDK's default settings, rank every ad network for a given ad unit — rewarded video, interstitial, banner — from highest expected eCPM to lowest. When a user triggers an ad request, the SDK calls the first network in that chain. If it returns a fill within its timeout window, the ad shows. If it doesn't, the SDK moves to the second network, then the third, and so on until something fills or the chain runs out.

The ranking itself is the part people misunderstand. It isn't based on what any individual impression is actually worth to a bidder in that moment. It's based on a historical average eCPM you or an account manager calculated from the last 7, 14, or 30 days of that network's performance on that ad unit, then hardcoded as a rank. Some mediation platforms let you set price floors per line item to approximate real-time value, but the order itself is still static until someone manually edits it.

That manual editing is the operational tax nobody really talks about openly. Someone has to pull performance reports, notice Network B is now outperforming Network A for US rewarded traffic, and reorder the chain — usually weekly if you're diligent, monthly if you're realistic. Every single day between updates, you're serving impressions in an order that reflects last month's demand, not today's.

There's also a sequencing cost baked into the request flow itself. Each network in the chain gets its own timeout window before the SDK moves on, which means a request that has to pass through two or three failed attempts before finding a fill has already burned several hundred milliseconds of latency the user is sitting through. On a five-network chain with 300ms timeouts each, a request that fills on network four has already cost you close to a second, even before the winning ad starts rendering.

What In-App Bidding Actually Auctions

In-app bidding flips the sequence into a single simultaneous auction. When the ad request fires, every participating bidding network receives the same impression opportunity at the same time and returns an actual bid — a real price, calculated against that specific user, device, and context — within a shared timeout window. The mediation layer collects every bid, compares them against any traditional waterfall line items still in the chain, and awards the impression to whichever demand source offered the highest real price.

This is the same auction logic that reshaped display advertising on the open web, just translated into the mobile SDK layer. If you've read through how the auction concept plays out across ad platforms broadly, in-app bidding is the mobile-native version of that same real-time competitive pricing, running inside your app binary instead of a browser tag rendering on a page.

The practical distinction that matters for your revenue: bidding networks are competing on the actual impression in front of them, not on a proxy calculated from last month's average. A 34-year-old iOS user opening your fitness app on a Tuesday morning gets a price discovered right then, from every bidder who wants that specific slot, based on signals available at that exact moment rather than a rank set weeks earlier.

Most modern mediation SDKs — AdMob's, LevelPlay's, and the major independents — support what's usually called a unified auction, meaning bidding networks and any remaining waterfall line items get evaluated against each other in the same comparison rather than in two separate systems bolted together. That matters because it removes the artificial ceiling a legacy line item sitting above the auction would otherwise impose on what a bidder could ever win.

• Ad request fires once, sent to all bidding participants simultaneously
• Each bidder returns a real-time price based on live signals (geo, device, time, user behavior)
• Mediation SDK compares bids against remaining waterfall line items
• Highest actual price wins and renders, typically within 200-400ms

Why Waterfall Underprices Every Impression, Systematically

Here's the core problem with static ranking, and it's the same issue that pushed web publishers off waterfalls years before mobile caught up: averages hide variance, and variance is where the money is. A network ranked third in your chain might average $3.80 eCPM across all your traffic, but on a specific impression — a returning user, US-based, on a newer device, browsing at 9pm — that same network might genuinely be willing to pay $14.00. Your waterfall never finds out, because the network ranked first and second already claimed first look and filled the request before request three ever got asked.

I've seen this play out on accounts where the top-ranked network in the chain fills 60-70% of requests, which sounds efficient until you check what those same impressions would have cleared in an open auction. On one shopping app, we found the network sitting in the number-one waterfall slot was winning impressions worth $9-11 to other bidders at an average price of $6.40, simply because it got first crack before anyone else was asked.

That's not a network being predatory — it's the structural flaw of sequential, average-based ranking. Every impression that gets filled by a lower-priced network ahead of a higher-priced one is money left on the table permanently, not recoverable later. It compounds across millions of daily requests in a way that a manually reordered waterfall, no matter how often you update it, structurally cannot fix. This is the deeper mechanism behind the eCPM gains covered in the broader guide to lifting app eCPM — bidding closes this gap at the auction level rather than through tactics layered on top of it.

This is also why I'm skeptical of the advice, still repeated in a lot of onboarding guides, that says you can fully solve waterfall underpricing through more aggressive price floors and more frequent manual reordering. Floors help at the margins, but they're still a human guessing at value ahead of time instead of the market discovering it in the moment. Teams that spend hours a week fine-tuning waterfall floors are often optimizing the wrong lever entirely — that time is better spent adding bidding participants than perfecting a fundamentally static system.

Client-Side Bidding vs Server-Side Bidding Architectures

Client-side in-app bidding, the model used by AdMob's bidding and LevelPlay's bidding, embeds a bidding adapter SDK for every participating network directly inside your app binary. When an ad request fires, the device itself sends a bid request to each network's server, waits for responses within the timeout, and the mediation SDK running on-device picks the winner. It's transparent — you can see exactly which network bid what, in your own mediation dashboard, line by line.

Server-side bidding routes things differently. Your app makes a single request to a server-side auction endpoint, which then fans that request out to bidders on its own infrastructure and returns one winning creative payload back to the device. The app only ever talks to one server, not five or eight, which cuts the number of round trips your device makes over cellular or spotty wifi.

The tradeoff is visibility and control. Client-side bidding means more SDKs bundled into your app (each bidding adapter typically adds 0.5-2MB), more independent network calls draining battery and data, but you get granular, auditable per-bidder data. Server-side bidding is leaner on-device and often faster to first render, but you're trusting the server auction's reporting on bid values you can't independently verify request-by-request. Most mid-size apps I work with run primarily client-side bidding today simply because the tooling and documentation are more mature.

• Client-side: full per-bidder transparency, heavier app footprint, more network calls
• Server-side: leaner device footprint, single request, less bid-level auditability
• Client-side is currently the more common default for apps under roughly 500k DAU
• Server-side architectures tend to show up more in larger, engineering-heavy publisher stacks

The Mobile Latency Budget Is Even Tighter Than Web's

On desktop web, a header bidding wrapper can often tolerate 800-1500ms of auction time before a page feels sluggish, because a page is already loading dozens of other assets and users are somewhat conditioned to a beat of delay. Mobile app UX gives you nowhere near that grace. A rewarded video that hangs for a second and a half before loading, or an interstitial that stalls the transition between game levels, reads as a broken app, not a slow ad.

Because of that, in-app bidding timeouts on mobile are typically configured much tighter — commonly 200-400ms per bidder, sometimes even less for banner refreshes. That's the entire window for the request to leave the device, reach the bidder's server, get scored, and return a price. Anything slower gets dropped from that auction round entirely, whether or not it would have won.

Cellular variability makes this worse than it sounds on paper. A user on strong 5G and a user on a congested LTE connection in a crowded venue are both hitting the same timeout clock, but one of them is going to lose bidders simply due to network conditions, not bid competitiveness. A pattern I've seen work: adaptive timeout tiers based on measured connection quality, giving marginally more time on weaker connections rather than a single fixed timeout across your whole user base, which recovers fill you'd otherwise lose to timeouts alone.

Device tier matters too, and it's easy to overlook. A three-year-old low-end Android device processing bid responses and rendering a creative has meaningfully less headroom than a current-generation flagship, even on an identical network connection. Some of the mediation setups I've reviewed apply the same timeout and the same number of concurrent bidders across every device, which quietly costs fill rate on the lower end of the install base — trimming concurrent bidders on older hardware tends to recover more revenue than it gives up.

Realistic eCPM Lift When You Actually Flip The Switch

The honest range I've seen across accounts moving from a pure legacy waterfall to bidding-enabled mediation is a 15-40% eCPM lift, and where you land in that range depends almost entirely on how outdated your existing waterfall already was. An app running three or four static networks that hadn't been reordered in months tends to land at the high end. An app that was already reasonably well-optimized, with frequent manual reordering and tight price floors, might only see 5-12%, because a diligent manual process was already partially compensating for the structural flaw.

Concrete numbers from recent migrations: rewarded video moving from $12.00 to $15.40 average eCPM, interstitials from $6.20 to $7.85, banners from $0.80 to $1.05. Those are believable, not guaranteed — vertical, geo mix, and ad unit density all move these numbers meaningfully. A US-heavy gaming app with strong rewarded engagement tends to sit at the upper end of that range, while a utility app with mostly banner inventory and a broader international geo mix will land closer to the lower end, simply because there's less competitive bidder density chasing that traffic in the first place.

What most guides don't mention is the dip before the lift. In the first two to three weeks after adding new bidders, fill rate and eCPM can actually soften slightly while each network's bidding algorithm calibrates against your specific traffic — it hasn't seen enough of your users yet to bid confidently. Judging the migration on week-one numbers is a common mistake; give it a full billing cycle before drawing conclusions.

• Rewarded video: often the largest absolute dollar lift due to high baseline eCPM
• Interstitials: moderate, consistent lift, usually 15-25%
• Banners: smallest relative lift but highest impression volume, so still material in aggregate
• Expect a 2-3 week calibration dip before bidders reach full pricing confidence

Migration Considerations Nobody Puts In The Onboarding Deck

Moving from a pure waterfall to a hybrid or full bidding setup isn't a settings toggle — it's an SDK integration project. Each bidding network needs its own adapter added to your mediation SDK, and adapters have their own release cadence, minimum OS support, and occasional conflicts with each other's dependencies. Adding six to eight bidding adapters can grow your app size by 3-8MB combined, which matters more than it used to now that install conversion is sensitive to app size on slower connections.

Testing has to cover both current and one or two prior major OS versions on both platforms, because bidding adapters don't always get simultaneous parity between iOS and Android releases — I've seen an Android adapter ship two months ahead of its iOS counterpart from the same network. Skipping older OS version testing is how you end up with silent no-fill on a meaningful slice of your install base.

App Tracking Transparency affects both models, but not identically. On waterfall, a drop in consented iOS traffic degrades the historical averages your static ranking was built on, and that ranking takes weeks to catch up because someone has to notice and manually reorder it. On bidding, each auction adjusts per-impression in real time — bidders without IDFA access simply bid lower or shift to contextual signals immediately, impression by impression, without waiting on you to notice a trend and act on it. If you're planning this migration, it's worth getting hands-on implementation support rather than treating adapter integration as a side project squeezed between feature releases.

Budget time for a proper QA pass on both ATT states specifically — opted-in and opted-out — not just a general regression pass. I've seen migrations ship where the bidding adapters were thoroughly tested against consented traffic but the non-consented fallback path, which routes to contextual bidding or a reduced set of participants, was never actually exercised until it hit production and quietly underperformed for weeks before anyone noticed the gap in the reporting.

When Skipping Bidding Entirely Is The Right Call

Bidding isn't free to run, and for a genuinely small app, the math doesn't favor it yet. If you're under roughly 2,000-3,000 daily active users, the incremental lift from adding five or six bidding adapters might translate to $30-80 extra per month, against real engineering time spent integrating, testing, and maintaining those adapters through OS updates. That trade isn't close.

For apps in that range, I'd rather see a clean two- or three-network waterfall with tight, honestly-set price floors, using whatever bidding-enabled demand your primary mediation platform already bundles by default (AdMob's own bidding participation, for instance, competes reasonably well even inside a simple setup without you adding anything extra). Get the fundamentals right — proper ad unit placement, frequency capping, viewability — before chasing auction sophistication.

The signal to revisit this isn't a calendar date, it's growth. Once you cross a few thousand DAU with multiple ad units live and enough daily impression volume for bidders to actually calibrate against, the equation flips in bidding's favor fast. If you're unsure where your account currently sits relative to that threshold, running through an eligibility check is a faster answer than guessing from DAU alone.

• Under ~2,000-3,000 DAU: bidding overhead usually outweighs the lift
• Fewer than 2-3 active ad units: not enough auction volume to matter yet
• Revenue plateaued despite waterfall reordering: the clearest signal it's time to move
• Engineering bandwidth for adapter maintenance: a real prerequisite, not optional

The Hybrid Setup Most Apps Actually End Up Running

In practice, very few of the accounts I work with go straight to a fully bidding-only stack, and I'd argue that's the right instinct rather than a compromise. The more common, and honestly more sensible, setup keeps bidding networks competing against each other in real time while a couple of proven legacy line items sit in the chain as a fallback for whatever the auction doesn't clear.

The mistake I see going the other direction — treating the bidding auction as just another line to insert below your existing top-ranked networks — undersells the whole point. If your best-performing legacy network still sits above the bidding auction by default rather than inside it, you're recreating the exact underpricing problem bidding exists to solve, just with fewer networks affected.

Pace the rollout. Add one or two bidders at a time over four to six weeks, watching eCPM, fill rate, ANR and crash rates, and latency percentiles after each addition rather than flipping everything on at once. If a specific adapter introduces a stability regression, you want to isolate which one caused it, and you can't do that if you added five simultaneously.

One setup I'd point to as a working example: a mid-size trivia app kept two direct-sold, high-value line items above the auction for exactly one placement — a premium rewarded slot with a negotiated floor that consistently outbid the open auction — while every other ad unit ran fully inside the bidding auction with no static line items above it at all. That's the right instinct: keep exceptions rare, evidence-based, and specific to inventory that genuinely earns the exception, not a default assumption applied across the whole app.

Frequently Asked Questions