Troubleshooting

Most integration issues trace back to one of four values not matching exactly: adapter class name, placementName, the Unity LevelPlay network key, or eCPM/rate. Adapter class names and the network key live in the Class & Network Key Registry; your placementName and eCPM/rate come directly from your account manager. Check these before diving into logs.

Common issues

These apply to every mediation partner. Partner-specific problems are in Mediation-specific issues below.

App crashes on launch

The Google Mobile Ads (GMA) SDK reads your app ID from native config at process startup - before your own code runs. If the app ID is missing or malformed, initialization throws and the app crashes on launch. The crash looks like an ad problem but happens before any ad is requested, so check your native config, not your ad-loading code. This applies to both AdMob and Google Ad Manager (same GMA SDK).

Android - add inside the application element in AndroidManifest.xml:

<meta-data
    android:name="com.google.android.gms.ads.APPLICATION_ID"
    android:value="ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy"/>

iOS - add to Info.plist:

<key>GADApplicationIdentifier</key>
<string>ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy</string>

Common mistakes

• App ID vs ad unit ID. The value here is your app ID (contains a tilde: ca-app-pub-…~…), not an ad unit ID (contains a slash: ca-app-pub-…/…). The ad unit ID here still crashes.
• Sample ID left in. The ca-app-pub-3940256099942544~… values in examples are Google's test IDs. Replace with your real app ID before release.
• Wrapper frameworks still need this. On Flutter, React Native, Unity, and Cocos the plugin does not inject the app ID for you - you must still edit the native AndroidManifest.xml and Info.plist (or the Unity/Cocos equivalent). This is the most common wrapper-integration crash.

Use the exact snippet for your platform shown above.

Mediation-specific issues

The problems below are specific to how each mediation platform is configured. Find your partner.

AdMob (custom event)

Note: See Dashboard vs. backend count discrepancies if AdMob's reported request counts run higher than TapMind's backend numbers.

Google Ad Manager (yield group)

Verify: GAM dashboard changes can take time to propagate before delivery begins - confirm the expected delay with your account manager before assuming a misconfiguration.

Note: See Dashboard vs. backend count discrepancies if GAM's yield group request counts run higher than TapMind's backend numbers.

AppLovin MAX (custom network)

Verify: confirm the MAX Mediation Debugger surfaces custom-network adapters as described in your setup.

Note: See Dashboard vs. backend count discrepancies if MAX's Attempts count runs higher than TapMind's backend numbers.

Unity LevelPlay (network key)

Note: See Dashboard vs. backend count discrepancies if LevelPlay's fill counts run lower than expected relative to TapMind's backend numbers.

Dashboard vs. backend count discrepancies

It's common across mediation platforms (AdMob, Google Ad Manager, AppLovin MAX, Unity LevelPlay) to see the mediation dashboard report a higher request or attempt count for TapMind's line than the number of requests TapMind's backend actually receives.

Why this happens: most mediation platforms count a request or attempt at the ad-unit or waterfall level, not on the device itself. Any device requesting an ad for an ad unit configured with TapMind's line can be counted, whether or not that specific app build actually contains TapMind's adapter class. Two common sources:

• Devices still running an app version installed before the adapter was integrated
• Devices where the adapter class was stripped during release minification (verify your release build's keep rules if suspected)

Both generate a counted request or attempt on the mediation dashboard without that request ever reaching TapMind's backend.

This is expected mediation-side behavior, not a defect in your integration. It's most pronounced immediately after rolling out the adapter, and typically narrows as more of your user base updates to a build that includes it. AppLovin documents this pattern directly for MAX: "You may see higher discrepancies between network and MAX numbers at launch and when user adoption rates are low, but this should stabilize as adoption increases."

What to do:

1. Track the discrepancy against your app version's adoption curve, not a single day's snapshot, and the gap should shrink as more users update.

2. If a significant gap persists well after full adoption of the adapter-carrying build, treat it as a mediation-side reporting question and escalate directly to that platform's support team.

Release vs debug

If ads work in debug but not in release, suspect the class string or R8/ProGuard stripping adapter classes in release builds.

ProGuard / R8 keep rules (Android)

Each shipped TapMind adapter AAR includes populated consumer ProGuard rules (consumer-rules.pro), packaged as consumer rules inside the artifact. These are applied automatically when you integrate the published Maven packages - you do not need to copy manual keep rules for normal integration.

Consumer rules cover both the standard adapter namespace (com.tapmind.tech.*) and the GMA Next-Gen namespace (com.tapmind.mediation.ng.*).

If you still see release-only failures after confirming class strings, contact your account manager with release logcat output.

Release build QA: There is currently no documented release-safe test path to validate R8/ProGuard without serving live ads (test mode is build-type driven: debug = test, release = live).

Escalation

Contact your account manager with:

• The mediation platform and framework
• The adapter class name and placementName you are using
• For Orchestration: error code and message from OrchError

Integration pages include partner-specific verification steps under Verify integration on each mediation page.