The Google Play Data safety section is a form every Android developer must complete before publishing, and it tells users exactly what data your app collects, shares, and protects. It sounds bureaucratic, but it is really just a structured honesty exercise: you declare your data practices, and Google shows a summary card on your store listing. This guide walks through what the section is, how Google defines its terms, how to fill it out accurately, and what it looks like against one of my own published apps. Quick note up front: this is general guidance, not legal advice; the primary source is Google's own page, Provide information for Google Play's Data safety section.
What the Data safety section actually is
The Data safety section is a declaration you complete inside Google Play Console, under App content. You answer a series of questions about how your app handles user data, and Google turns those answers into a Data safety card shown on your Play Store listing.
That card is what users see before they install. It summarizes:
- Whether your app collects or shares any data
- What categories of data are involved
- Whether data is encrypted in transit and whether deletion can be requested
The form is required for every app on Google Play, even if your app collects nothing. Google's page puts it as: all developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open or production testing tracks. If you collect no data, you still declare that explicitly. There is no "skip" option.
Data collected vs data shared
Google draws a careful line between two words that sound similar but mean different things.
- Collected, in Google's words, means transmitting data from your app off a user's device. If your app sends it to a server, it is collected, and that includes data sent by third-party libraries and SDKs inside the app.
- Shared means transferring user data collected from your app to a third party. Google counts server-to-server transfers and on-device transfers to other apps, and excludes transfers to service providers that process the data on your behalf.
There are limited exceptions where Google says data does not count as collected or shared. Read the official definitions carefully, but they generally cover situations like:
- Data processed entirely on-device and never sent anywhere
- Ephemeral processing where data is used in memory and not retained
- Data that is end-to-end encrypted so you cannot read it
- Transfers that are user-initiated, where the user clearly directs the data to go somewhere (for example, choosing to email a file)
These exceptions are narrow. When in doubt, assume data is collected and declare it. Exact rules can change, so confirm against Google's current page, which also carries a changelog of what moved.
The data types and purposes you must declare
The form asks you to map each piece of data to a type and one or more purposes.
Common data type categories include:
- Location (approximate or precise)
- Personal info (name, email, address)
- Financial info (payment details, purchase history)
- Messages (emails, SMS, in-app messages)
- Photos and videos
- App activity (interactions, in-app search history)
- Device or other IDs
For each type you collect, you declare why. Purposes include:
- App functionality
- Analytics
- Advertising or marketing
- Personalization
- Account management
- Fraud prevention and security
A single data type can serve several purposes. An email address, for instance, might support account management and fraud prevention at the same time. Declare every purpose that applies, not just the main one.
Security practices you disclose
Beyond what you collect, the form asks how you protect it. The two questions developers see most often are:
- Is the data encrypted in transit (protected while moving between the device and your servers)?
- Can users request that their data be deleted?
You should only answer "yes" to encryption in transit if it is actually true for the data in question. Be honest here.
One point that trips up many developers: your answers must cover third-party SDKs too. If a software development kit bundled into your app collects data, that counts as your app collecting it. For example, SDKs like Firebase, AdMob, or Crashlytics may collect certain data if your app uses them — but you must check each SDK's own documentation to confirm what it actually collects and how. Do not guess. Many SDK providers publish a Data safety guide listing the values they recommend.
How it connects to your privacy policy
The Data safety form and your privacy policy are separate, but they have to agree with each other.
- Google Play requires a valid privacy policy URL for most apps.
- The data practices described in your privacy policy must match what you declare in the form.
Mismatches are one of the most common reasons apps get flagged or rejected. If your form says you collect location but your privacy policy never mentions it — or vice versa — that inconsistency can hold up your release. Inaccurate or inconsistent declarations can lead Google to reject or even remove an app, so consistency is not optional.
If you do not yet have a policy, you can generate a starting template with our Google Play privacy policy generator and then adapt it to your real practices. Not sure whether you even need one? Our guide on do you need a privacy policy for your app explains when it is required.
What it looks like for a real app
The clearest way to see the form is to hold it against an app's actual behaviour. Media Rescue is one of mine, and its privacy policy is written to be read next to the Data safety card. The relevant facts in it:
- Finding, restoring and fixing files happen on the phone. The app does not upload or store the user's files on any server, and there is no account.
- Two Google services are built in. Firebase Analytics records app events as short codes and counts, with the device model, Android version, language, country and an app-instance identifier. Firebase Crashlytics records crash reports with the device model, Android version, an installation identifier and a stack trace. File names and paths are stripped before a report is sent.
- There are no ads, no advertising SDK and no advertising ID.
Those sentences are the raw material of the form. The files themselves are processed on-device and never transmitted, so they are not "collected" under Google's definition. The analytics events and the crash reports do leave the device, so they are collected, with purposes of analytics and diagnostics, and the identifiers Firebase creates are declared with them. Nothing is passed to an advertising network, which is what keeps the "shared" column clean. Google treats data sent by an SDK exactly as if your own code sent it, which is why the SDK list in your build decides most of the answers.
How to fill it out, step by step
Here is the general flow inside Play Console:
- Open Play Console and select your app.
- Go to App content in the left menu.
- Find the Data safety section and start the form.
- Answer the data collection and sharing questions for each data type.
- Declare the purposes and security practices, including anything your SDKs do.
- Add your privacy policy URL where requested.
- Submit the declaration — it goes through with a release.
Before you start, review the documentation for every SDK in your app so you can answer accurately. Take your time on the SDK questions; that is where most mistakes happen.
Two questions that come up
Is the Data safety section the same as Apple's App Store privacy labels? No. They are separate systems with different categories and rules. Filling out one does not satisfy the other, so you complete each platform's requirements on its own.
Does the privacy policy generator on this site fill in or submit the Data safety form? No. It produces a privacy policy draft you review and adapt. The form is always completed by you in Play Console, and Google's page is explicit that you alone are responsible for making complete and accurate declarations; when Google finds a discrepancy between app behaviour and the declaration, it may take enforcement action.
A policy that tells the same story
Your Data safety answers and your privacy policy need to tell the same story. A clear, accurate policy makes the whole process smoother. Use our free Privacy Policy Generator to create a starting template right in your browser — no upload, no signup — then review and adapt it to match what you actually declare. Remember, this is a starting point, not legal advice.
The Data safety form is one of several things Play Console checks before a listing goes live. If you are still assembling the rest, the Google Play icon resizer produces the 512 × 512 PNG the listing requires and the feature graphic resizer the 1024 × 500 banner — both in the browser, nothing uploaded.
Is your Android app a wrapper for your website? Turn your website into an app with our builder: the publishing kit drafts the Data safety answers for the app it builds. Built your site with Base44? Here is how we published a Base44 app on Google Play, step by step.