Table of contents
- Quick nav
Google Play Data Safety Form: How to Fill It Out (Collection vs Sharing, SDKs, and Common Rejections)
What the Data safety form is
The Data safety section on a Google Play listing tells users what data your app collects and shares, why, and how you protect it. It's generated from the Data safety form on the App content page in Play Console (Policy and programs → App content). Google Play reviews your answers as part of app review, then shows them on your store listing.
Google's official help article sets out a few rules worth knowing up front:
| Rule | Details |
|---|---|
| Who must complete it | Every app published on Google Play, including closed testing, open testing and production tracks |
| Who's exempt | Apps active only on the internal testing track; system services and private apps |
| No data collected? Still required | Declare that you collect and share nothing, and provide a privacy policy link |
| Privacy policy | Required to complete the form; the link must be publicly accessible |
| Third-party code | Data collected or shared by SDKs and libraries counts toward your declaration |
| Responsibility | You alone are responsible for accurate declarations; if Google finds a mismatch with app behavior, it may take enforcement action |
If you're working through the 12 testers for 14 days closed testing requirement, Data safety is one of the app setup tasks you must finish before starting that closed test.
Collection vs sharing
This is where most mistakes happen. Google defines the terms like this:
| Term | Google's meaning | Example |
|---|---|---|
| Collect | Transmitting data off the user's device, whether to your server or a third party | Uploading a profile photo to your backend; a crash SDK sending device info |
| Share | Transferring data collected from your app to a third party | Your server syncing user emails to an ad platform; an ad SDK sending device IDs straight to an ad network |
What doesn't count as collection
- On-device processing: data accessed and processed locally that never leaves the device.
- End-to-end encryption: data sent off device that nobody but the sender and recipient — not even you — can read.
Ephemeral processing still has to be entered in the form, but if it meets Google's bar (kept only in memory and retained no longer than needed to serve the request), it won't be shown on your listing. Data used to build advertising or user profiles can't be treated as ephemeral.
What doesn't count as sharing
- Transfers to a service provider processing data on your behalf and under your instructions, such as a cloud host;
- Transfers for legal purposes, such as legal obligations or government requests;
- Transfers the user initiates, or that follow a prominent disclosure and consent;
- Data that is fully anonymized and can no longer be associated with an individual.
Step-by-step
- Map your data flows. List declared permissions, APIs you call, your own server endpoints, and every SDK — analytics, crash reporting, ads, sign-in, payments, push.
- Check SDK guidance. Google recommends your SDK providers' published Data safety guidance; look for links in the Google Play SDK Index. Ads and analytics SDKs typically collect device or other IDs and app activity.
- Answer the overview questions. Do you collect or share any of the required user data types? Is all data encrypted in transit? Do you provide a way for users to request data deletion?
- Select data types. For example location, personal info, financial info, health and fitness, messages, photos and videos, audio, files and docs, calendar, contacts, app activity, web browsing, app info and performance, and device or other IDs.
- Add details for each type. Collected or shared, processed ephemerally or not, required or optional, and purposes — app functionality, analytics, developer communications, advertising or marketing, fraud prevention/security/compliance, personalization, account management.
- Preview and submit. Make sure the listing preview matches reality; the changes go live with the next review.
If several apps share the same SDK stack, use the form's export/import option to keep declarations consistent.
Security practices and account deletion
Security practices appear directly on your listing, so be precise:
| Item | What to watch |
|---|---|
| Encrypted in transit | Only tick it if all collected data travels over encrypted connections — "mostly HTTPS" isn't enough |
| Data deletion | If you say users can request deletion, the mechanism has to actually work |
| Account deletion | Apps that let users create an account must offer account deletion both in the app and on the web, and enter the web deletion link in Play Console |
| Independent security review | Optional; apps that complete the relevant security assessment can show a badge, but it isn't required |
Common rejections and warnings
- Broken privacy policy link, or a policy that contradicts the form.
- Undeclared SDK data — most often advertising ID, crash logs and app interactions.
- Permissions vs declaration mismatch — requesting location or contacts while claiming no collection.
- Missing account deletion — sign-up supported but no deletion path or web link.
- Stale form after an update — a new SDK or feature shipped without updating Data safety.
How it differs from Apple's privacy labels
The logic is similar but the vocabulary isn't. Apple focuses on whether data is linked to the user's identity and used for tracking; Google focuses on collection vs sharing and ephemeral processing. If you ship on both stores, keep one master data inventory and map it to each form. For the Apple side, see our App Store privacy nutrition label guide.
Takeaway
The Data safety form isn't a formality. It shapes user trust on your listing and gets checked against how your app actually behaves. Audit permissions and SDKs first, fill in each item using Google's collection/sharing/exemption rules, and update the form every time you add an SDK. If your listing screenshots and icon need a refresh at the same time, AppShot Maker can help you rebuild them quickly.