How to fill in the Google Play Data safety form (with an SDK guide)

The Data safety form looks like a questionnaire, but it works more like a sworn statement. What you enter becomes the "Data safety" section on your store listing, the part users read before they install. If it's wrong, Google can block your updates until you fix it.

The official help pages explain the rules one at a time, and every SDK vendor documents only its own SDK. This guide puts it in one place: what the form asks, what "collected" and "shared" actually mean, and what to declare for the SDKs most indie apps use.

Who has to fill it in

Everyone publishing to a production, open or closed testing track. Google's Data safety help page says:

Even developers with apps that do not collect any user data must complete this form and provide a link to their privacy policy.

So you need a privacy policy before you start. The form won't let you submit without the link.

You'll find it in Play Console under Policy and programs > App content > Data safety.

What the form asks, section by section

The form walks you through four steps.

1. Data collection and security. The yes or no questions that shape the rest:

• Does your app collect or share any of the required user data types?
• Is all of the user data collected by your app encrypted in transit?
• Which methods of account creation does your app support? (or "my app doesn't allow users to create an account")
• If users can create accounts: a web link where they can request account deletion. Our account deletion guide covers that page.

2. Data types. A list of categories (Location, Personal info, Financial info, App activity, App info and performance, Device or other IDs and more). You tick every type your app or its SDKs collect or share.

3. Data usage and handling. For each type you ticked: is it collected, shared or both, is it processed ephemerally, is it required or optional for the user, and what is it used for. The purposes are App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security and compliance, Personalization and Account management.

4. Preview. Google shows you the section as users will see it on the store listing. Read it as a user would before you submit.

"Collected" and "shared" mean specific things

Most wrong answers come from reading these words in their everyday sense.

Collected means the data is sent off the device, by your code or by any SDK or web view inside your app. Data that stays on the phone isn't collected, even if your app reads it. A notes app that saves notes only in local storage doesn't collect them.

Shared means the data is transferred to a third party. Again, SDKs count: if an ad SDK sends the advertising ID to its ad network, your app shares it.

Google lists cases that don't count:

• Not collection: data processed only on the device, data sent with end-to-end encryption that no one else can read, and data processed ephemerally (held in memory only as long as needed to serve a request).
• Not sharing: transfers to a service provider that processes data on your behalf, transfers for legal reasons, and transfers the user starts themselves (like sharing a photo to another app).

The service provider exception is the one that matters most for small apps. Firebase says it only passes data to subprocessors that help run its services, so data your app sends to Firebase is usually collected, not shared. An ad network is different: it uses the data for its own advertising business, so AdMob data is both collected and shared.

What to declare for common SDKs

This is a starting point built from each vendor's own disclosure page. SDK versions and settings change what's collected, so check the linked page for your setup before you submit.

A few notes on the table:

• AdMob lets you turn off advertising ID collection in the manifest. If you do, remove it from your answers.
• Card details are handled by Google Play during a purchase. They never reach your app, so you don't declare them.
• AI APIs usually act as service providers under their API terms, which keeps the data "collected" rather than "shared". Read the provider's data usage terms for your plan, especially if they can use inputs for training.
• If all of these send data over HTTPS, answer yes to "encrypted in transit".

A worked example

Say your app is a habit tracker with AdMob banners, Firebase Analytics, Crashlytics and no accounts. Your answers:

• Collects or shares required data: yes
• Encrypted in transit: yes
• Account creation: my app doesn't allow users to create an account (no deletion link needed)
• Location > Approximate location: collected and shared, advertising, analytics, fraud prevention
• App activity > App interactions: collected and shared, advertising, analytics
• App info and performance > Crash logs: collected, analytics
• App info and performance > Diagnostics: collected and shared, analytics, advertising
• Device or other IDs: collected and shared, advertising, analytics, fraud prevention

The habits themselves stay on the phone, so they aren't declared at all. That's the kind of detail worth saying in your privacy policy too, because users care about it more than about crash logs.

Make the form and your privacy policy agree

Reviewers read both. A few mismatches come up often:

• The form declares advertising, and the policy never mentions ads or names the ad network.
• The policy says "we don't collect personal data" while the form lists device IDs.
• The form says users can't create accounts, and the app has a sign-in screen.
• The policy promises deletion within 30 days, and the deletion page says 90.

Write both from one list of data types and services, and update both when you add an SDK. Adding Crashlytics in a patch release is a Data safety change too.

What happens if your answers are wrong

Google says you alone are responsible for complete and accurate declarations, including data collected by third-party code. If Google finds a mismatch, you'll get a policy email and may be blocked from publishing updates until you correct the form. Repeated or serious problems can lead to removal.

You can check yourself before Google does. Run your release through Google Checks or at least go through every SDK in your build file and look up its disclosure page. The dependency you forgot is almost always the one that collects device IDs.

When to update the form

Update it whenever the data your app handles changes: a new SDK, a new feature that uploads something, accounts added, ads added or removed. Submit the form change along with the app update that causes it, and update your privacy policy at the same time.