The Data Safety section turns into a public "Data safety" card on your store listing. Because users see it, Google treats inaccuracy as a policy violation rather than a paperwork slip. Getting it right the first time saves review cycles.
Before you open the form
Make a list of every third-party SDK in your build. Open your build.gradle dependency block and write down each one. Then find each SDK's own data-disclosure page — most major vendors publish exactly what their SDK collects. Your answers are the union of what your own code collects and what every SDK collects.
Filling the form from memory is how mismatches happen.
Section 1: Data collection and security
The opening questions set the shape of everything after.
- Does your app collect or share any of the required user data types? If you use AdMob, Firebase, or almost any analytics, the answer is yes. Answering no because "I don't store anything on my server" is wrong — data leaving the device counts.
- Is all user data encrypted in transit? If you use HTTPS everywhere, yes. Any plain HTTP call, including an old API you forgot, makes this no.
- Do you provide a way for users to request data deletion? If you have accounts, you need a real deletion path and a URL describing it.
Section 2: Data types
For every data type you declare, Play asks the same four follow-ups: is it collected, is it shared, is it processed ephemerally, and is it required or optional.
Two distinctions decide most of these answers:
- Collected vs shared: "collected" means it leaves the device to you. "Shared" means it goes to a third party. Ad SDKs almost always mean shared.
- Ephemeral processing: only if the data is used in memory and never persisted. Crash logs written to a service are not ephemeral.
The types that catch people out
- Device or other IDs — the advertising ID and Firebase installation IDs both land here. If you ship AdMob, declare it.
- App interactions — any analytics event at all.
- Crash logs and diagnostics — Crashlytics, Play Vitals reporting via an SDK.
- Approximate location — IP-derived location counts, even without the location permission.
- Photos, files, contacts — declare these if you request the permission, even for a feature most users never open.
Section 3: Security practices
You will be asked whether you follow the Play Families policy, whether your app has been independently validated against a security standard, and whether users can request data deletion. Only claim an independent security review if you genuinely had one.
Section 4: The preview
Play shows you the card exactly as users will see it. Read it as a sceptical user. If the card says "No data shared with third parties" while your app shows ads, stop and fix it — that discrepancy is exactly what gets reported and enforced.
Keeping it consistent, permanently
The Data Safety form is not a one-time task. Every time you add an SDK, revisit it. A common enforcement scenario: a developer adds a monetisation SDK in version 12, never updates Data Safety, and gets an enforcement notice months later.
The workflow that holds up over time is a single source of truth — one list of SDKs and the data each collects — that both your privacy policy and your Data Safety answers are generated from.