When Is It Time to Migrate Your Mediation Platform?
Switching ad mediation platforms is one of the most consequential decisions a mobile publisher can make. The mediation layer controls which ads your users see, how much you earn per impression, and how smoothly your ad experience runs. Migration carries real risk, but staying on a suboptimal platform carries a compounding cost that grows every day.
Clear signals that it is time to evaluate a move:
- Declining eCPMs without market explanation: If your eCPMs are dropping while industry benchmarks hold steady, your current platform may have demand gaps or optimization issues that new entrants have solved.
- Better bidding support elsewhere: If your current platform supports 3 bidding partners but a competitor supports 8, you are leaving auction density (and revenue) on the table.
- SDK sunset or deprecation: When your mediation platform announces end-of-life for its SDK or stops actively developing features, migration is not optional. It is a matter of when, not whether.
- Missing ad formats: If your platform does not support app open ads, rewarded interstitials, or native bidding while competitors do, each missing format represents lost revenue.
- Reporting limitations: If you cannot get granular eCPM data by network, geo, ad unit, and format, you are flying blind. Modern platforms provide this as standard.
Migration Planning: The Parallel Testing Approach
The cardinal rule of mediation migration is never to do a hard cutover. A parallel testing approach protects your revenue floor while validating the new platform’s performance with real traffic.
The parallel strategy works as follows:
- Phase 1 (Setup): Integrate the new mediation SDK alongside your existing one. Configure identical ad units, demand sources, and floor prices in both platforms.
- Phase 2 (Split traffic): Route 10–20% of your traffic to the new platform while keeping 80–90% on the existing one. Use a remote config flag or A/B testing framework to control the split.
- Phase 3 (Monitor): Run both platforms simultaneously for at least 2 weeks, comparing eCPM, fill rate, latency, and crash rate across the split.
- Phase 4 (Scale): If the new platform meets or exceeds the old one, gradually increase its traffic share: 20% to 50% to 80% to 100%.
- Phase 5 (Cleanup): Remove the old mediation SDK and associated configurations once 100% of traffic has been on the new platform for at least one week with stable performance.
Data You Need Before Switching
Before initiating any migration, export and document comprehensive baseline data from your current platform. This data serves two purposes: it provides comparison benchmarks for evaluating the new platform, and it informs the initial configuration of your new waterfall or bidding setup.
Essential Data Points
- Historical eCPM by network and geography: At minimum, the last 90 days of daily eCPM for each demand source broken down by country or country group. This tells you which networks are performing well in which markets and informs your new waterfall ordering.
- Fill rate by network and ad format: A network with high eCPM but 5% fill rate contributes differently than one with moderate eCPM and 90% fill rate. Both metrics are needed for accurate configuration.
- Impression volume by ad unit: Understand which ad placements generate the most impressions. These are your highest-impact units and should be migrated last to minimize risk.
- Latency data: If available, document average ad load time and timeout rates per network. This helps set appropriate timeout values in the new platform.
- Revenue by day of week and time of day: Ad markets have weekly and daily cycles. Having this pattern documented ensures you do not mistake normal cyclical variation for migration-related changes.
Nice-to-Have Data
- User-level ARPDAU by cohort
- Session-level ad frequency data
- Crash and ANR rates correlated with ad SDK activity
- Detailed bid-level logs if your current platform provides them
Step-by-Step Migration Process
Step 1: Install the New Mediation SDK
Add the new mediation SDK and all required adapter SDKs to your project. Do not remove the old SDK yet. Both will coexist during the parallel testing phase. Key actions:
- Add the core mediation SDK dependency
- Add adapter SDKs for each demand source you plan to use
- Initialize the new SDK in your Application class or AppDelegate, gated behind a remote config flag
- Verify the build compiles without conflicts between old and new SDKs
Step 2: Configure Ad Units and Demand Sources
In the new platform’s dashboard, recreate your ad unit configuration:
- Create ad units matching your existing placements (same format, same refresh interval for banners)
- Add all demand sources with their respective app IDs and placement IDs
- Set initial floor prices based on your historical eCPM data from the old platform
- Enable bidding for all sources that support it; configure waterfall entries for the rest
Step 3: Implement the Traffic Split
Use a remote configuration system (Firebase Remote Config, your own feature flag system, or a simple server-side toggle) to control which mediation SDK handles each session:
- On app launch, check the remote flag to determine which SDK is active for this session
- Request ads only through the active SDK for the entire session. Do not mix SDKs within a session.
- Log which SDK is active in your analytics so you can segment performance data cleanly
Step 4: Run Parallel for Two Weeks Minimum
Two weeks is the minimum evaluation period. This duration captures weekday and weekend patterns, accounts for demand fluctuation, and gives bidding algorithms time to learn your inventory. During this period:
- Monitor eCPM, fill rate, and total revenue daily for both groups
- Track app stability metrics (crash rate, ANR rate) across both groups
- Watch for user experience issues (slow ad loads, blank ad frames, unexpected full-screen ads)
- Do not make configuration changes to either platform during this period unless something is clearly broken
Step 5: Compare and Decide
After the parallel period, compare the two platforms across these dimensions:
- Revenue per DAU: The primary metric. If the new platform generates equal or higher revenue per daily active user, it passes the core test.
- Fill rate: Higher fill rate means more impressions monetized. A new platform with 5% higher fill rate and similar eCPM is a clear winner.
- Latency: Faster ad loading means better viewability and user experience.
- Stability: If the new SDK increases crash rates, it may not be worth the revenue gain.
Step 6: Cutover and Cleanup
Once you have committed to the new platform, increase traffic to 100%, monitor for 5–7 more days, then remove the old SDK entirely. Update your dependency list, remove old initialization code, and clean up any conditional logic related to the traffic split.
Common Pitfalls in Mediation Migration
Even well-planned migrations encounter issues. Being aware of common pitfalls helps you avoid or recover from them quickly:
- Losing historical optimization data: Bidding algorithms on the old platform have months of data about your inventory. The new platform starts cold. Expect 1–2 weeks of suboptimal performance while algorithms learn.
- SDK conflicts: Running two mediation SDKs simultaneously can cause dependency conflicts, especially if both include the same demand source SDKs at different versions. Test thoroughly in a staging build before deploying to production.
- Mismatched floor prices: Setting floors too high on the new platform kills fill rate. Setting them too low leaves money on the table. Use your historical data as a starting point and adjust after the first week.
- Comparing unequal time periods: Ad markets fluctuate. Comparing week 1 of the new platform against week 1 of the old platform from three months ago is not a valid comparison. Parallel testing eliminates this problem.
- Rushing the timeline: Pressure to show quick results leads to premature conclusions. Two weeks of parallel data is the minimum. Four weeks is better for publishers with significant traffic.
Migrating from AdMob Mediation to Google Ad Manager
One of the most common migration paths is moving from AdMob mediation to the full Google Ad Manager platform. This upgrade is driven by GAM’s superior features for publishers at scale:
- Direct deal support: GAM allows direct-sold campaigns to compete alongside programmatic demand, which AdMob mediation does not support
- Advanced reporting: GAM provides granular reporting by line item, advertiser, creative, and custom dimensions
- Open Bidding: GAM’s server-side bidding supports a wider range of exchange partners than AdMob’s client-side mediation
- Unified pricing rules: Set floor prices with geo, device, and format granularity across all demand sources from a single interface
This specific migration is one RevenueFlex handles frequently. The transition from AdMob mediation to a fully managed GAM setup involves recreating your entire ad configuration in GAM, mapping demand sources, establishing new floor prices based on historical performance, and running a parallel evaluation to confirm revenue neutrality or improvement. Publishers who make this transition with proper planning typically see a 10–25% revenue increase once the GAM waterfall is fully optimized.
Mediation migration is not a weekend project. It is a multi-week process that requires careful planning, disciplined parallel testing, and patience while new algorithms learn your inventory. But for publishers on an underperforming platform, the long-term revenue impact of switching makes the short-term effort worthwhile.