Setting Up Ad Mediation in Unity Without Losing a Week

A clean Unity ad mediation setup takes about two days if you follow a fixed order: pick one mediation platform, integrate its core SDK, resolve Android dependencies, add two or three network adapters, then verify every ad format with the platform's test tool. Most lost weeks come from adding networks before the basics serve a single test ad.

What mediation actually does

Mediation is a layer that asks several ad networks for an ad and shows the one that pays best at that moment. You integrate one SDK in your game. The networks plug in behind it through adapters.

For a publisher-track team, this matters for two reasons. It raises eCPM, meaning the revenue you earn per thousand ad impressions. And publishers will often want their own mediation setup in the build, so you need to swap it quickly.

Pick one platform and commit

The three most common choices for Unity mobile games are:

If you are heading to a specific publisher, ask which one they use before you start. Many have a preference or ship their own SDK that wraps a mediation platform. Integrating the wrong one first is the most common way to lose a week.

Check each platform's current docs before you begin. SDK versions and supported networks change often.

The setup order that avoids rework

Follow this order. Each step must work before you start the next.

1. Create the app and ad units in the mediation dashboard. One rewarded, one interstitial, one banner if you need it. Note the app key and unit IDs.
2. Import the core SDK through the platform's Unity package or the Package Manager. Do not add any network adapters yet.
3. Resolve Android dependencies. Run Assets > External Dependency Manager > Android Resolver > Force Resolve. Fix every error before moving on.
4. Initialise and load one rewarded ad with the platform's own test mode on. Ship a development build to a real phone.
5. Add two or three adapters, re-resolve, rebuild, and test again.
6. Set up iOS: SKAdNetwork IDs in Info.plist, the App Tracking Transparency prompt, and a CocoaPods install that completes cleanly.
7. Add consent handling for players in regions that require it, using a certified consent tool where the networks ask for one.

A minimal rewarded flow

Keep the game code separate from any one SDK. A thin wrapper means you can swap platforms for a publisher in an afternoon.

public interface IRewardedAds {
    bool IsReady { get; }
    void Show(string placement, System.Action<bool> onDone);
}
// Game code only ever talks to IRewardedAds.
// One small class per mediation SDK implements it.

The callback reports true only when the network confirms the reward. Grant the reward there, never on the button press.

The errors that eat days

These five come up again and again.

• Duplicate classes on Android build. Two plugins ship the same library. Let the dependency manager resolve it rather than deleting files by hand.
• App crashes on launch with AdMob in the mix. The AdMob app ID is missing from the Android manifest or the plugin settings.
• Ads never fill in test. Test mode is off, the device is not registered as a test device, or the ad unit is too new.
• iOS build fails at pod install. Update CocoaPods, open the .xcworkspace not the .xcodeproj, and check the minimum iOS version.
• Rewards granted twice. The game listens to both a close event and a reward event. Grant on reward only.

Make one rewarded ad work end to end on a real phone before you add a second network. Every adapter you add makes the next bug harder to find.

Choosing networks for a first test

You do not need ten networks for a CPI or retention test. Two or three well-known networks behind your mediation is plenty while you are proving the game.

Add more only when you have real traffic and the platform's reporting shows unfilled requests or weak eCPM in specific countries. Each extra adapter adds build size and another thing to update. Our post on the SDKs and services riding inside your game explains why that matters.

A two-day plan

Here is a realistic shape for a small team that has done this once before.

Day one, morning. Dashboard setup, core SDK import, Android resolve, rewarded test ad on a phone.

Day one, afternoon. Interstitial and banner on Android, the wrapper interface, reward logic on the confirmed callback.

Day two, morning. Adapters, re-resolve, debugger check that each network initialises.

Day two, afternoon. iOS build, ATT prompt, SKAdNetwork IDs, consent flow, final test on both platforms.

If you are still fighting Gradle at the end of day two, stop and strip back to the core SDK alone. Find the conflict, then add pieces one at a time.

What we would do

We would ask the publisher which mediation platform they want before touching code, and build to that from day one. We would keep every ad call behind one interface so a platform swap is an afternoon, not a sprint.

We would also keep a short integration log in the repo: SDK versions, adapter versions and the date each was tested. When a publisher asks for an update, that log saves the guesswork. If you are moving a prototype onto a publisher's stack, see porting a Unity prototype to a publisher SDK.

The short version

• Ask your publisher which mediation platform they use before you start.
• Integrate in order: dashboard, core SDK, Android resolve, one test ad, then adapters.
• Wrap every ad call behind your own interface.
• Grant rewards only on the confirmed reward callback.
• Use the platform's test tool to check every network before you ship.

If you want a prototype that arrives with mediation already wired for your publisher, get in touch.

Related reading: Hybrid-Casual Monetization: Ads, IAP, and the Blend That Works, Ad Frequency and Churn: Finding the Line