Google Play Data Safety Form: A Plain-English Walkthrough

Somewhere between uploading your first build and starting closed testing, the Play Console stops you with the Data Safety form. It looks simple: a handful of checkboxes about what data your app collects. In practice, it's one of the most commonly filled-out-wrong sections in the entire publishing flow, and getting it wrong doesn't just look bad, it can trigger real policy trouble down the line.

What the form actually asks

Google wants three things from you, honestly and specifically:

• What data your app collects. Not just what you intentionally collect, but everything, including data gathered by third-party SDKs you've integrated (analytics tools, ad networks, crash reporters).
• How that data is used and shared. Whether it stays on-device, gets sent to your servers, or is shared with third parties for advertising or analytics.
• How it's protected. Whether data is encrypted in transit, whether users can request deletion, and whether collection is optional or required to use the app.

The mistake almost everyone makes

Developers fill this out based on what they think their app does, not what it actually does. The gap is almost always the SDKs. Firebase Analytics, AdMob, Crashlytics, and most ad networks all collect data on their own, often more than developers realize, and that collection counts toward your declaration whether you remembered it or not. If you're not sure what an SDK collects, check its own privacy documentation directly rather than guessing.

Section by section, what to actually declare

Data collection and sharing

List every category that applies: location, personal info (name, email), financial info, health data, messages, photos and videos, app activity, device or other IDs. Err toward over-declaring rather than under-declaring; a data type you're not sure about should usually be included, since the downside of an unnecessary disclosure is much smaller than the downside of a missing one.

Purpose of collection

Google wants specific purposes: app functionality, analytics, advertising or marketing, fraud prevention, personalization, account management. Match this to what you actually use the data for. "Advertising" and "Analytics" are the two most commonly under-declared purposes, because developers think of them as automatic background processes rather than active data uses.

Data security practices

Whether data is encrypted in transit (almost always yes if you're using standard HTTPS), whether users can request data deletion, and whether you follow Google's Families Policy if your app targets children. Answer these based on your actual backend and account infrastructure, not aspirationally.

Optional vs. required data collection

Data collection tied to a feature the user can decline (like location for a "find nearby" feature that isn't core to the app) should be marked optional. Data required just to use the app at all (like an email for account creation) is required.

Why this matters beyond just filling out a form

The Data Safety section appears publicly on your Store listing, so users see it before installing. But more importantly for closed testing developers, Google's review systems check this declaration against real app behavior, sometimes automatically, sometimes as part of the same review process that evaluates your Production access application. A mismatch here is one of the policy violations that can trigger the account suspensions we cover in what actually gets developer accounts suspended.

A quick audit before you submit

1. List every third-party SDK in your app (check your build dependencies, not just what you remember adding).
2. Look up each SDK's own data collection disclosure, most major ones (Firebase, AdMob, Facebook SDK) publish this directly.
3. Cross-reference against what you declared. Add anything missing.
4. Re-read your purposes section and make sure "analytics" and "advertising" are checked if you use any ad network or analytics tool at all.
5. Keep a saved copy of your declaration and reasoning, so if Google ever asks you to justify it, you have your answer ready.

Getting this right the first time saves you a policy flag later, and it's one less thing to worry about while you're managing the 12-tester, 14-day closed testing window covered in our full setup guide.