The Data Safety section of Google Play Console trips up a lot of developers — not because it's technically hard, but because it's genuinely unclear which boxes apply to your app if you've never mapped out exactly what AdMob and your other dependencies actually collect.
This isn't legal advice, and you should treat your own app's data practices as the source of truth — but here's the practical starting point we use when going through this form for AdMob-integrated apps.
Start with what AdMob itself collects
If your app uses Google AdMob for monetization, a baseline set of data types is typically involved regardless of what your own app code does, because AdMob's SDK collects it as part of serving and measuring ads:
- Device or other IDs — the advertising ID, used for ad personalization and frequency capping
- App interactions — ad clicks and impressions, used for measurement and fraud prevention
- Crash logs and diagnostics — standard SDK crash/performance reporting
- Approximate location — commonly used for regionally relevant ad targeting
These are generally marked as Collected, Shared (with the ad network), non-ephemeral, and often Required for the app's core ad-supported functionality — but confirm each of these against your specific AdMob configuration and any mediation networks you've added, since mediation partners can introduce their own data collection.
Check your other SDKs too
AdMob is rarely the only third-party code in an app. Analytics SDKs, crash reporting tools, and any social login or sharing integrations each have their own data collection footprint. The Data Safety form asks about your app's data practices as a whole, not just the ad SDK, so each dependency needs the same review.
A practical checklist before you fill out the form
- List every third-party SDK in your app — ads, analytics, crash reporting, login providers.
- For each one, check its own published data safety documentation (most ad networks and analytics providers publish exactly what to declare).
- Note whether each data type is collected (leaves the device) vs. only processed on-device — these are treated differently in the form.
- Determine whether data is shared with third parties (like an ad network) versus used only internally.
- Mark whether each data type is required for core functionality or optional.
- Decide whether your data practices are covered by an existing privacy policy, and make sure that policy is actually up to date before you submit — Google can and does check for consistency between your form answers and your linked privacy policy.
In practice: for an AdMob-integrated ringtone app, the data types that ended up marked Collected + Shared were Approximate location, App interactions, Crash logs, Diagnostics, and Device or other IDs — all non-ephemeral and Required, reflecting what the AdMob SDK actually gathers to serve and measure ads.
Common mistakes to avoid
- Under-declaring because you didn't realize your ad or analytics SDK collects something — this is the most common issue, and it's a policy risk, not just a form inaccuracy.
- Leaving the form outdated after adding a new SDK later — the Data Safety section needs updating whenever your app's data practices change, not just at first submission.
- Mismatched privacy policy — if your linked privacy policy doesn't mention data types you've declared in the form (or vice versa), that inconsistency itself can trigger a policy review.
The takeaway
Treat the Data Safety form as a direct reflection of your actual dependency list, not a one-time checkbox exercise. Every SDK you add is a reason to revisit it.