AdMob and Google Play Data safety: review advertising data

Start with the AdMob setup you actually ship

The AdMob profile describes in-app advertising, but it does not prove how your app is configured. Personalized and non-personalized ads can lead to different answers. Consent controls, mediation choices, ad measurement, and the way your app initializes the SDK all matter. Begin with the release build and its production settings, not a sample project or a development toggle.

Write down which AdMob products are active, which ad formats appear, and whether mediation or other Google advertising components are present. Check whether the app requests advertising identifiers, whether you use an approved consent flow, and whether your own event or user identifiers are attached to ad requests. The point is not to infer every answer from the SDK name. The point is to connect each answer to what your app and its configuration do.

Read the catalog as a review plan

Declora’s App Passport uses the service profile to suggest App Facts. For AdMob, those suggestions cover advertising as a purpose, advertising identifiers as a possible data category, and device identifiers that may support ad serving or measurement. The catalog also flags the service’s tracking potential as configuration-dependent.

An App Fact is a review prompt, not a declaration. Open each suggestion, inspect the evidence and reason shown in Declora, and then confirm or correct it as the developer who controls the app. If a suggestion does not match your release build, do not force the build to fit the suggestion. Record the configuration that explains your answer.

The Google mapping turns confirmed facts into the store taxonomy used by Data safety. It may surface advertising ID and device IDs as separate review rows. That distinction is useful: an advertising identifier can be enabled or disabled independently from other device or app identifiers, and the answer should follow your implementation rather than a generic assumption about AdMob.

Review collection, purposes, and sharing together

Start by asking whether the data is collected by your app or by an SDK operating in your app. Then ask why it is processed. AdMob-related data may support advertising, measurement, fraud prevention, or other configured functions. Do not collapse every purpose into “analytics” or “advertising” without checking the actual products enabled.

Next, review sharing in the Google Play sense. Sharing is about providing data to another company, so an AdMob integration can make this question material even when your own server does not receive the value. Confirm the relevant data path and the provider relationship from your current integration. If mediation or another partner is enabled, review that path separately rather than assuming the base AdMob setup covers it.

For optionality, check the user journey. A user may be able to use the app without signing in, while ads still run for that user. Do not mark advertising-related data optional merely because a different app feature is optional. Match the answer to whether the user can avoid the collection by declining an optional feature or account step.

Check the settings that change the result

Use a short evidence pass before you confirm an App Fact:

• Inspect AdMob ad-personalization settings and the consent state that reaches the SDK.
• Confirm whether the advertising identifier is available, restricted, reset, or excluded by your platform logic.
• Review mediation, ad measurement, and any additional advertising SDKs loaded in the release build.
• Inspect custom request parameters, user IDs, and event payloads for data you send beyond the standard ad request.
• Check your data-retention and account-deletion process for identifiers that your own systems store alongside ad activity.

Treat an unknown as unknown. A missing answer is a reason to investigate, not permission to choose the least demanding option. If two environments behave differently, review the production release and document the condition that controls the difference.

Use Safe Mode before you publish

Safe Mode is useful when you want to inspect the page without turning an uncertain suggestion into a final answer. Use it to keep tentative Ad Facts visible while you compare the release build, consent flow, and ad configuration. It is especially helpful when a team is reviewing an advertising identifier question and has not yet agreed whether a particular request path is active.

After confirmation, run Consistency Check across the outputs you maintain. Compare the Data safety review with your privacy policy, consent wording, account controls, and any Public Pages that describe how your app handles data. Public Pages do not replace the store form, and a store answer does not replace a user-facing explanation. They should describe the same product behavior without promising more than your implementation supports.

Common mistakes with AdMob

One common mistake is treating the presence of an AdMob dependency as proof that every advertising identifier is collected in every configuration. Another is assuming that non-personalized ads eliminate every disclosure question. A third is forgetting mediation or a second advertising SDK when reviewing the release bundle.

It is also easy to confuse “the SDK can process this” with “your app collects this for the purpose selected in the form.” Inspect your setup, permissions, consent state, and server-side records. Keep the wording factual and configuration-specific. Do not copy a neighboring app’s answers simply because both apps use AdMob.

Declora is not a law firm, and it cannot guarantee store approval. Its catalog and Consistency Check help organize evidence and surface questions; you remain responsible for confirming the facts and submitting the final information.

FAQ

Does using AdMob automatically mean I should select every advertising answer?

No. The service profile identifies likely and possible areas for review, while your production configuration determines what your app actually does. Confirm advertising purposes, advertising ID use, device identifiers, and any additional SDK paths before selecting an answer.

Are personalized ads the only reason ATT or tracking questions matter?

No. Personalization is one configuration signal, not the complete test. Review whether data is linked or used across apps or websites owned by other companies, how consent works, and which identifiers your integration makes available. A Google Play Data safety review and Apple’s tracking review are related but not interchangeable.

How should I handle a possible device identifier?

Keep the App Fact in a needs-confirmation state until you inspect the release configuration and data flow. Check whether the identifier is actually collected, what purpose it serves, whether it is shared, and whether your app’s own systems retain it. Then confirm the fact that matches the evidence.

What should I do when mediation changes after submission?

Revisit the Data safety answers and the relevant App Facts whenever the production data path changes. Recheck the SDK bundle, partner list, consent behavior, and privacy wording, then run Consistency Check again. A previous review is not a permanent answer for a changed build.