Why Mobile Games Need a Consent SDK

If your game shows ads from AdMob, Ad Manager, or a mediated waterfall to players in the European Economic Area or the UK, you are legally required to obtain valid consent before any personalized advertising or tracking identifier is used. A web cookie banner does not solve this — native mobile apps have no cookies, and the consent must reach the ad SDKs that run inside your build.

Google's answer is the User Messaging Platform (UMP) SDK, the consent layer that ships with the Google Mobile Ads SDK. It presents an IAB TCF-compliant consent form, stores the player's choices, and exposes a consent signal that AdMob and mediation partners read automatically. For a Unity studio, getting this flow correct is the difference between a healthy eCPM and a wave of policy strikes.

The Consent Flow, Start to Finish

The correct order of operations matters more than any single API call. On every app launch you should:

• Request a consent info update. This tells UMP to check the player's region and whether a form is required.
• Load and show the form if required. UMP decides whether to display it based on geography and prior choices — you never hard-code "is this user in the EU".
• Wait for the form to close before initializing the Mobile Ads SDK.
• Initialize ads only after consent is gathered, so the first ad request already carries the correct signal.

Initializing the ad SDK before the consent form returns is the most common mistake we see. It produces a non-personalized or non-compliant first impression and can trip automated policy reviews.

A Minimal Unity Implementation

In C#, the skeleton looks like this:

var request = new ConsentRequestParameters();
ConsentInformation.Update(request, (FormError error) => {
  ConsentForm.LoadAndShowConsentFormIfRequired((FormError err) => {
    if (ConsentInformation.CanRequestAds()) InitializeAds();
  });
});

The CanRequestAds() check is your gate. As long as it returns true — either because the player consented or because they are outside a regulated region — you may initialize and request ads. Cache nothing about region yourself; let UMP be the single source of truth.

Testing Without Shipping to the Store

You cannot verify a consent flow from your office in, say, Istanbul unless you simulate an EEA device. UMP supports a debug geography setting and a list of test device hashed IDs:

• Register your test device's hashed ID in the request parameters.
• Force the debug geography to EEA to make the form appear.
• Use the SDK's reset method between runs so you see the first-launch experience every time.

Always remove debug settings before a production build. Shipping a forced-EEA debug flag to every player is a real and embarrassing incident.

Consent, Mediation, and Your Revenue

When consent propagates correctly, every network in your mediation stack — AdMob, Meta Audience Network, Unity Ads, AppLovin — receives the TCF string and can bid on personalized inventory where allowed. When it breaks, those networks fall back to non-personalized ads at a fraction of the eCPM, and your waterfall quietly bleeds revenue. Treat the consent layer as part of your monetization stack, not a compliance afterthought.

Where FlexyConsent Fits

UMP covers Google's own surface, but most serious publishers run consent across web properties, multiple apps, and server-side tagging at once. FlexyConsent gives you a single consent record, TCF and Google Consent Mode v2 signals, and analytics on consent rates across every platform — so the choice a player makes in your Unity game and the choice a visitor makes on your marketing site live in one auditable place. Compliance becomes a dashboard, not a fire drill.

Key Takeaways

• Gather consent through the UMP SDK before initializing the Mobile Ads SDK.
• Never hard-code region logic — let UMP decide when a form is required.
• Test with debug geography and hashed test IDs, then strip those before release.
• Correct consent propagation protects your personalized-ad eCPM across the whole mediation stack.