Mediation Waterfall vs In-App Bidding: The Decision Framework (2026)

Most mobile publishers should run a hybrid stack: bidding for Meta, AppLovin, and Mintegral (which no longer offer meaningful waterfall access), waterfall for direct deals and demand sources where you control the price floor. Pure bidding outperforms pure waterfall when you have diverse demand, scale above roughly 50,000 DAU, and ops capacity to tune the bidding configuration. Below that scale or with niche geo demand, waterfall with well-maintained floors frequently wins. Migration without A/B testing against your current waterfall costs 2-7% of revenue during the calibration period.

What changed after ATT (and why the bidding pitch got louder)

Before ATT, the main argument against waterfall was mechanical: sequential network calls meant the second network never competed with the first. Waterfall had a real structural flaw. But publishers who maintained their stacks well, with current CPM floors and regular network audits, could capture competitive price pressure through smart manual positioning. The structural flaw was real but manageable.

Post-ATT, the pitch shifted. SKAdNetwork's limitations destroyed the user-level targeting data that let demand-side platforms value impressions precisely. In that data-sparse environment, the value proposition of a unified auction changed. If a DSP cannot see individual user attributes, it needs to see as many impressions as possible to let its ML models learn from aggregate patterns. Bidding gives demand partners access to every impression simultaneously. That is the legitimate post-ATT argument for bidding, and it is not a fabrication.

Eric Seufert's analysis in Mobile Dev Memo framed this directly: mediation became the "primary front in the mobile advertising wars" post-ATT because the mediator aggregates user-value signal across publishers that no individual demand partner can access. This is why AppLovin pursued MoPub's publisher relationships and why Unity acquired ironSource. These were data acquisitions as much as supply acquisitions. The mediation layer holds the signal; whoever controls the mediator has first-mover access to it.

What this means for publishers is specific. The bidding pitch is louder post-ATT partly because the structural value of unified auctions genuinely improved in a low-signal environment, and partly because the networks pushing bidding hardest (AppLovin, Meta, Mintegral) are the ones whose ML models are large enough to benefit most from impression-level competition. A network running a thin ML model does not get meaningfully smarter by seeing more bids per second. The post-ATT bidding argument applies strongest where the ML is deepest.

For smaller demand partners, the waterfall price floor mechanism still functions. Those networks are not running better ML inference in a real-time auction. A well-set floor for a regional or mid-tier network captures most of the available CPM just as reliably as a bid request. The ATT shift did not make bidding universally better. It made bidding better specifically for demand partners with the ML infrastructure to use the signal.

For the full post-ATT attribution context, see SKAdNetwork 4.0 Conversion Value Setup.

How waterfall actually works today (not a history lesson)

A live waterfall in 2026 has three levers that matter. The static CPM floor you set for each network at each tier. The country-level segmentation of those floors. The fallback fill order when a higher tier declines. Everything else is configuration details.

The structural property that waterfall defenders understate: the publisher controls the price. If AdMob historically pays $8 CPM for a specific placement in the US, you set the waterfall tier at $7.50 and AdMob fills most of the time, at a price you chose. Bidding removes that control and replaces it with auction dynamics. For publishers who have done this manual optimization well, handing that control to an auction is not obviously an improvement.

The structural property that waterfall critics correctly identify: the CPM floor is historical, not real-time. If an impression is worth $12 today because there is an advertiser in market for your specific user, but your floor is set at $8, you leave $4 on the table. Bidding captures that $4. A well-run waterfall never does.

Both of those properties are real and both matter. The question is which one dominates for your specific stack at your specific scale.

Unity's published guidance on waterfall configuration covers the mechanics that most operators get wrong: price point spacing (keep tiers at least $0.25 apart to avoid redundant fills), update cadence (not more than once every 3 days per tier to avoid signal noise), and multi-tier placement of individual networks at high, medium, and low price points to maximize fill across CPM buckets. Publishers who are following this guidance have a functional waterfall. Publishers who set it up 18 months ago and have not touched it since are not running a waterfall. They are running a decayed waterfall, and comparing a decayed waterfall to a fresh bidding setup is not a fair comparison.

The ops cost is real. A well-maintained waterfall requires someone to review floors at minimum monthly, ideally weekly for high-revenue placements. Country-level floors need updating as seasonality shifts eCPMs. New networks need to be placed at the right tier, not just added at the bottom. This is manageable with a dedicated monetization resource. It is less manageable for a two-person studio.

If your waterfall has not been reviewed in the last 90 days, the comparison you are making to bidding is probably not fair to your current setup. A structured audit of your existing waterfall is the right starting point before any migration decision. The Mediation SDK Checker is a useful first pass on the technical side before going deeper.

How in-app bidding actually works today

The mediator's role in bidding is different from what most publishers think. In a waterfall, the mediator calls networks one at a time. In bidding, the mediator broadcasts a bid request to all participating demand partners simultaneously, collects bids within a time window (typically 500-1,000ms), runs the auction, and calls the winning network's SDK to load the ad. The mediator is no longer a passive sequencer. It is an active auctioneer with control over who participates, what data is shared, and how the auction clears.

Server-side vs in-app is a distinction worth understanding. True in-app bidding means the bid request originates from the device. Some "bidding" implementations route through the mediator's server, which changes latency characteristics and the data available to bidders. AppLovin MAX's bidding and Google's open bidding both use server-side auction orchestration. The label "in-app bidding" gets used for both, but the mechanics differ.

Time budget matters for specific formats. Bidding adds a server round-trip to the ad loading path. On poor network conditions or high-latency regions, that round-trip is costly. For rewarded video, where the user is already in a loading state, the latency cost is lower. For banner placements where a slow load means a missed impression, the latency cost is material. Format and geography both affect whether the latency tradeoff is worth taking.

Which networks actually participate in bidding is the variable that determines whether the auction is competitive. Meta Audience Network, AppLovin, Mintegral, and Google via open bidding are the primary bidding participants with enough demand depth to make the auction work. A bidding setup with only one or two participating demand sources is not a competitive auction. It is a first-price sale to the only bidder in the room. For that situation, a well-set waterfall floor may outperform the auction simply because the single bidder knows it has no competition.

The calibration period is the fact that bidding platforms do not lead with. Bidding ML models need impression data to calibrate. A publisher migrating a placement from waterfall to bidding will typically see a revenue dip in the first 2-4 weeks while the bidding models calibrate on new impression signals. This is not a bug. It is structural. But it is also not usually disclosed upfront by the platform advocating for the migration.

For the platform comparison, see AppLovin MAX vs Unity LevelPlay and AdMob Mediation vs AppLovin MAX.

The honest revenue swing

Vendor content universally presents bidding as a revenue improvement. The honest picture is more specific.

Bidding outperforms waterfall when three conditions are met: diverse, competitive demand from multiple bidding partners; sufficient scale for bidding ML models to calibrate (roughly 50K or more DAU, or 10K or more ad impressions per day per placement); and geography where bidding demand is deep. US, UK, Western Europe, and Australia qualify. Most of Southeast Asia, LATAM, MENA, and Eastern Europe do not.

Waterfall outperforms or matches bidding when those conditions are not met. Niche or tier-2/3 geo-focused apps where bidding demand is thin and a well-set floor captures most available CPM. Apps with small DAU where bidding models cannot calibrate on the available signal. Placements where a direct deal or a specific high-CPM network relationship is better captured through waterfall priority.

Real data makes this concrete. GameBiz Consulting's published A/B test results from 2024 client testing show switching specific network instances from waterfall to bidding produced ARPDAU decreases of 2.5%, 3%, 3.5% on UnityAds instances, and 7.3% on an AdMob hybrid instance. The same analysis found that non-bidding networks still generate 42% of iOS revenue and 34% of Android revenue for the publishers tested. That is not a rounding error. Those networks still require waterfall optimization to capture competitively.

The 20-50% revenue swing that circulates in industry benchmarks reflects a specific comparison: a badly maintained waterfall (wrong floors, missing networks, no country segmentation) against a well-configured bidding setup with three to four competitive bidding demand partners. That comparison is real. It just is not the comparison most publishers are actually making. A publisher migrating from a well-optimized waterfall to a bidding setup with thin demand and no calibration period can see a drop of similar magnitude in the other direction.

The honest framing: bidding is not categorically better. It is better when you have the demand depth, scale, and configuration quality to make the auction competitive. When those conditions are not met, a well-maintained waterfall is not a fallback position. It can outperform.

The decision framework

This section is a framework with explicit criteria. The conditions point to specific outcomes. "It depends" is not the answer here.

Variable 1: Revenue scale (DAU and daily impressions)

Below 10K DAU: bidding models cannot calibrate on the available signal. Bidding is unlikely to outperform a well-set waterfall for the bulk of your demand. The right call: waterfall with maintained floors, add bidding only for Meta and AppLovin since those networks require bidding to access competitively anyway.

10K-50K DAU: calibration is possible but slow. A full stack migration at this scale is high-risk during the calibration period. The right call: hybrid. Bidding groups for the major networks that require it, waterfall for everything else. Do not migrate the full stack.

Above 50K DAU: full bidding is viable if demand mix is diverse. The auction becomes competitive at this scale. Hybrid or full bidding are both defensible depending on ops capacity and demand mix.

Variable 2: Demand mix

If more than 60% of your revenue comes from one network: bidding is unlikely to help that relationship. That network is already dominant. A competitive auction requires multiple competitive bidders. A single dominant network bidding against sparse competition is not an auction. Waterfall with that network prioritized is the right structure, with bidding groups only for demand partners that require it.

If you have four or more active demand partners generating meaningful revenue: bidding becomes useful. Competition across those partners in a real-time auction is where bidding earns its price premium over waterfall.

If any of your top three networks are Meta, AppLovin, or Mintegral: those networks offer bidding as their primary product in 2026. You are either running bidding for them or leaving competitive demand on the table. This is not a choice about architecture. It is a condition of accessing their demand.

Variable 3: Geography

US, UK, Western Europe, Australia, Canada: bidding demand is deep. Unified auction is competitive. Bidding adds value.

Tier-2 and tier-3 geos (Southeast Asia, LATAM, MENA, Eastern Europe): bidding demand is thin. Fewer demand partners bid, and those that do have less campaign budget allocated. A well-set waterfall floor in these geos often captures more revenue than a sparse auction with two bidders and no floor competition.

Mixed-geo app: hybrid is the correct structure. Bidding groups for US and tier-1 traffic, waterfall for tier-2 and tier-3 geo segments. Do not run the same configuration across all geos.

Variable 4: Ops capacity

No dedicated monetization resource: bidding is operationally lighter once configured. You give up price-floor control but you also give up the maintenance burden. Bidding is defensible for indie developers and small teams where the waterfall would otherwise decay.

Dedicated monetization team: waterfall maintenance is feasible. A well-maintained waterfall competes with or beats bidding at most scales below 50K DAU. You have the capacity to keep the comparison honest.

Summary matrix

Small app (below 10K DAU), US-focused, no ops team: Recommendation: Full bidding for Meta, AppLovin, Mintegral. Waterfall for remaining demand.

Mid-size app (10K-50K DAU), mixed geo, some ops capacity: Recommendation: Hybrid: bidding groups for tier-1 geos and bidding-only networks, waterfall for tier-2 geos and demand with direct relationships.

Large app (above 50K DAU), diverse demand, dedicated team: Recommendation: Full bidding is viable and likely optimal if demand mix has four or more competitive bidding partners.

Any size, niche geo (tier-2/3 primary), one dominant network: Recommendation: Waterfall with that network prioritized. Bidding groups only for demand partners that require it.

The framework does not resolve every edge case. But if you apply the four variables to your actual stack, not to an abstract app, you get a recommendation, not a discussion.

Hybrid setups: the actual production reality

Most real production stacks in 2026 are hybrid. This is not widely acknowledged in the content on this topic because vendor content wants to describe a clean migration from one state to another. The production reality is messier and more functional than that.

Google's AdMob documentation explicitly supports hybrid mediation groups, with bidding and waterfall sources in the same mediation group. AppLovin MAX supports bidding and waterfall in the same waterfall stack. Unity LevelPlay migrated toward bidding as its default but still supports waterfall configuration. The platforms that are most loudly advocating for bidding all support hybrid configurations, which tells you something about what their production publishers are actually running.

The hybrid architecture in AdMob works like this: you create a mediation group, add bidding sources and waterfall sources. Bidding sources compete in the auction. If no bidder clears the floor, waterfall sources run in CPM order. This is the most common hybrid configuration for AdMob publishers. The floor between the bidding group and the waterfall sequence is the critical configuration variable. Set it wrong and you are selling bidding impressions below what your waterfall would have captured.

AppLovin MAX's hybrid model runs bidding competition first for bid-enabled demand, then falls to waterfall instances for demand that does not bid. This is the default behavior for most MAX publishers, including many who describe themselves as running "full bidding." They are running hybrid. The waterfall positions for direct deals and non-bidding demand are still live.

The hybrid is not a compromise. For most publishers, hybrid is the right architecture, not a transitional state on the way to full bidding. Waterfall positions for direct deals and demand relationships where you control the floor are a real revenue lever. Bidding positions for Meta, AppLovin, and Mintegral are a real revenue lever. Combining them is not a failure to commit. It is the correct production configuration.

The configuration detail that breaks most hybrid setups: bidding floor prices set below the waterfall's highest tier. If your waterfall has a top tier at $8 CPM for US traffic and your bidding group has no floor, you are selling bidding impressions to whoever shows up, at whatever they offer. Set bidding floors at or above your waterfall's top tier for each geo segment. For the SDK and adapter version discipline that underpins a clean hybrid setup, the full reference is the Mediation SDK & Adapter Compatibility Guide.

Why bidding vendors push bidding so hard

No vendor article will write this section. That is exactly why it belongs here.

The structural argument for bidding is true: competitive auctions produce better prices than sequential calls, when the auction is genuinely competitive. Publishers benefit from that price competition. That part is not a fabrication.

But bidding is also better for the mediator, and the mediator's incentives are not identical to the publisher's incentives.

In a waterfall, the publisher sets the price. Each network fills at the CPM floor the publisher set or declines. The mediator is a routing layer. In a bidding auction, the mediator controls the auction rules: which demand partners participate, what data is shared with bidders before the auction, how the floor is set, and how the auction clears. The mediator is no longer a routing layer. It is the market maker, and market makers always have structural advantages.

AppLovin is the clearest example. AppLovin MAX is a mediator. AppLovin is also a demand-side platform. When MAX runs a unified auction, AppLovin demand is a first-party participant. That first-party demand has structural advantages: it has better signal on MAX publisher inventory because it is also operating the mediator. It can use impression-level publisher data in its bidding models that third-party DSPs cannot access through the same auction. This is not a secret. Eric Seufert named it directly: AppLovin's pursuit of MoPub's publisher relationships and Unity's ironSource acquisition were data acquisitions, not just supply acquisitions. The mediator position is the data position.

Google's structural position is the same. AdMob mediation routes open bidding participation through Google's servers. Google demand has first-mover access to impression data at the server level before third-party demand partners see the bid request. The architecture is neutral in design and advantageous to Google in practice.

The take-rate reality compounds this. In a waterfall, the publisher sets the price and networks pay it or decline. The transaction is relatively transparent. In a bidding auction, the mediator controls the clearing mechanism and takes a margin. The publisher's gross CPM and the network's payout to the publisher may differ, with the mediator capturing the spread. This margin is not always published. It is also not the primary reason to avoid bidding, but it is a real structural feature of the market that operators should price into their analysis.

None of this means bidding is wrong for publishers. The competitive auction still benefits publishers in many cases, particularly at scale with diverse demand. But publishers should understand that bidding is not a neutral technical upgrade. It is a structural shift in market power toward the mediator. The mediator's advocacy for bidding reflects that shift. A vendor-neutral framework for this decision has to name it.

Network-by-network state in 2026

Publishers need to know which networks offer a meaningful waterfall channel in 2026 and which have effectively moved to bidding. The choice between waterfall and bidding is partly a choice about which networks you can access through each channel.

Bidding-only or near-bidding-only

Meta Audience Network moved to bidding as the primary access model. Waterfall CPM integration still technically exists, but Meta's own demand supply prioritizes bidding inventory. Publishers not running Meta bidding are not getting competitive Meta demand. They are accessing Meta's secondary pool.

AppLovin's primary publisher product in 2026 is MAX with in-app bidding. Their waterfall network adapter still exists, but AppLovin's UA buyers run through the bidding channel. Waterfall-only AppLovin access leaves significant demand unreachable. For a full comparison of how AppLovin MAX approaches this relative to its competitors, see AppLovin MAX vs Unity LevelPlay.

Mintegral's primary publisher channel is in-app bidding. Their performance in waterfall placements has declined materially as their demand-side budget shifted to real-time bidding campaigns. Running Mintegral in a waterfall position gives you access to their secondary demand, not their competitive real-time inventory.

IronSource (Unity LevelPlay) migrated toward bidding as its default. Waterfall configuration is supported but IronSource's buyer base increasingly runs through bidding channels.

Dual access (waterfall and bidding both meaningful)

Google AdMob direct (not open bidding) still carries material revenue through waterfall, particularly for publishers with AXON-eligible inventory. AdMob continues to support both configurations, and the waterfall instance for AdMob direct still delivers meaningful CPMs for publishers who maintain it. For the AdMob-specific configuration questions, the Mediation SDK Checker is a useful starting point.

Digital Turbine (DT Exchange) supports both waterfall and programmatic channels. Waterfall access remains viable for mid-tier publishers.

Waterfall-primary (bidding still limited)

Smaller regional networks including Yandex, InMobi, and Vungle direct continue to operate primarily through waterfall in most geographies. Their bidding adoption is partial or limited to specific ad formats.

The practical implication is important to state clearly: a publisher "choosing waterfall" in 2026 is not choosing to exclude Meta, AppLovin, and Mintegral. Those networks require bidding to access competitively. Choosing waterfall means choosing how to configure demand that still offers meaningful waterfall channels. That is why hybrid is the production reality. You run bidding for the networks that require it and waterfall for those that do not.

Measuring the migration

Do not switch a full stack from waterfall to bidding without a measurement plan. The revenue signal during the calibration period is noisy and easy to misread in the wrong direction.

The canary release pattern: migrate a single ad unit or a single geo segment first. Run the bidding configuration on that unit while the rest of the stack stays on waterfall. Compare per-unit eCPM and fill rate for the bidding unit against a matched control unit that stays on waterfall. Run for a minimum of 14 days. Bidding models typically take 7-14 days to calibrate. Data from days 1-7 is pre-calibration noise.

What to watch: per-network fill rate (not total fill rate), per-network eCPM, and overall ARPDAU for the affected segment. A drop in per-network fill rate during calibration is expected and normal. A sustained drop after day 14-21 is a signal that the bidding demand is thinner than expected for that placement at that scale. That is the diagnostic: not whether there is a dip, but whether the dip persists past calibration.

AppLovin MAX has a built-in A/B testing tool for mediation group configurations. Use it for a controlled waterfall-vs-bidding comparison rather than a hard cutover. The tool splits traffic between configurations and reports comparative eCPM and fill rate by group. This is the right instrument for a migration decision. A hard cutover and a revenue comparison on day 3 is not.

Google's mediation report provides per-source eCPM and fill rate. After migrating to bidding, watch these metrics at the ad source level, not just the aggregate. A bidding setup with lower overall eCPM but higher fill rate may or may not be a net revenue improvement depending on how much fill rate delta you are capturing and at what CPM. Total eCPM is a misleading single metric for this comparison.

The per-network signal is the diagnostic tool, not total eCPM. If bidding improved Meta and AppLovin fill but dropped AdMob waterfall fill because the floor was misconfigured, total eCPM will give you a blended number that obscures both the win and the problem. Always evaluate per-source and per-format before drawing a conclusion.

Budget for 2-4 weeks of modestly lower revenue on the migrated placement during calibration. Publishers who do not budget for the calibration period, see a dip on day 3, roll back, and then conclude "bidding does not work" have not run a bidding test. They have run a precalibration snapshot. The conclusion is wrong because the test was too short.

Before running the migration comparison, audit your AdMob mediation configuration with the Mediation SDK Checker to confirm the technical baseline is solid.

When to stay on waterfall

The contrarian case is real, not a theoretical hedge. There are specific conditions under which staying on waterfall is the correct production choice, and most vendor content will not name them.

Stay on waterfall (or stay primarily waterfall with bidding only for networks that require it) if any of these conditions apply to your stack:

Your DAU is below 10K and your top revenue network is not a bidding-only source. The auction has no depth at that scale. A well-set floor captures more value than a sparse auction with one or two bidders who know they have no competition.

More than 50% of your revenue comes from a single network that you have a direct relationship with. That relationship is better managed in a waterfall where you control the prioritization. A competitive auction cannot help you when there is only one serious bidder. Running bidding for a single dominant network adds complexity and latency without adding competition.

Your primary geography is tier-2 or tier-3. Bidding demand in Southeast Asia, LATAM, MENA, and Eastern Europe is thin. Well-set waterfall floors in those geos frequently outperform what a sparse bidding auction delivers, because the bidding auction has fewer participants and less budget behind them.

Your app has irregular session patterns that make bidding ML calibration slow. Seasonal or event-driven apps may be better served by waterfall floors that can be manually updated for peak periods. A bidding model that calibrates on off-season traffic will perform poorly during peak if the traffic distribution shifts materially.

Your existing waterfall is performing well and has been maintained recently. The cost of a 2-4 week calibration period is real. Migrating a stack that is already performing at or near its ceiling to prove a point about bidding is an unnecessary risk. If the waterfall is well-maintained and producing competitive eCPMs, the burden of proof is on the migration to show incremental value, not on the waterfall to justify staying.

What "well-maintained" means in practice: floors updated at minimum monthly, country-level segmentation in place, all active networks on their current SDK and adapter versions (the full reference is in the Mediation SDK & Adapter Compatibility Guide), and fill rate monitored per network per format. A waterfall that has not been touched in six months is not a well-maintained waterfall. It is not a fair benchmark for bidding comparison.

If you are not sure whether your waterfall is actually well-maintained or if it has quietly drifted since the last time someone looked at it, that is the kind of structured audit that pays for itself in the first month. The free initial conversation is the right starting point. Book a free 30-minute call.

Frequently Asked Questions

What is the actual revenue difference between waterfall and in-app bidding?

There is no fixed number. Real-world A/B tests from operators show bidding can improve ARPDAU materially when there are multiple competitive bidding demand partners and sufficient scale (roughly 50K or more DAU per placement). The same tests show decreases of 2.5-7.3% on specific placements when demand is thin or when the bidding configuration is wrong. The 20-50% revenue swing claim in the industry reflects the difference between a badly maintained waterfall and a well-configured bidding stack, not a clean head-to-head comparison at the same configuration quality. Bidding is not categorically better. It is better when you have the demand depth and scale to make the auction competitive.

Should I run waterfall and in-app bidding at the same time?

Most production stacks in 2026 already do this, whether or not publishers call it a hybrid. Meta, AppLovin, and Mintegral require bidding to access competitively, so those demand partners belong in the bidding group. AdMob direct, smaller regional networks, and any direct deals go in the waterfall group. The mediator (AdMob, MAX, LevelPlay) supports both in the same mediation configuration. The key configuration detail: set bidding floors at or above your waterfall's top tier so you are not selling bidding impressions below what your waterfall would have captured.

Which networks still offer waterfall mediation in 2026?

Google AdMob direct (not open bidding) still carries material revenue through waterfall, particularly for publishers with AXON-eligible inventory. Digital Turbine and several regional networks including InMobi, Yandex, and Vungle direct offer waterfall access. Meta, AppLovin, and Mintegral have effectively moved their primary demand supply to bidding channels. Running those networks in a waterfall position means you are accessing their secondary demand pool, not their competitive real-time inventory. The practical consequence: most publishers in 2026 run a hybrid stack whether they intend to or not, because the networks worth accessing require it.

Why do mediation platforms push in-app bidding so hard?

Because bidding is also better for them, not only for publishers. In a bidding auction, the mediator controls the auction rules: which demand partners participate, what data is shared, and how the auction clears. A mediator that also operates a demand-side platform (AppLovin MAX combined with AppLovin DSP, AdMob combined with Google Ads) has structural advantages in its own auction. Their first-party demand has better signal on inventory because they also run the mediator. The publisher's shift from waterfall to bidding is a real revenue opportunity in many cases, but it also shifts market power toward the mediator and concentrates revenue flow toward the mediator's preferred demand partners.

How do I A/B test a waterfall to in-app bidding migration without breaking my revenue?

Migrate one ad unit or one geo segment, not the full stack. Run the bidding configuration on that unit while the rest stays on waterfall. Use a matched control unit (same format, same placement, similar traffic) and run the test for at least 14 days, since bidding models take 7-14 days to calibrate and pre-calibration data is misleading. AppLovin MAX has a built-in A/B testing tool for mediation groups. AdMob's mediation report gives per-source eCPM and fill rate. Budget for a calibration dip in the first two weeks and do not roll back based on day-3 noise.

Is in-app bidding always better than waterfall?

No. Bidding outperforms waterfall when you have multiple competitive demand partners, sufficient scale for bidding ML models to calibrate (roughly 50K or more DAU), and geography where bidding demand is deep. Below those thresholds, or when your primary demand partner still offers meaningful waterfall access, a well-maintained waterfall with correctly set floor prices is a valid production choice. The operators most likely to see bidding underperform are those with small scale, niche geo focus, or a dominant single-network revenue concentration where a competitive auction is structurally impossible.

When to bring someone in

The waterfall vs bidding question is not a product decision. It is a stack architecture decision that depends on your specific demand mix, scale, and ops capacity. Getting it wrong costs real revenue in either direction: an unnecessary migration from a well-maintained waterfall burns 2-4 weeks of calibration losses for no incremental gain. Staying on a decayed waterfall when the conditions for bidding are clearly met leaves real money in the auction that you are not collecting.

Most publishers asking this question do not have the benchmark data to know which side of that line they are on. Vendor benchmarks are not useful here because they are not running your stack against your demand mix. The comparison that matters is your actual waterfall config against a properly configured bidding setup at your actual scale and geo mix.

If you want to run that comparison against your real numbers rather than against a case study written by someone selling you a bidding platform, that is what the free initial conversation is for. Book a free 30-minute call.