AdMob consent is not a legal footnote hidden at the bottom of a privacy policy — in 2026 it is a monetisation setting. The ads your app is allowed to serve to users in the EEA, the UK and Switzerland depend on a message you build in the AdMob console and on a small SDK that reads the user's answer back to the ad request path. The Google User Messaging Platform (UMP) SDK is that SDK, and the events it drives decide whether an ad request is a personalised impression, a limited one, or nothing at all.

The frustrating part is that a broken consent setup barely looks broken. The app installs, the ads render, the dashboard shows impressions — and revenue per user simply comes in lower than it should, in exactly the geographies that pay best. This checklist covers the whole AdMob consent configuration in the order it is actually done: account prerequisites, the message type and targeting, the UMP SDK integration on Android and iOS, the canRequestAds() gate, the privacy options entry point, testing with debug geography and test devices, US states signals, and Consent Mode. Each step maps to behaviour that Google documents in its own AdMob Help and Mobile Ads SDK references.

1. Three consent layers that are not the same thing

Most setup mistakes come from treating one system as another. Keep these three separate in your head, because they are configured in different places and fail in different ways.

If a user in Germany never sees a form, the problem is the message configuration or the targeting — not your ad implementation. If a user sees the form but your app requests ads before the SDK has an answer, the problem is your request flow. Different layers, different fixes.

2. Checklist step 1 — confirm you can configure this at all

Consent settings live behind an account permission, and this trips up larger operations first.

3. Checklist step 2 — create the European regulations message

The form itself is built in AdMob, under Privacy & messaging. For the European regulations message type:

  1. In AdMob, open Privacy & messaging and create a new message (the button reads Create if this is your first message for the app, or Manage if you have created one before).
  2. Select the apps the message will be shown in. Under the UMP SDK, the message is resolved from the AdMob Application ID configured in your project, so an app that is not selected here has no form to show.
  3. Select the languages. The message falls back to a default language when the device language cannot be determined, so review every language you add before publishing.
  4. In the Targeting section choose either Countries subject to GDPR (EEA, UK, and Switzerland) or Everywhere. Most apps want the first option: the form reaches the users the policy applies to and leaves everyone else alone.
  5. Add a privacy policy URL — it is a required part of the message — then review and publish. Saving a draft is not publishing, and an unpublished message means no form ever appears.

Google also exposes Error reports in the AdMob UI for consent implementations, which is the first place to look when a form behaves oddly rather than the last.

4. Checklist step 3 — Android integration

The UMP SDK is a separate library from the ads SDK and requires Android API level 21 or higher.

// app/build.gradle
dependencies {
    implementation("com.google.android.ump:user-messaging-platform:4.0.0")
}
<!-- AndroidManifest.xml -->
<meta-data
    android:name="com.google.android.gms.ads.APPLICATION_ID"
    android:value="ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy"/>

5. Checklist step 4 — iOS integration

# Podfile
pod 'GoogleUserMessagingPlatform'
<!-- Info.plist -->
<key>GADApplicationIdentifier</key>
<string>ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy</string>

6. Checklist step 5 — request consent information on every launch

This is the step people implement once and forget. It has to run every app launch, before any ad request.

7. Checklist step 6 — gate ad requests on canRequestAds()

The consent decision is only meaningful if it actually gates the ad request.

8. Checklist step 7 — the privacy options entry point

9. Checklist step 8 — test with debug geography and test devices

Consent code that cannot be replayed is consent code that will break in production.

  1. Build ConsentDebugSettings and register your test device with addTestDeviceHashedId("…"). The hashed ID is printed in the log output of the first requestConsentInfoUpdate() call, so you can copy it from there.
  2. Force a region with setDebugGeography(DebugGeography.DEBUG_GEOGRAPHY_EEA) so an EEA form can be exercised without travelling. The same setting covers the UK and Switzerland.
  3. Emulators are treated as test devices by default from UMP SDK 2.2.0 onward — no device ID required.
  4. Use consentInformation.reset() to simulate a fresh install and see the first-run experience again. This is a testing tool: do not call reset() in production code.
  5. Remove the debug device IDs and geography before you ship. Forced geography is a hard-coded lie about where the user is; it belongs in development builds only.

10. Checklist step 9 — US states: RDP or the IAB GPP signal

US state privacy laws are handled differently from European consent, and you must choose one approach rather than sprinkling both.

11. Checklist step 10 — Consent Mode mapping

If you also run analytics, the UMP SDK can translate GDPR choices into Google Consent Mode so measurement and ads agree with the user's decision.

12. What actually happens when a user declines

Declining is a supported outcome, not an error state — but it changes what you can serve.

13. The failure list — eight ways this breaks quietly

  1. The message was saved as a draft and never published.
  2. The app was not selected in the message, so the SDK has nothing to show for that Application ID.
  3. The wrong AdMob application ID is in the manifest or Info.plist.
  4. Targeting is set to Everywhere (or left misconfigured) when only EEA, UK and Switzerland traffic was intended, or the reverse.
  5. The privacy policy URL is missing, which blocks publication of the message.
  6. Ad requests fire on cold start, before requestConsentInfoUpdate() — so canRequestAds() could never have returned true.
  7. The app caches its own consent verdict instead of asking the SDK each launch.
  8. Debug device IDs, forced geography or reset() shipped in the release build.

Every item in that list is checkable before release, and none of them require a policy argument — they are build and configuration defects.

14. Where KappS fits in

Consent sits in the same chain as the developer account, the payments profile and the tax information: any one of them can quietly hold up revenue without stopping the product. KappS helps developers prepare and submit compliant material across that chain — including the AdMob side, where the difference between a published message, a correctly registered application ID and a properly gated ad request is measurable in EEA revenue.

What we do not do is manufacture consent. A form that is never shown, or a signal that claims an answer the user never gave, is a policy violation that puts the account and its payouts at risk, and it is not a service we offer. The setup above is the whole trick: show the real form, keep the real answer, and respect it at the ad request.

Sources (Google official documentation): AdMob Help — European regulations message (support.google.com/admob/answer/10113207); Mobile Ads SDK — Set up UMP SDK (Android / iOS, developers.google.com/admob); US states privacy laws (RDP and IAB GPP); Interpret consent mode values; Google EU user consent policy.