The Data safety section is the part of a Google Play listing where you tell users what data your app handles. People read it before installing, and Google compares it with what your app actually does. Filling it in carefully takes a little time up front and spares you awkward review messages later. This guide walks through the concepts, the usual traps with third-party SDKs, and a routine for keeping the form accurate over time.
Definitions and form fields change from time to time, so treat this article as a method rather than a rulebook. Whenever a detail matters, check the current policy in Play Console and read Google’s own Data safety help pages.
What the form is really asking
The form asks, in effect, four things about your app:
- Does the app collect or share any user data at all?
- Which categories and types of data are involved?
- Why is each type collected or shared, and is it optional?
- How is the data protected, and can users ask for it to be deleted?
The answers are shown on your public listing in a short summary. Because the summary is public, an overstatement can scare off users, and an understatement can put your listing at risk. Aim for accuracy in both directions.
Collected versus shared
These two words carry specific meanings in the form, and mixing them up is the most common error.
- Collected generally means data that leaves the user’s device and is received by you or by a service acting for you. Data that is only processed on the device and never transmitted is typically not counted as collected, though you should confirm the current wording in Google’s help text.
- Shared generally means transferring user data to a third party. Passing data to a service provider that processes it only on your behalf can be treated differently from handing it to a party that uses it for its own purposes. The form’s help text explains the exceptions, and they are narrow, so read them rather than assuming.
A practical approach is to write down every network call your app makes and note what each request contains. That list is the raw material for your answers. If a request contains a device identifier, an approximate location, or an account email, it belongs on the list.
Work out your data inventory first
Before opening the form, build a simple inventory. For each app, list:
- Data the user types in (name, email, notes, photos).
- Data the app reads from the device (contacts, files, location, advertising ID).
- Data generated by usage (events, crash traces, session length).
- Data that arrives from your server and is tied to an account.
Next to each item, write where it goes, who receives it, and why. Only then match each item to the form’s categories. Doing the inventory first prevents the usual pattern of answering from memory and forgetting the analytics library someone added last spring.
Third-party SDKs: ads, analytics, crash reporting
Most mismatches come from SDKs, not from your own code. You are responsible for what libraries inside your app do, even if you never wrote a line of them.
Advertising SDKs
Ad libraries commonly use device or advertising identifiers and may collect approximate location or interaction data. The SDK vendor usually publishes a page describing what its library collects and how to answer the Data safety form. Find that page, follow it, and note the date you read it so you can compare after the next SDK update. If you run several ad networks through mediation, each adapter may add its own disclosures.
Analytics SDKs
Analytics tools typically gather app interactions, device information, and identifiers. Settings matter here: some tools let you switch off identifier collection or truncate IP addresses. If you change a setting to collect less, make sure the form reflects the real configuration, not the default.
Crash reporting SDKs
Crash reporters usually collect diagnostics such as stack traces and device model information, and sometimes identifiers. These are easy to forget because developers think of them as technical plumbing, but the form still asks about diagnostics.
How to verify what an SDK actually sends
Do not rely on documentation alone. Run a debug build through a network inspection proxy on a test device and watch the requests. Compare what you see with the vendor’s description and with your form. Where the two disagree, trust the traffic and contact the vendor.
Purposes and optional data
For each data type you declare, the form asks why you collect or share it, for example app functionality, analytics, advertising, or account management. Pick every purpose that truly applies. Do not choose a purpose only because it sounds harmless.
The form also asks whether a data type is required or whether users can choose to provide it. If the app works fully without a particular permission, say it is optional. If the feature depends on it, say it is required. Keep these answers consistent with your in-app permission prompts, since users and reviewers will see both.
Security practices and deletion
The form asks whether data is encrypted in transit and whether users can request deletion. Answer from facts, not hopes.
- Encryption in transit: Confirm that every endpoint your app talks to, including SDK endpoints, uses secure connections. If any traffic goes out over an unencrypted channel, answer accordingly or fix the traffic first.
- Deletion requests: If you let users create accounts, Google asks for a way to request account and data deletion, including a link users can reach outside the app. Check the current requirements in Play Console for the exact expectations. Build a real process behind the answer: who receives the request, what gets erased, and how long it takes.
- Data you cannot delete: If you must retain some records, for example for legal reasons, explain that plainly in your privacy policy.
Keep the form and the privacy policy in sync
Your Data safety answers and your privacy policy describe the same reality from two angles, so they must agree. A reviewer, a journalist, or a curious user can compare them in a minute. Our guide on what a mobile app privacy policy should include lists the sections to cover, and the App Store privacy labels guide explains the Apple equivalent, which you should also keep aligned with the same inventory.
A simple rule: maintain one data inventory per app, and derive the policy, the Play form, and the App Store labels from it. When the inventory changes, update all three on the same day.
What happens if the form is wrong
Google treats inaccurate declarations as a policy matter. The possible outcomes depend on how serious and how repeated the problem is, and the details are set by Google, not by us. Read the current User Data and Data safety policy text in Play Console so you know what applies to you. Do not guess at thresholds or timelines. If you receive a notice, correct the form and the app quickly, and respond through the official channel with specifics about what you changed.
A review routine that scales
If you manage many apps, a routine matters more than heroics. The portfolio checklist describes inventories and calendars in more detail. For Data safety specifically:
- Before every release, diff the dependency list against the previous release. Any new or upgraded SDK triggers a re-read of its data disclosures.
- After every release that adds a permission, re-check the form entries tied to that permission.
- Once a quarter, run each app on a test device with a network proxy and confirm the traffic still matches the form.
- Record the date of each review in your inventory sheet.
Sensitive categories need extra care. If your app touches health or cycle data, read our pieces on FTC lessons for fertility app privacy and the cycle tracking privacy checklist, and be especially conservative in what you collect.
Common mistakes to avoid
- Declaring “no data collected” while an ad or analytics SDK is present.
- Forgetting crash logs and diagnostics.
- Treating an SDK’s defaults as your configuration.
- Updating the form but not the privacy policy.
- Copying another app’s answers without checking your own code.
- Leaving a forgotten debug or test library in a release build.
For more on running a publishing operation, browse the publishers hub.