Play Data safety

Why does adding AdMob change my Data safety form?

This page explains what the SDK does so the form can be filled in accurately. It is not legal advice, and the app’s own data collection must be declared alongside the SDK’s. The categories below cover the Google Mobile Ads SDK in its default configuration; changes in GMA release notes can change the collection behaviour, and the canonical source is Google’s per-SDK data-disclosure guide for the current version.

admob-cmp itself declares only the INTERNET permission. Every data category below is collected by the Google Mobile Ads SDK through transitive dependencies, and removing the library would remove the API surface but not the data collection, which is driven by GMA directly.

Which data categories does the Google Mobile Ads SDK collect?

The Play form asks for data type, category, and purpose. Each row in this list maps to a row in the form:

Data type	Play category	Purpose
Advertising ID	Device or other IDs	Advertising or marketing
Ad impressions and clicks	App activity → App interactions	Advertising or marketing, analytics
Coarse location derived from IP	Location → Approximate location	Advertising or marketing

All three should be declared as collected and shared with third parties, because ad serving sends the data to Google and, when mediation is enabled, to the mediated networks. The mediation guide has the implications of enabling mediation for the Data safety form.

A short note on what is not in the default collection. GMA does not collect precise location by default; the location it derives from IP is coarse. It does not collect the user’s name, email, or phone number, and it does not collect contacts, photos, or audio. Apps that add any of these via custom request options or mediation need to declare them in addition to the three rows above.

What is the AD_ID permission?

The Google Mobile Ads SDK merges com.google.android.gms.permission.AD_ID into the app’s manifest. Apps targeting API 33 or above that do not declare it cannot access the advertising ID, which reduces ad revenue. The permission is opt-in by default; opting out is a deliberate choice.

To opt out, remove the permission explicitly:

<uses-permission
    android:name="com.google.android.gms.permission.AD_ID"
    tools:node="remove" />

State plainly: this reduces ad revenue and is not recommended unless the app is child-directed or there is another compliance reason. If the permission is removed, the Data safety declaration should reflect that the advertising ID is no longer collected — but ad impressions and coarse location still are.

Note

A child-directed app should also set GlobalRequestConfiguration(ageRestrictedTreatment = AgeRestrictedTreatment.Child), and AdConfig.consentTagForUnderAgeOfConsent is a separate UMP-only flag. The library deliberately does not infer either setting from the other. Show it:

AdConfig(
    androidAppId = "ca-app-pub-…",
    iosAppId = "ca-app-pub-…",
    consentTagForUnderAgeOfConsent = true,                 // UMP consent-flow setting
    ageRestrictedTreatment = AgeRestrictedTreatment.Child, // GMA ad-request setting
)

AgeRestrictedTreatment is Unspecified, Child or Teen, and Teen should be used only when the app has determined that treatment is appropriate. The two flags are independent because they govern different layers of the stack: UMP consent for GDPR-style flows, GMA for the ad request itself. A child-directed app that has only set the UMP flag has still sent ad requests without the GMA child-treatment hint, which the SDK silently ignores for non-child configurations.

Can I opt out of the advertising ID?

The opt-out is the manifest removal above. Its cost is the reduction in ad revenue, because Google’s bidding depends on the advertising ID for cross-app personalisation. An app that removes the ID sees the same fill rate but materially lower eCPM, because personalised bids are worth more than the non-personalised floor.

For a child-directed app, the trade-off is correct. For an app that is not child-directed and has no other compliance reason, the trade-off is rarely worth it. The Android setup guide has the manifest mechanics.

What changes when I enable mediation?

Each mediated network is its own SDK with its own collection behaviour, so enabling mediation can add data categories the base declaration does not cover. Every adapter’s data-disclosure documentation must be checked and the form updated. The mediation guide has the integration mechanics; the data-disclosure check is the publisher’s responsibility and changes per network.

A common concrete example: enabling Meta’s Audience Network adapter adds User ID and Device ID collection under the “Social Media” and “Device or other IDs” categories, both as shared with Meta. Enabling the Pangle adapter adds similar fields under Bytedance. The full list is documented per adapter, and the publisher is responsible for re-declaring when adapters change.

The form’s “shared with third parties” flag deserves more attention than it usually gets. Every ad request your app sends is shared with Google at minimum, because Google’s network is the auction host. Mediation extends that sharing list to every mediated network whose adapter you have installed and whose waterfall is configured. The “shared” flag is a yes/no answer, but the answer is “yes” for any app that has AdMob at all, and the form text is what tells the reviewer which networks are involved. A vague “shared with ad partners” is correct in spirit but rejected by reviewers who want specifics; a named list of networks is what the form is asking for.

Where to next?

Android setupManifest and the AD_ID permission.

UMP consentThe EU consent obligation.

MediationExtra SDKs, extra disclosures.