Back to Blog
Tutorial

AdMob Mediation in 2026: Bidding, Waterfall and Mediation Groups

AdMob Mediation in 2026: Bidding, Waterfall and Mediation Groups

AdMob Mediation is the layer that turns a single ad unit into a competition. Instead of letting one network decide what an impression is worth, mediation sends each ad request to several ad sources — the AdMob Network included — and lets them fight for it. Google's own wording is direct: mediation "helps maximize your fill rate and increase your monetization by sending ad requests to multiple networks". This tutorial walks the full path in 2026: the two kinds of mediation, the five console steps, the adapters and the code, and the failures that quietly cap revenue.

Bidding versus waterfall: the only distinction that matters

AdMob splits mediation into two types, and every other setting is downstream of this choice:

You can run both at once. AdMob calls that a hybrid setup, and the same source may appear as both a bidding and a waterfall source (Overview of bidding). That hybrid is the normal 2026 configuration: bidders establish what an impression is worth, and waterfall entries catch the traffic the auction does not fill.

How a request is filled, in four moves: 1) the ad unit sends a request with targeting such as platform and format; 2) AdMob matches it to a mediation group by targeting, and by priority if more than one matches; 3) the bidding sources in that group hold an auction, and the winning bid is placed into the waterfall according to its eCPM value; 4) the waterfall then runs top-down — if the bidder is not the highest entry, waterfall sources are called first.

Mediation groups, not per-ad-unit settings

Mediation groups are the unit of configuration. They are combinations of targeting that segment your traffic by format, platform, app, ad unit and country, and you set ad sources once on the group instead of repeating the setup for every unit. Two rules decide what happens at request time (About AdMob mediation groups):

Mediation groups do not daisy-chain. You also need a separate group for each ad format, and separate groups for Android and iOS.

The five-step setup

  1. Create an ad unit in AdMob and assign it a format — the container that sends the request and displays the ad.
  2. Set up ad sources, both bidding and waterfall. The type fixes how it bids: bidders bid in real time in one auction, waterfall entries are called in the eCPM order you assign.
  3. Map your ad units. Add the third-party source's own identifiers in AdMob so it can be addressed per ad unit. The details vary by source and live in the partner's account.
  4. Create a mediation group for the format and platform, then attach the ad units and sources. Sources and mappings can also be added while editing the group.
  5. Set up mediation in the app using the SDK plus the network adapters.

Two prerequisites: the ad format must already be implemented in the app (banner, interstitial, native, rewarded or rewarded interstitial), and mediation is not available for every ad source — unsupported ones have to go through custom events.

Adapters and code

Third-party networks reach your app through an adapter. AdMob distinguishes open-source and versioned adapters, both integrated with a single line change in your build file, and the console generates the exact statement for the adapters you tick. Two rules from the developer guide matter more than they look:

Bidding on Android requires Google Mobile Ads SDK (Legacy) 18.3.0 or higher, and the 2026 documentation now carries a parallel set of guides for the GMA Next-Gen SDK. The same three steps — create ad sources, map ad units, build a group — exist for iOS, so plan one mediation group per format per platform.

What breaks, and how it looks

Mediation failures are usually silent. Google names the signature symptom of a bad bidding integration: significantly fewer ad requests reaching that partner than expected, together with a missing a3p parameter on requests after the first (Troubleshoot bidding). Work through this list before blaming the network:

Four details developers find after launch

On iOS there is one more instrument: the adNetworkClassName property of the response info tells you which network actually served a loaded ad — the fastest way to confirm a partner is participating at all.

app-ads.txt: optional, and still worth ten minutes

Authorized Sellers for Apps (app-ads.txt) is an IAB initiative to protect app inventory from ad fraud and app spoofing. It is not mandatory — Google calls it highly recommended — and it is a plain text file listing your authorized sellers, published at the root domain of your app's developer website (Firebase Hosting is a supported alternative if you cannot publish at root). The crawler then verifies it and the status shows in the AdMob console. If your developer site already exists for store requirements, this is a ten-minute task with a direct effect on how much legitimate demand you can receive.

Sources

Running developer accounts at scale? We handle the operational side.

Click to choose a file · right-click → Paste, or press Ctrl/⌘+V to paste a screenshot

You can also drag a file onto this box.

We reply to the email you provide. Your details stay with KappS.

✔ Submitted

We received your message and will reply within 24 hours.

Or email expert@kapps.store
← Back to edit