Ad Mediation: How Bidding, Waterfalls, and Hybrid Auctions Work
Ad mediation is the control layer between an app and multiple ad demand sources. This guide follows one request through the stack, explains current bidding and waterfall mechanics, and turns platform selection, measurement, privacy, and debugging into practical decisions.
What is ad mediation?
Ad mediation is a software and decisioning layer that connects an app's ad inventory to multiple demand sources. When an eligible ad request arrives, the mediator applies the matching configuration, asks bidding sources to compete or calls waterfall sources in order, and returns an ad from a source that can serve.
The mediator does not create demand and it does not guarantee that the nominally highest price becomes a displayed impression. It coordinates SDKs, adapters, ad-unit mappings, auctions, timeouts, privacy signals, and reporting. The result still depends on the user's market, the format, creative eligibility, network demand, technical reliability, and whether the loaded ad is actually shown.
Routing
Match the request
Select the configuration for the app, operating system, ad format, placement, country, and other supported conditions.
Competition
Compare eligible demand
Run a real-time bid process, a sequential waterfall, or a hybrid of both according to the platform's rules.
Operations
Load, show, and report
Coordinate adapters and callbacks, record the serving source, and expose data for revenue and reliability analysis.
Mediation operates on configured ad units and requests. Revenue is recognized only when the platform and serving network count a valid ad impression, so request-level eligibility and impression-level outcomes should not be treated as the same event.
How an ad request moves through mediation
A useful mental model is a pipeline, not a list of networks. Each stage can remove demand, add latency, or create a reporting gap.
Request
The app asks for a banner, interstitial, rewarded, native, or app-open ad for a specific unit.
Match
The mediator selects an eligible group or waterfall using format, platform, app, geography, and priority.
Compete
Bidders return per-request prices while waterfall instances remain ordered by configured or optimized eCPM.
Load
The winning or next eligible adapter attempts to load a creative. Errors or timeouts can move the request onward.
Show
The app displays the loaded ad and receives impression, revenue, click, reward, and close callbacks when supported.
Configuration priority matters before price comparison. Google AdMob, for example, selects the highest-priority matching mediation group when more than one group matches a request. That means an unexpected group match can explain a missing source even when the network, adapter, and eCPM look correct.
Official references: Google's guide to AdMob bidding and waterfall mediation and mediation group priority guidance.
Bidding, waterfall, and hybrid setups
Bidding and waterfall describe how an eligible source gets an opportunity. They are not different definitions of mediation, and a production group can use both.
| Model | Decision signal | Request behavior | Operational tradeoff |
|---|---|---|---|
| In-app bidding | A price returned for this request | Eligible bidders compete in a parallel server-side auction | Less manual pricing, but source support, bid participation, timeouts, floors, and auction rules still matter |
| Waterfall | A manual or optimized average eCPM | Instances are called sequentially until one fills or the chain ends | Supports non-bidding demand, but stale ordering and long chains can add latency and lose opportunities |
| Hybrid | Real-time bids plus waterfall eCPM values | The auction winner is positioned against eligible waterfall sources according to the mediator's rules | Broad demand access, with more configuration and reporting paths to validate |
In AdMob's documented hybrid flow, the winning real-time bid is placed into the waterfall according to its eCPM. A higher-valued waterfall source may still be called first. If a network submits a bid and loses, it is not called again as a waterfall source for that request. If it does not bid, it can remain eligible for its waterfall call when configured there.
Waterfall optimization is not a real-time bid. AdMob documents that it retrieves network reporting data and updates a source's average eCPM and position from historical performance. This reduces manual upkeep, but the ordering signal can still lag a sudden demand shift.
Mechanism references: AdMob bidding FAQ and waterfall optimization documentation.
How to choose a mediation platform
A static ranking of mediation vendors ages quickly. Compare the current documentation and a controlled test against the inventory, formats, countries, engineering capacity, and commercial agreements that your app actually has.
Demand and formats
Verify bidding and waterfall support by network, platform, and format. A logo in a partner list does not prove support for the format you need.
Integration surface
Compare SDK size, adapter versioning, dependency conflicts, release cadence, initialization visibility, and migration effort.
Control and experimentation
Look for geography and placement segmentation, floors, group priority, A/B tests, APIs, and safe rollback paths.
Reporting fidelity
Confirm impression-level revenue availability, timezone and currency rules, API access, source-level errors, and reconciliation workflows.
Privacy and policy
Map consent propagation, partner disclosures, child-directed settings, platform privacy requirements, and creative review controls.
Commercial fit
Review payment paths, account ownership, data access, demand neutrality claims, support terms, and any requirements tied to first-party demand.
Compare current first-party setup details rather than copied vendor counts. Useful examples include AdMob's supported source and adapter guide and AppLovin MAX's current integration and waterfall workflow.
Implementation and launch workflow
Treat mediation as a release that crosses product, engineering, ad operations, analytics, privacy, and finance. Adding network SDKs is only one part of the work.
- 01
Define the inventory
Document each placement, ad unit, format, load trigger, show trigger, frequency rule, reward behavior, and fallback experience.
- 02
Map demand and accounts
Create the correct apps and ad units at every network, record ownership and payment terms, and map identifiers without reusing the wrong environment.
- 03
Integrate SDKs and adapters
Use supported versions, resolve dependency conflicts, initialize after required privacy choices, and wait for adapter initialization before the first mediated request when the platform requires it.
- 04
Configure request rules
Set matching groups, priority, bidding sources, waterfall instances, floors, geography, formats, and any test-specific configuration.
- 05
Validate source by source
Use approved test modes and single-source tests to confirm each adapter can initialize, request, load, display, close, and issue rewards or revenue callbacks.
- 06
Stage the rollout
Release to a controlled traffic slice, reconcile mediator and network reports, monitor user experience, and keep a rollback path before broad expansion.
Google's current Android mediation guide says to wait for Mobile Ads SDK initialization to complete so all adapters can participate in the first request. It also recommends passing an Activity where mediated networks require that context and disabling third-party banner refresh when the mediator already controls refresh. These are examples of why each platform and adapter guide must be checked, not generalized from a single integration.
Implementation reference: Google's AdMob mediation setup guide for Android.
Metrics and decision rules
The goal is not the highest isolated eCPM. It is durable app value after considering monetization, reliability, user experience, and operating cost. Read each metric at the same app, platform, country, format, placement, and time grain before comparing it.
| Signal | Question it answers | Interpretation risk |
|---|---|---|
| Match or fill rate | How often did eligible requests return an ad? | Definitions differ by platform, and a fill can still fail to show |
| Show rate | How often did loaded ads become impressions? | Product timing, caching, navigation, and load failures can sit between load and show |
| eCPM | How much revenue was reported per thousand impressions? | A high eCPM on few impressions may produce less total revenue |
| Latency and error rate | How reliably and quickly did a source respond? | Averages can hide tail latency and source-specific failures |
| ARPDAU or ad ARPU | How much ad revenue did an active user generate? | Format and audience mix can move the metric without improving experience |
| Retention and payer value | Did monetization change the wider product outcome? | Correlation is not incrementality, so controlled experiments are preferable |
Reconcile mediator revenue against each network's report before using a source comparison for pricing decisions. Align timezone, currency, gross or net treatment, ad-unit mappings, and late data. Then connect ad revenue to broader ARPU and retention rather than optimizing a single auction metric.
Use an experiment for consequential changes to sources, floors, ordering, or formats. Google documents that its mediation A/B test splits users between two group configurations, recommends changing one setting at a time, and requires enough traffic before declaring a result. The exact capabilities and thresholds are platform specific.
Experiment reference: AdMob mediation A/B testing guidance. For campaign-side measurement concepts, see SocialPeta's attribution modeling guide.
Privacy, policy, and supply-chain controls
Mediation adds third-party code and data recipients. The app publisher remains responsible for understanding those partners, collecting or honoring required choices, configuring regional and child-directed settings, and keeping store disclosures accurate.
Consent and partner lists
Make the actual mediated partners visible in the relevant consent flow. Pass supported privacy signals before SDKs begin data collection or ad requests.
Platform disclosures
Keep Google Play Data safety, Apple App Privacy details, ATT behavior, privacy manifests, and SDK declarations aligned with the shipped build.
SDK governance
Inventory each SDK and adapter, owner, version, data purpose, destination, required flags, release notes, and removal procedure.
Authorized sellers
Publish and maintain app-ads.txt records for authorized selling relationships where applicable, using entries supplied by each partner.
Google's UMP guidance tells AdMob publishers to add mediation partners to published GDPR messages and warns that omitted partners can fail to serve. On Apple platforms, cross-company tracking may also require App Tracking Transparency permission. See the separate App Tracking Transparency guide for the scope and limits of ATT.
Primary references: Google's GDPR and mediation partner guidance and the IAB Tech Lab's ads.txt and app-ads.txt standards page.
How to troubleshoot no fill and lost revenue
Start at the request and move forward. A dashboard total cannot tell you whether the request matched the wrong group, a bidder declined, an adapter failed, a network timed out, the app never showed the loaded ad, or reports simply use different boundaries.
Integration
- Confirm app and ad-unit IDs
- Check SDK and adapter versions
- Inspect initialization status
- Use approved test devices
Request path
- Verify the matched group
- Inspect bids and waterfall order
- Read source errors and latency
- Run a single-source test
Business result
- Compare load, show, and impression
- Reconcile source revenue
- Segment by app, OS, country, and format
- Check retention and payer metrics
AdMob's ad inspector exposes adapter status, SDK versions, request logs, waterfall details, errors, latency, and single-source testing. Google also warns that mediated ads may not show its Test Ad label, so developers must enable test mode for every network and avoid clicking live ads.
Testing references: AdMob ad inspector overview and mediated test ad guidance.
Ad mediation FAQ
What is mobile ad mediation?
Mobile ad mediation is a control layer that connects an app's ad units to multiple demand sources. For each eligible request, it applies targeting and privacy rules, compares real-time bids or calls waterfall sources in order, and returns an ad from a source that can serve.
Is ad mediation the same as header bidding?
No. Ad mediation is the broader orchestration layer. In-app bidding is one way that sources compete inside it, while waterfall calls are another. A modern mediation group can combine bidding and waterfall sources in a hybrid setup.
Does the highest eCPM always produce the most revenue?
No. eCPM is revenue per thousand impressions, not total revenue or profit. Fill rate, show rate, latency, format mix, session length, retention, reporting differences, and the value of purchases or subscriptions can change the business result.
Can one ad network be used in both bidding and a waterfall?
Sometimes. Platform and network support varies. Google AdMob, for example, documents that a source can be configured in both bidding and waterfall within the same mediation group, with rules that prevent a bidder from being called twice after it submits a bid.
How should a developer test an ad mediation integration?
Use test devices and each network's approved test mode, verify SDK and adapter versions, inspect initialization status, run one ad source at a time, and then test the full request path in the app. Do not click live mediated ads during development.