AdMob to AppLovin MAX Migration Playbook: How to Switch Without Breaking Revenue

Running AdMob mediation and moving to MAX? This is the execution playbook: parallel run setup, the calibration window, what breaks, and when to fully cut over.

Migrating from AdMob mediation to AppLovin MAX requires a parallel run (7-14 days minimum), not a hard cutover. Run AdMob and MAX simultaneously on a traffic split to calibrate MAX's ML models before committing revenue to the new stack. What breaks during migration: GMA SDK adapter dependency, app-ads.txt entries for MAX demand partners, GAM line item conflicts, and the SKAN ID list delta on iOS. Full cutover is safe when per-network eCPM and fill rate stabilize across a 7-day moving average after day 14.

This is the migration playbook, not the decision article

If you are still evaluating whether to move from AdMob mediation to AppLovin MAX, the right starting point is the AdMob Mediation vs AppLovin MAX comparison. That article covers the decision framework, format-level eCPM differences, and when MAX is the right call for your stack. Start there if you have not decided yet.

This article starts where that one ends. You have decided MAX is the right primary mediator. Now you need to execute the migration without breaking revenue.

The most common migration mistake is treating this as an SDK swap. It is not. Moving from AdMob mediation to MAX as your primary mediator changes the auction architecture, the demand routing logic, the impression counting methodology, and the attribution chain. Each of those changes requires a specific handling step. Swap the SDK without addressing those layers and you will see a revenue drop you cannot explain, because the numbers will look like misconfiguration when they are actually calibration noise, or look like calibration noise when they are actually misconfiguration.

The structure of this playbook: pre-migration audit, parallel-run setup, calibration window management, what breaks and how to identify it, the revenue dip curve by format, full cutover criteria, rollback plan, and the common migration mistakes that produce bad data. Read it in order the first time. Use the What breaks during migration section as a diagnostic reference once you are mid-migration.

For SDK version compatibility details, the Mediation SDK & Adapter Compatibility Guide is the reference. For the architecture comparison between MAX and Unity LevelPlay, see AppLovin MAX vs Unity LevelPlay.

Pre-migration audit: dependency inventory, waterfall snapshot, and demand mapping

Before touching any SDK, capture the current state. You cannot evaluate whether the migration worked if you did not record what you started from.

Step 1: Demand inventory

Export your AdMob mediation group configuration. For each ad unit, list every demand source, its type (bidding or waterfall), its country-grouped CPM floor for waterfall sources, and its 30-day average eCPM and fill rate from your AdMob mediation report.

Two things to check specifically: first, any demand sources active in AdMob mediation that are not on the official MAX adapter list. Some regional networks do not have a MAX adapter. Those sources will not survive the migration cleanly. Identify them before you start. Second, any direct CPM relationships you negotiated outside the platform. Those do not transfer automatically to MAX.

Cross-reference your current AdMob adapter list against MAX's supported network list using the Mediation SDK & Adapter Compatibility Guide before committing to a migration date.

Step 2: Waterfall snapshot

Export or screenshot the full waterfall order for each ad unit, by country segment. This is your rollback reference. If MAX underperforms after the calibration window, you need to be able to reconstruct the AdMob waterfall exactly. Capture the CPM floor values set for each waterfall tier, not just the network order. Floor values are as important as ordering.

Before starting the migration, run the Mediation SDK Checker across your current build. It confirms which SDK versions are active, flags any existing conflicts, and gives you a clean pre-migration baseline. The baseline reading matters: if you have existing conflicts before the migration, you cannot reliably attribute post-migration errors to the migration itself.

If you want to audit your current AdMob mediation configuration, the AdMob Approval Checker covers GMA SDK version and account-level configuration review.

Step 3: SDK dependency audit

The most common technical failure in an AdMob-to-MAX migration is a misunderstanding of the GMA SDK adapter requirement. AppLovin MAX uses the Google Mobile Ads (GMA) SDK as the underlying transport layer for AdMob demand flowing through MAX. You are not replacing the GMA SDK. You are adding MAX on top of it and configuring AdMob as a mediated network within MAX's stack.

Current confirmed requirements: AppLovin adapter version 13.6.2.0 (minimum for full bidding support is 9.4.2.0), GMA SDK 25.1.0 or above, Android API level 23+, compileSdkVersion 34+ for Android.

Check your current GMA SDK version before the migration. If you are on a legacy version, upgrade the GMA SDK first, validate that your existing AdMob setup is stable, then begin the MAX migration as a separate step.

Step 4: SKAN ID list (iOS)

On iOS, every network in your mediation stack requires its own SKAN ID entries in your app's Info.plist. Your current AdMob mediation stack has a specific set of SKAN IDs from your current demand partners.

When you add MAX and its mediated networks, the SKAN ID list changes. The AppLovin Integration Manager (Unity path) handles this automatically. For the Android/Gradle path, you need to manually reconcile the delta: compare the SKAN IDs required by your new MAX-mediated demand partners against the ones already in your Info.plist, and add the missing entries before submitting.

Missing SKAN IDs do not cause a crash or a visible error. They silently remove those demand partners from receiving SKAdNetwork attribution. Over time, their bidding models receive fewer valid postbacks, degrading their optimization signal for your inventory, which reduces their bids. The revenue leak is gradual and easy to misattribute to market conditions over the following weeks. For the full SKAN 4.0 attribution context, see SKAdNetwork 4.0 Conversion Value Setup.

Before the parallel run begins, a structured demand audit tells you exactly what you have, which networks will survive the migration cleanly, and which need a plan. That is the kind of pre-work that prevents a revenue drop you cannot explain three weeks in. If you want a second pair of eyes on your current stack before starting, the free 30-minute call is the right starting point.

The migration architecture: MAX as primary mediator, GMA SDK as demand transport

The architecture distinction that confuses most developers migrating from AdMob mediation: you are not choosing between AdMob and MAX. You are changing which platform sits at the top of the mediation hierarchy. AdMob demand does not disappear. It becomes one demand source within MAX's stack.

In AdMob mediation, AdMob is both the mediator and a first-party demand source. In MAX mediation, MAX is the mediator. AdMob becomes a mediated adapter: MAX calls the GMA SDK adapter to access Google demand.

The practical implications: (a) you still need the GMA SDK installed, (b) AdMob's impression counting and MAX's impression counting are not identical. MAX counts an impression when it renders. AdMob counts when Google delivers. This gap (roughly 5-8%) is normal and permanent in the MAX-mediated architecture. It is not a sign that AdMob demand is performing worse. It is a counting methodology difference that will appear in your reporting forever.

The stack architecture after migration:

MAX (primary mediator)
├── Bidding group
│ ├── AppLovin (first-party demand, via SDK Key)
│ ├── Meta Audience Network
│ ├── Mintegral
│ └── AdMob / Google Open Bidding (via GMA adapter)
└── Waterfall group
├── AdMob waterfall instances (high / medium / low CPM tiers)
├── Direct deals
└── Remaining demand partners (via MAX adapters)

Banner format through the AdMob/AppLovin adapter supports waterfall only, not bidding. Supported banner sizes in this adapter: 320x50 and 728x90. If you are running adaptive banners or custom sizes through AdMob mediation today, confirm those sizes are supported in the MAX adapter before migrating those placements.

One specific failure mode to know about: AppLovin enforces a single concurrent load per zone ID (error 105). If your app requests multiple interstitial loads simultaneously against the same AppLovin zone, the second load fails silently. This surfaces as a fill rate drop that looks like a bidding problem but is a request architecture problem. Check your load request logic before attributing unexplained fill drops to calibration.

For the relationship between bidding and waterfall demand routing, see Mediation Waterfall vs In-App Bidding.

Parallel-run setup: traffic splitting, instrumentation, and what to measure

A parallel run means running AdMob mediation and MAX simultaneously on different segments of your traffic. You do not migrate the full stack at once. You route a portion of users to the MAX-primary configuration while the rest stay on AdMob mediation. You run this for the full calibration window before making the cutover decision.

The parallel run is not optional. MAX's AXON ML models need impression data to calibrate. The first 7-14 days of impressions through MAX train the model on your specific inventory. Pre-calibration eCPM from MAX is not a valid comparison to AdMob eCPM. If you do a hard cutover and evaluate on day 3, you are comparing calibrated AdMob to pre-calibration MAX. That comparison will tell you MAX is worse. That conclusion is wrong, but the data will support it.

Two parallel-run architectures:

Option A (recommended): remote config split. Use Firebase Remote Config, LaunchDarkly, or an equivalent to assign users to a mediator = "admob" or mediator = "max" condition at app launch. Each condition initializes a different mediation SDK path. The assignment must be stable per user (same user always routes the same way) to avoid impression counting contamination. Start with 20-30% of traffic on the MAX segment, 70-80% on AdMob.

Option B: MAX built-in A/B testing. MAX provides a built-in A/B test for mediation group configurations. This is easier to configure but tests MAX configuration variants against each other, not MAX vs AdMob head-to-head. Use Option A if you want a clean AdMob vs MAX comparison.

What to track per segment:

  • Per-network eCPM (not aggregate eCPM: the aggregate is too noisy during calibration)
  • Per-network fill rate by format and country
  • Total ad ARPDAU by segment
  • Revenue per session by format
  • Error codes: error 105 (AppLovin zone conflict), GMA adapter load failures, and per-network "no fill" rates above your AdMob baseline

Evaluation timeline:

Days 1-3: Do not evaluate eCPM. Monitor error rates and load failures only. Pre-calibration MAX eCPM is noise. If you see systematic errors (error 105, GMA init failures), resolve those before proceeding.

Days 3-7: eCPM and fill rate are still noisy. Watch the trend direction, not the absolute numbers. A consistent downward trend in per-network fill rate after day 3 signals a configuration issue, not calibration.

Days 7-14: Evaluation window. Per-network eCPM should be stabilizing. Compare per-network ARPDAU for the MAX segment against the AdMob control using a 7-day rolling average. That is the number that drives the cutover decision.

Day 14 and beyond: If the MAX segment is at or above the AdMob control on total ad ARPDAU, calibration is complete and you can proceed to cutover planning. If it is still below, extend the parallel run and investigate per-network fill rate for the lagging sources.

The calibration window: what happens day 1-3, day 7-14, and when the numbers become trustworthy

The calibration window is not a courtesy period. It is a structural requirement of how MAX's AXON bidding models work. The models AppLovin uses to price your inventory in real-time auctions train on your specific app's data. Without sufficient impression volume, the model has weak priors and bids conservatively. Conservative bidding means lower clearing prices, which means lower eCPM. That is the revenue dip.

Days 1-3: initialization phase

AXON initializes with population-level priors for your app category and geography. These are conservative. eCPM in the first 72 hours reflects a model that does not yet know your inventory's specific value.

AdMob demand through the GMA adapter is also initializing its impression-count baseline. The first day of AdMob impressions through MAX will show lower reported eCPMs than the same AdMob demand through AdMob mediation directly. This reflects the impression counting methodology difference (MAX counts on render, AdMob counts on delivery). The roughly 5-8% gap is normal and permanent.

Measure error rates, init success rates, and aggregate fill rate in this phase. Not eCPM.

Days 3-7: calibration phase

The AXON model is accumulating signal. eCPM will fluctuate. A drop on day 4 followed by a recovery on day 6 is expected model behavior, not a revenue signal.

What to watch: per-network fill rate trends. Meta, Mintegral, and AppLovin direct should all be improving. If Meta fill rate is flat or declining after day 5, check the Meta adapter version (11.0 or later required) and the advertiser tracking consent flag implementation (setAdvertiserTrackingEnabled).

A note on timeline context: Playwire's analysis of AXON references "90+ day optimization periods." That figure refers to full account-level AXON optimization. Unit-level calibration (the eCPM stabilization window a publisher sees during migration) is 7-14 days for apps with sufficient impression volume. Do not conflate the two figures.

Days 7-14: evaluation phase

Per-network eCPM should be stabilizing. This is the first window where a meaningful comparison to the AdMob control is valid. Use a 7-day rolling average for both segments. Single-day comparisons are still noisy.

From operator experience: rewarded video eCPM in the MAX segment should be within 5-10% of the AdMob segment by day 10-12 if the configuration is correct. For apps with rewarded video as the primary format and 50K+ DAU, MAX typically meets or exceeds AdMob eCPM by day 14. For smaller apps or banner-primary setups, the calibration period may be longer.

If eCPM is still 15% or more below the AdMob control at day 14, investigate three things: (a) AdMob adapter demand: confirm the GMA SDK is on 25.1.0+, confirm Open Bidding is correctly configured in the AdMob account; (b) MAX bidding floor settings: if your AdMob waterfall top tier is $8 CPM and your MAX bidding floor is $2, you are clearing MAX impressions at prices below what the AdMob waterfall would have held; (c) traffic split contamination: user assignment bleed (users assigned to both segments simultaneously) corrupts the comparison.

The expected revenue dip and recovery curve

Name it directly. Publishers migrating from AdMob mediation to MAX will see a revenue dip during the calibration window. That is expected. It is not proof that MAX is worse.

Rewarded video

Rewarded is the format where publishers see the most consistent recovery and often material uplift after calibration. AppLovin's bidding demand for rewarded video is deep, particularly for gaming apps in US/UK/Western Europe. The calibration dip for rewarded video is typically 3-7% in the first 7 days, with recovery to parity or above possible by day 14.

Interstitial

Interstitial follows a similar pattern. AppLovin and Meta bidding demand for interstitials is competitive. Recovery timeline is similar to rewarded: 7-14 days for apps with 50K+ DAU in tier-1 geographies.

Banner

Banner is the format most likely to show a persistent decline rather than a temporary calibration dip. The GMA adapter supports banner sizes 320x50 and 728x90 in waterfall only, no bidding. If your AdMob mediation stack ran adaptive banners or custom sizes, those placements are not migrating cleanly. Banner revenue may decline permanently unless you reconfigure those placements.

Honest range

There is no single published figure for the migration revenue dip because it depends on app category, geography, impression volume, demand mix, and whether the parallel run was executed correctly. The range from operator experience: 5-15% dip in total ad ARPDAU during calibration, with recovery to parity or above by day 14-21 for apps that meet the calibration conditions (rewarded primary, 50K+ DAU, US/UK/DACH/AU geo weight, four or more competitive bidding demand partners).

What the dip is not

It is not a sign of misconfiguration (unless it persists beyond day 21 or is accompanied by high error rates). It is not a sign that MAX is the wrong choice. It is not a fair comparison to the AdMob baseline unless the control segment is clean and the parallel run is properly isolated.

If your revenue dip is past day 21 and has not recovered, that is not calibration noise. That is a configuration problem. A structured read of your MAX setup against your AdMob baseline will find what is misaligned. That is exactly what the free 30-minute call covers.

What breaks during migration

This section is written as a diagnostic reference. If you are mid-migration and something is wrong, start here.

1. GMA SDK adapter version conflict

Symptom: AdMob demand through MAX shows very low fill rate or zero revenue from day 1.

Cause: GMA SDK below 25.1.0, or AppLovin adapter below 9.4.2.0, or incompatible versions of the two together.

Fix: Confirm GMA SDK in Gradle: com.google.android.gms:play-services-ads:25.1.0 (or higher). Confirm adapter: com.google.ads.mediation:applovin:13.6.2.0. If conflicting transitive dependency versions are pulling in older versions from other libraries, use Gradle dependency resolution to force the correct version. Run the Mediation SDK Checker to confirm the dependency tree before and after the fix.

2. App-ads.txt: missing MAX demand partner entries

Symptom: Revenue from MAX demand partners is lower than expected, particularly AppLovin, Meta, and Mintegral. No SDK error.

Cause: Your app-ads.txt file does not include the authorized seller entries for demand partners now flowing through MAX. Programmatic buyers check app-ads.txt authorization before bidding. Missing entries cause them to skip your inventory silently.

Fix: Pull the required app-ads.txt entries from each MAX demand partner's documentation and add them to your app-ads.txt. AppLovin's required entries differ from AdMob's. This is a deployment-side step, not an SDK step, and it is commonly missed. Allow 24-48 hours after updating before attributing fill rate changes to this cause.

3. GAM line item conflicts (for publishers running AdMob through Google Ad Manager)

Symptom: Specific ad units show demand competing in a way that degrades yield, with one source winning at a price that does not reflect the actual auction clearing price.

Cause: Publishers running AdMob mediation through GAM have GAM line items configured for AdMob demand. When MAX takes over mediation, those line items may overlap with MAX's waterfall or bidding configuration for the same ad unit.

Fix: Audit your GAM line items for any AdMob Network or AdMob Audience Network line items targeting the ad units you are migrating. Reconcile those line items against MAX's waterfall and bidding configuration. If you use open bidding through GAM, determine whether those line items should be retired or repurposed within the MAX stack. This is the most complex breaking point for publishers with GAM setups. Run the GAM line item audit before migrating those ad units.

4. SKAN ID list delta (iOS)

Symptom (not immediate): Bidding eCPM from specific demand partners declines gradually over the first 2-4 weeks post-migration.

Cause: The SKAN ID list in your Info.plist does not include the SKAN network IDs for new demand partners added through MAX. Without those entries, partners cannot record SKAdNetwork conversions. Their bidding models receive fewer valid postbacks over time, degrading their optimization signal, reducing their bids.

Fix: After adding new demand partners via MAX adapters, run the SKAN ID reconciliation: compare SKAN IDs required by each new partner's documentation against your current Info.plist SKAdNetworkItems array and add the missing entries before submitting to the App Store. For the Unity/Integration Manager path, this is handled automatically. For Android/Gradle, it is a manual step. See SKAdNetwork 4.0 Conversion Value Setup for the full attribution architecture context.

5. Missing demand partner approvals

Symptom: A demand partner you expected in MAX shows zero impressions from day 1.

Cause: Several networks require explicit publisher approval before their demand is available in MAX. Meta Audience Network requires a separate app registration in Meta Business Manager and sometimes a manual review period. Some regional networks require contacting their partner team directly.

Fix: Check approval status for each demand partner in your MAX dashboard before the parallel run begins. Unapproved partners show in the network list but deliver zero demand. Meta approval typically takes 3-7 days. Confirm all approvals before starting the parallel run, not after.

6. Privacy flag initialization order

Symptom: GDPR-applicable traffic (EEA/UK) shows lower fill rate or fill drops after migration.

Cause: AppLovin privacy settings must be called before the GMA SDK initializes. AppLovinPrivacySettings.setHasUserConsent(true/false) and setDoNotSell(true/false) must be called before MobileAds.initialize(). Wrong order means Google's GDPR consent chain is incomplete for EEA traffic.

Fix: Audit the SDK initialization order in your app's startup sequence. Privacy flags first, then SDK init.

7. Child-directed app flag

Symptom: AppLovin demand shows zero impressions in a previously functioning setup.

Cause: If your app's content rating or AdMob settings flag the app as child-directed, AppLovin adapter version 13.0.0.1+ automatically disables AppLovin demand for that app. This is by design.

Fix: Confirm your app's content rating settings in both AdMob and MAX. If the app is not child-directed, verify no SDK initialization call is passing a child-directed flag to the GMA SDK.

SDK and app-ads.txt updates required

This is the deployment checklist. Everything here needs to be in place before or during the parallel run.

SDK updates (Android):

  • Google Mobile Ads SDK: com.google.android.gms:play-services-ads:25.1.0 or higher
  • AppLovin SDK: 13.6.x or higher
  • AppLovin adapter for AdMob mediation: com.google.ads.mediation:applovin:13.6.2.0
  • Android Gradle plugin: 4.2.0 or higher
  • Gradle version: 6.7.1 or higher
  • compileSdkVersion: 34 or higher
  • Per demand partner: each additional network adapter (Meta, Mintegral, etc.) has its own Gradle dependency. Pull current versions from the MAX Integration Manager, not the adapter's own documentation. The Integration Manager tracks version compatibility with the current MAX SDK.

SDK updates (iOS):

  • AppLovin SDK: 13.6.x or higher
  • GMA SDK: current minimum compatible with AppLovin adapter 13.6.x
  • Info.plist: SKAdNetworkItems array updated with all new demand partners' SKAN IDs
  • Meta Audience Network SDK: 11.0 or later (required for full bidding support in MAX)
  • setAdvertiserTrackingEnabled implementation for iOS 14.5+

App-ads.txt updates:

  • Add AppLovin as an authorized seller: applovin.com, [your publisher ID], DIRECT
  • Add authorized seller entries for each new demand partner flowing through MAX (Meta, Mintegral, and others). Pull the exact entries from each partner's app-ads.txt documentation.
  • Remove or archive AdMob-specific entries for demand sources now routing through MAX that no longer have a direct AdMob relationship.
  • Validate your app-ads.txt against your MAX demand partner list using the app-ads.txt section of the Mediation SDK Checker.

Network approvals checklist:

  • Meta Audience Network: app registration in Meta Business Manager required before demand is available
  • Mintegral: publisher account approval required
  • Any network with a publisher review requirement: initiate approval before SDK integration, not after

Post-migration: full cutover criteria and the rollback plan

Full cutover means removing AdMob as your primary mediator and running MAX as the sole mediation layer. Do not do this until all seven criteria below are met.

Full cutover criteria:

  1. The MAX parallel-run segment has run for at least 14 days
  2. Total ad ARPDAU for the MAX segment is within 5% of (or above) the AdMob control, using a 7-day rolling average
  3. Per-network fill rate for all major demand sources (AppLovin, Meta, Mintegral, AdMob via GMA adapter) is stable for at least 5 consecutive days
  4. Error rate (SDK errors, zone conflicts, load failures) is below 1% of total ad requests
  5. App-ads.txt has been updated and has been live for at least 48 hours
  6. All required demand partner approvals are confirmed active in the MAX dashboard
  7. On iOS: the App Store build with the updated SKAN ID list has been approved and is the active version in production

When all seven are met, the cutover is low-risk. If any are not met, identify the specific criterion and resolve it before proceeding.

The rollback plan:

Keep your AdMob mediation configuration intact and inactive (not deleted) for a minimum of 30 days post-cutover. Mediation groups, waterfall settings, and CPM floor configurations stay in the AdMob dashboard even after MAX is live.

In your app, keep the remote config flag or initialization path for the AdMob configuration available in the build. Do not remove AdMob mediation code on the first post-migration release.

Rollback procedure: flip the remote config flag back to the AdMob path. The AdMob mediation stack reinitializes with the existing configuration. Revenue signal restores within 24 hours.

Rollback trigger: if post-cutover ARPDAU drops more than 10% from the pre-migration baseline and does not recover within 5 days, activate the rollback and investigate. Do not wait for a longer window at that level of sustained drop.

When to run both permanently:

Some publishers find that keeping AdMob mediation active for specific ad units or geographies while running MAX for others is the right long-term configuration. If banner units perform better through AdMob mediation (given the adapter's format limitations in MAX) and rewarded performs better through MAX, running the two side by side permanently is a valid production configuration.

The constraint: do not run the same ad unit through both mediators simultaneously with overlapping demand. That creates duplicate impression counting and revenue attribution problems.

Common migration mistakes

Mistake 1: Full cutover without a parallel run

The most common and most costly mistake. A hard cutover from AdMob to MAX on day 1 puts 100% of your revenue on a pre-calibration ML stack. Pre-calibration eCPM is structurally lower. If you cut over on day 1 and evaluate on day 3, you will conclude MAX is underperforming. The system has not had enough data to compete fairly. The parallel run is the only valid comparison methodology.

Mistake 2: Removing the GMA SDK

Some developers interpret the move away from AdMob mediation as permission to remove the GMA SDK. They cannot. MAX uses the GMA SDK as the transport layer for AdMob demand. Removing the GMA SDK removes AdMob demand entirely from the MAX stack. Check your Gradle or CocoaPods dependency tree after the migration and confirm the GMA SDK is present and on the correct version.

Mistake 3: Missing demand partner approvals before the parallel run

Integrating a network's adapter in MAX does not automatically grant access to that network's demand. Meta requires a separate app registration. Several networks have a publisher review step that takes 3-7 days. If you begin the parallel run before approvals are confirmed, you are calibrating MAX with an incomplete demand set. The calibration data from that period is not valid for the full demand configuration. Confirm all approvals before the parallel run starts.

Mistake 4: Not updating app-ads.txt

Missing entries for AppLovin or MAX demand partners cause those partners to skip your inventory. The fill rate drop does not generate an SDK error. The only signal is lower-than-expected fill rate from those specific partners. The fix is a non-code deployment that can be done at any point, but every day it goes unfixed is revenue loss.

Mistake 5: Skipping the SKAN ID delta on iOS

The SKAN ID reconciliation step is easy to skip because it does not cause immediate visible errors. The impact is delayed: demand partners whose SKAN IDs are missing from your Info.plist lose optimization signal over 2-4 weeks, reducing their bids. The only signal is a slow eCPM decline from specific partners, easy to misattribute to seasonality or market conditions. Fix it before your first post-migration App Store submission.

Mistake 6: Evaluating aggregate eCPM instead of per-network eCPM

Aggregate eCPM during calibration blends calibrated demand (AdMob, which was already calibrated before the migration) with uncalibrated demand (AppLovin bidding, Meta bidding). The aggregate number will look worse than either component at steady state. Evaluate per-network eCPM and per-network fill rate separately. The diagnostic signal lives at the network level.

Mistake 7: Setting MAX bidding floors below the AdMob waterfall top tier

If you leave MAX bidding floors at zero or at MAX's default, bidding demand can clear at prices well below what your AdMob waterfall would have captured for the same impression. Set the bidding floor in MAX at or above your highest-tier AdMob waterfall CPM for each geo segment during the calibration period. Once you have steady-state MAX data, you can optimize floors downward if the bidding demand is competitive enough to reliably clear above them.

Frequently Asked Questions

How long does an AdMob to AppLovin MAX migration take?

The migration has two phases. The parallel run (running AdMob and MAX simultaneously on a traffic split) takes 14-21 days minimum to calibrate MAX's ML models and validate per-network eCPM and fill rate before committing full traffic to the new stack. Technical setup (SDK integration, app-ads.txt updates, demand partner approvals) adds 3-7 days before the parallel run can begin. Total elapsed time from decision to full cutover is approximately 3-4 weeks for a clean migration. Full cutover is safe when the MAX segment's total ad ARPDAU is within 5% of the AdMob control on a 7-day rolling average after at least 14 days of parallel run data.

Will I lose revenue during the AdMob to MAX migration?

Yes, and that is expected. The parallel run segment running MAX will show lower eCPM than your AdMob control during the first 7-14 days while AppLovin's AXON ML models calibrate on your inventory. The typical dip for apps with rewarded video as the primary format and 50,000 or more DAU in tier-1 geographies is 5-15% in total ad ARPDAU on the MAX segment during calibration. Because only 20-30% of traffic is on the MAX segment during this period, the impact on total revenue is limited. The risk of a permanent revenue dip (not a calibration dip) is highest for banner-primary setups and apps with thin bidding demand coverage in their primary geography.

Should I run AdMob and MAX in parallel during the migration?

Yes. Running MAX on the full stack without a parallel run is the single most common migration mistake. Without a parallel run you have no baseline comparison, no clean error detection window, and you are putting pre-calibration MAX eCPM against your revenue expectations before the ML models have enough data to perform accurately. The parallel run requires a remote config split (Firebase Remote Config or equivalent) to assign users stably to either the AdMob or MAX initialization path. Run the split for a minimum of 14 days before evaluating the cutover decision. Do not roll back based on data from the first 3-7 days, which reflects pre-calibration noise rather than steady-state MAX performance.

What breaks during an AdMob to AppLovin MAX migration?

The seven most common breaking points are: (1) GMA SDK adapter version incompatibility (MAX still requires the GMA SDK to access AdMob demand; removing it removes AdMob demand entirely); (2) app-ads.txt missing authorized seller entries for AppLovin and MAX demand partners (causes silent fill rate drops with no SDK error); (3) GAM line item conflicts for publishers running AdMob through Google Ad Manager; (4) SKAN ID list not updated with new demand partner IDs on iOS (causes gradual eCPM decline over 2-4 weeks as partners lose attribution signal); (5) missing demand partner approvals before the parallel run begins (Meta requires separate app registration, which takes 3-7 days); (6) privacy flag initialization order (AppLovin privacy settings must be called before GMA SDK init for correct GDPR handling); (7) AppLovin zone conflict error 105 if the app requests multiple simultaneous ad loads per zone.

Do I keep AdMob as a demand source after migrating to AppLovin MAX?

Yes, in almost all cases. When you move to MAX as the primary mediator, AdMob becomes a mediated adapter within MAX's stack accessed via the GMA SDK adapter. AdMob demand does not disappear; you configure AdMob waterfall instances at high, medium, and low CPM tiers within MAX alongside AdMob open bidding participation. The GMA SDK remains in your build. The change is that AdMob is no longer running the auction (MAX is), and AdMob is one demand source among several. Removing AdMob demand from a MAX stack is possible but uncommon. Most publishers retain AdMob as a demand source within MAX because AdMob direct demand (AXON-eligible inventory) continues to be a competitive fill source for US and tier-1 geo traffic.

How do I know when the MAX migration is calibrated and ready for full cutover?

Use seven criteria: (1) the parallel run has run for at least 14 days; (2) total ad ARPDAU for the MAX segment is within 5% of the AdMob control on a 7-day rolling average; (3) per-network fill rate for all major demand sources (AppLovin, Meta, Mintegral, AdMob via GMA adapter) is stable for at least 5 consecutive days; (4) error rate is below 1% of total ad requests; (5) app-ads.txt has been updated and live for at least 48 hours; (6) all required demand partner approvals are confirmed active in the MAX dashboard; (7) on iOS, the App Store build with the updated SKAN ID list is in production. When all seven criteria are met, the cutover risk is low. If any remain unresolved, identify the specific criterion and fix it before proceeding.

After the migration

A migration from AdMob mediation to MAX done correctly takes 3-4 weeks and produces a clean calibrated baseline you can build on. Done incorrectly, it produces three weeks of bad data and a revenue story you cannot explain to anyone looking at the numbers.

The pre-migration audit, the parallel run, and the seven-criterion cutover checklist are the difference between those two outcomes. None of it is complex. All of it requires doing things in the right order, with the right instrumentation, before you need the data.

If you want a second pair of eyes on your migration plan before it starts, or a read on where your current MAX setup stands relative to your AdMob baseline, that is what the free 30-minute call is for.