What is the difference between a mediation adapter and a mediation SDK?

The mediation SDK (such as Google Mobile Ads SDK or AppLovin MAX SDK) is the platform you integrate into your app. The mediation adapter is a separate package that connects that platform to a specific ad network. You integrate one mediation SDK. You add one adapter per network you want to monetize with.

Do I need to initialize mediation adapters separately, or does the mediation SDK handle it?

The mediation SDK handles initialization when you call it at app startup, but several adapters require manual initialization before the first ad request. If you skip this step, the adapter initializes on the first ad call instead, which delays fill and causes missed impressions early in a session. AdMob publishes which networks require manual initialization in their mediation setup guide.

Does adding more mediation adapters always increase revenue?

Not automatically. Each adapter adds to app binary size and introduces an additional network SDK dependency to maintain. If a network's demand is already flowing through another adapter in your stack via a shared trading desk, adding a second route rarely increases revenue and increases complexity. Add adapters that cover demand sources not already represented in your auction, or that unlock in-app bidding for networks your current setup runs as waterfall only.

What causes a mediation adapter to stop delivering ads without an obvious error?

The most common causes are: adapter version incompatible with your current GMA SDK version, network not configured in the mediation dashboard despite the adapter being present in the app, privacy or consent signal triggering restricted mode on that network, or an account-level issue on the ad network side such as a payment hold or policy flag. Check the mediation test suite first. If the adapter initializes successfully but fills at 0%, the issue is almost certainly dashboard configuration or account status, not the adapter itself.

What changed with mediation adapters on iOS in 2025?

In September 2025, Google announced that all Google Mobile Ads mediation adapters now support distribution via Swift Package Manager. CocoaPods still works, but SPM is now the current standard for iOS dependency management. If you maintain an iOS app and have not migrated, your existing CocoaPods integration continues to function but new adapter versions may arrive via SPM first.

Is there a meaningful difference between AppLovin MAX and AdMob for mediation?

Yes. AdMob is better suited for apps with diverse geo distribution, web publisher crossover, or heavy reliance on Google demand. AppLovin MAX is generally stronger for gaming-focused apps with high rewarded and interstitial volume, particularly in US and Asian markets, because MAX's in-app bidding auction typically yields stronger results on gaming-specific demand. Many larger apps run both and test placement by placement. If you are choosing one early, the decision depends more on your app category and top-revenue geos than on the platforms themselves.

Mediation Adapters Explained: What They Are, How They Work, and Which Networks to Use

If your mediation dashboard says a network is configured but its fill rate is consistently zero, you're looking at an adapter problem in roughly 90 percent of cases. Adapters are the translation layer between your mediation platform (AdMob, MAX, LevelPlay) and each network's SDK. They're also where silent failures live: version mismatches, consent signal drops, manual initialization misses, mediation group misconfiguration. Most "my mediation broke" issues are adapter issues.

How adapters fit into your mediation chain

Three pieces have to be present and version-compatible for any mediated network to serve impressions: your mediation SDK (GMA SDK for AdMob, MAX SDK for AppLovin), the network's main SDK, and the adapter library that translates between them. Each network publishes its own adapter for each major mediation platform. The adapter's job is to convert your mediation's standardized request ("banner of this size, this user, this floor price") into whatever shape the network's SDK expects, then translate the response back.

When any of those three pieces is missing, out of date, or misconfigured, the failure mode is silent. Dashboard says network is enabled. Fill rate report says zero impressions. Nothing throws an error. You only find out by comparing expected revenue against actual, which most teams aren't doing per-network in real time.

Why mediation can break silently

This is the section the Reddit threads on r/admob keep asking about. Every developer running mediation hits some variation of these issues, and Google's own docs don't cover them clearly.

Version mismatches

The most common failure. AdMob requires a specific Google Mobile Ads SDK version. Each network's adapter requires a specific range of Google Mobile Ads SDK versions plus a specific range of the network's own SDK versions.

When any of those gets out of alignment, the adapter loads but the network calls fail. No error in the logs. No warning in the dashboard. Just silent zero fill.

The fix is always to check the network's adapter release notes (usually on GitHub or in Google's mediation networks page) and align: GMA SDK version, network SDK version, adapter version. All three need to be in their compatible range.

Adapter present but mediation group not configured

You install the SDK. You install the adapter. You assume mediation will start serving the network. It won't. AdMob mediation needs the network added as an ad source in the specific mediation group that your ad unit is in.

Common setup: the network is configured in mediation group A, but the ad unit you're testing is in mediation group B. The dashboard shows the network as configured. The mediation group for your ad unit doesn't have it.

The fix is to walk the chain explicitly: which ad unit, in which mediation group, with which ad sources, in which order. AdMob's UI obscures this by default.

Post-GDPR, post-ATT, post-DMA, your mediation platform needs to pass consent signals to each network. If your CMP isn't passing the right TCF string, or your IDFA prompt logic isn't capturing the right consent state, networks that require consent get suppressed.

Symptom: strong fill in non-GDPR markets, near-zero fill in EU. Every developer I've seen hit this assumes their mediation is broken. It's not. The networks are correctly suppressing demand because they didn't get the consent signal they need.

The fix involves checking your CMP integration, the TCF string your app passes to the GMA SDK, and whether each network's adapter is reading consent correctly. This is multi-layer debugging.

Manual initialization requirements

Some networks require manual initialization at app startup before they'll serve ads via the mediation chain. AdMob assumes the GMA SDK initializes the network adapter chain automatically, but several networks need an explicit initialization call (their own SDK init, sometimes their consent setup) before the adapter responds.

If you don't add the manual initialization, the network adapter is technically loaded but the network SDK isn't ready, so requests fail.

This is one of the issues that surfaces on r/admob regularly: "I configured everything but Meta Audience Network isn't showing up." Almost always it's the manual init.

Adapter test mode behavior

Adapters in test mode often behave differently than in production. Test ads serve from cached test creatives, not from real demand. Some networks return test fills regardless of actual configuration, which can mask underlying setup problems.

The fix is to test in test mode for SDK integration validity, then test in production mode (with a small user segment) before assuming the integration works at scale.

Network capability comparison

The most useful thing this article can show is what each major mediation network supports. Note: I'm deliberately keeping this table capability-focused rather than version-specific. Specific SDK and adapter versions change every few weeks. For current versions, always check the network's official documentation or GitHub releases. A static table with versions in a blog article goes stale within months.

AdMob (Google's own): Open source adapter: No (Google's own) · In-app bidding support: Yes (Google bidding) · Open Measurement SDK: Yes (built-in) · Best for: Apps starting with Google demand, AdMob mediation

AppLovin MAX: Open source adapter: Adapter open, SDK closed · In-app bidding support: Yes (real-time bidding) · Open Measurement SDK: Yes · Best for: Apps wanting MAX's bidding network and analytics

Unity LevelPlay (formerly ironSource): Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Gaming apps, Unity ecosystem integration

Meta Audience Network: Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Apps with strong social/lifestyle audience overlap

Pangle: Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Apps with non-Western traffic, video-heavy formats

Mintegral: Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Gaming apps, especially in Asia-Pacific markets

Vungle (now Liftoff Monetize): Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Performance-focused gaming, video and rewarded

Chartboost: Open source adapter: Adapter open · In-app bidding support: Limited · Open Measurement SDK: Yes · Best for: Gaming-specific, smaller publisher fit

InMobi: Open source adapter: No · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Apps with India-region traffic and emerging-markets focus

Smaato: Open source adapter: Adapter open · In-app bidding support: Yes · Open Measurement SDK: Yes · Best for: Apps wanting open-source-friendly demand

For specific versions of each network's SDK and adapter, check their official docs or Google's mediation networks page. Versions change every few weeks across the industry. We're working on a live tool to track current versions automatically. Until that ships, the network's own documentation is the source of truth.

When to add a new mediation adapter

The decision isn't "more adapters = more revenue." It's "does this specific adapter add demand that's not already in my stack?"

Add a new adapter when:

You have a clear gap in your demand mix. Heavy non-Western traffic and no Pangle or Mintegral is a gap. Heavy gaming traffic and no Unity LevelPlay or AppLovin MAX is a gap. Heavy lifestyle audience and no Meta Audience Network is a gap.
Your existing adapters are saturated. If your top-bidding networks are filling 95+ percent of impressions, adding another adapter doesn't help. If they're filling 60 percent and the rest is going unfilled or to fallback, a new adapter might capture some of that gap.
The network supports in-app bidding and your mediation can use it. Adding a static-CPM waterfall adapter is lower-leverage than adding a bidding-capable adapter that competes in real time.
Your geo mix favors a network you're not currently running. Pangle has strong APAC demand. InMobi has strong India demand. If your traffic is concentrated where a specific network has bid density, that's the case for adding it.

When to remove a mediation adapter

This is the question almost no developer asks but most should. Adapters that aren't earning their place add SDK weight, increase initialization time, and complicate debugging without contributing revenue.

Remove an adapter when:

It's been live for at least 30 days and contributes less than 2 percent of mediation revenue. The integration overhead isn't worth it.
It's the source of crash reports or initialization timeouts. Your app's stability matters more than 1 percent of incremental fill.
The network has been suppressed by consent failures for 60+ days and the fix is non-trivial. If the network can't get consent signals reliably, the adapter is dead weight.
You added it for a specific format (rewarded video, native) that you've since stopped using. Adapters scoped to formats you don't ship are pure overhead.

The decision rule: if removing the adapter would cost you less than 2 percent of net revenue and would simplify debugging or reduce SDK init time, remove it. The mediation industry's default cultural assumption that "more bidders = more money" stops being true after 4 to 5 well-tuned bidders. The 6th and 7th adapters often aren't earning their place.

How to test if a new adapter is actually working

Don't trust the dashboard saying it's enabled. Test directly.

The straightforward diagnostic, after adding an adapter:

Run a 14-day test in production with a small user segment (10 to 20 percent of traffic via Firebase A/B or your own server-side flag). The control segment runs without the new adapter. The test segment runs with it.
Compare net RPM, not fill rate or eCPM in isolation. Net RPM accounts for the actual revenue impact across your entire stack. A new adapter that wins impressions at high CPM but cannibalizes your existing adapters' wins might show flat or negative net RPM.
Check per-format performance. A new adapter might add 30 percent to interstitial revenue and zero to banner. If your inventory is mostly banner, that adapter doesn't help. If it's mostly interstitial, it does. Format-level analysis matters.
Check geo-level performance. Run the same comparison by geography tier. The lift in Tier 1 markets often differs significantly from Tier 3.
After 14 days, calculate incremental net revenue. If the adapter contributed under 2 percent of net revenue across your real traffic, consider removing it. Integration overhead isn't free.

This is the test most teams skip. Adapters get added, not removed. The dashboard says they're working. The net RPM doesn't show the real impact. After two years you have 8 adapters and 4 of them aren't earning their place.

Common mistakes when integrating adapters

Across stacks I see, the same handful of issues:

1. Adding adapters without removing failed ones. SDK bloat is real. App size, initialization time, and crash surface area all grow with each adapter. Periodically prune.

2. Trusting the dashboard over the data. AdMob's dashboard shows networks as "configured." It doesn't tell you whether they're actually serving meaningful volume. Check the per-network revenue contribution every quarter.

3. Skipping the consent signal verification. Every adapter that needs GDPR or ATT consent has its own way of reading the signal. If your CMP integration is wrong for one network, it's probably wrong for several. Audit the consent path during every quarterly review.

4. Updating the GMA SDK without checking adapter compatibility. The Google Mobile Ads SDK updates regularly. Several adapters break or under-perform until their own next release matches the new GMA SDK. If you upgrade GMA SDK and revenue drops, check whether one of your adapters is in a known-incompatible state with the new version.

5. Treating waterfall adapters as bidding adapters. A network that supports both should be configured for in-app bidding mode if your mediation platform supports it. Static-CPM waterfall adapters are the older path and capture less revenue. The configuration choice matters more than the network choice.

Frequently asked questions

What is a mediation adapter and why do I need one?

A mediation adapter is the code library that lets your mediation platform (AdMob, AppLovin MAX, Unity LevelPlay) communicate with a third-party ad network's SDK. Without an adapter, AdMob doesn't know how to ask Meta Audience Network or Unity Ads for a bid. The adapter is the translator that lets your mediation platform send requests to the network in a format the network SDK understands. When you "add a network to your mediation," what you're actually doing is installing the network's main SDK plus the adapter that connects it to your mediation platform.

Why isn't my mediation adapter working even though I configured it?

The most common reasons are: SDK and adapter version mismatch (the most frequent issue, where the GMA SDK version, network SDK version, and adapter version aren't in their compatible range), consent signal failures (the network requires GDPR or ATT consent that your CMP isn't passing correctly), the adapter is configured in a different mediation group than the ad unit you're testing, or the network requires manual initialization at app startup that wasn't added. The failure mode is almost always silent. No errors in the logs, just zero fill from that network. Walk the version compatibility chain first, then the consent signals, then the mediation group configuration.

How many mediation adapters should I run?

There's no universal number, but most well-tuned mobile app mediation stacks reach diminishing returns after 4 to 5 bidders. Below that, adding a new adapter usually contributes meaningful net revenue. Above that, the marginal contribution of additional adapters drops fast. The rule I use: if an adapter contributes less than 2 percent of net mediation revenue after 30 days, it's not earning its place. Adapter count for adapter count's sake is the wrong goal. Adding the right networks for your specific traffic mix matters more than adding many networks.

Do mediation adapters affect app size and performance?

Yes. Each adapter is a separate library, and each network's SDK is also bundled. Adding 5 adapters can add 10 to 20 MB to your app size. Each adapter's SDK initializes at app startup, contributing to app launch time. The cumulative effect is real, especially on lower-end Android devices. The trade-off is between fill rate and app performance. Pruning unused adapters helps both app size and stability without typically hurting revenue.

Where do I find updated SDK and adapter versions for each network?

The reliable sources are: Google's mediation networks documentation page (which lists current adapter versions per network), each network's GitHub repository for adapters, the network's own developer documentation, Maven Central for Android adapter versions, and CocoaPods or Swift Package Manager for iOS. Don't rely on third-party blog posts or static comparison tables, including this one. Version numbers change every few weeks across the industry. The official sources are the only ones that stay current.

Can I use AppLovin MAX adapters with AdMob mediation?

No, not directly. MAX adapters are designed for the AppLovin MAX mediation platform. AdMob mediation uses its own set of adapters published by each network specifically for AdMob's mediation chain. If you're switching from MAX to AdMob (or vice versa), you'll need to install the corresponding adapter set for the destination platform. Some networks (like Meta Audience Network or Unity Ads) publish adapters for both AdMob and MAX, so you can run them on either platform, but you can't reuse the actual adapter library between the two mediation platforms.

What to do this week

If you're running mediation and you haven't audited your adapters in 90 days, here's the order of operations:

List every adapter currently installed. Map each to the network it serves and the mediation group it's configured in.
Pull last 30 days of revenue contribution per adapter. Anything below 2 percent of net mediation revenue is a candidate for removal.
Verify version compatibility across the chain: GMA SDK, each adapter, each network's SDK. The network's own documentation is the source of truth, not a blog table.
Check consent signal status. If your fill rate dropped recently in EU or US states with state-level privacy laws, the consent path is where to look first.
Audit your initialization sequence. If any networks require manual initialization, confirm those calls are present and firing.
After this audit, decide whether to add new adapters (only if you have clear demand gaps) or remove existing ones (anything below the 2 percent threshold).

If your mediation revenue feels lower than it should be and the dashboard is telling you everything is fine, the dashboard is wrong. The signal is in the per-adapter contribution data and the consent path. That's where to dig.

If you're trying to figure out which adapters to add or remove for your specific mediation stack, book a 30-minute call. I'll look at your current setup and tell you what's actually contributing revenue versus what's adding overhead without pulling its weight.