Google Play data safety form: steps, SDK answers and fixes

The Google Play data safety form is the declaration in Play Console that tells Google, and everyone who opens your store listing, what user data your app collects, what it shares, and how it protects that data. Every app on Google Play needs one, including apps that collect nothing at all. Get it wrong and Google can block your updates or remove the app; get it right and it becomes a small trust signal on the page where people decide whether to install.

This guide walks through the form in the order Play Console asks the questions, explains the definitions that decide most answers, shows what common SDKs such as Firebase and AdMob send off the device, and covers how to fix the "Invalid Data safety form" rejection that catches many first-time publishers.

Key takeaways

• Every app on a closed, open or production track must complete the form. Only apps that live exclusively on the internal testing track are exempt.
• "Collected" means sent off the device, by your code or by any SDK in the app. "Shared" means sent to a third party.
• You are responsible for your SDKs. Most rejections name an SDK that sends Device or other IDs the form did not declare.
• Keep a written data inventory and re-check the form whenever you add an SDK or a feature.

What the Google Play data safety form is#

Google has required an accurate, complete form from every app since July 20, 2022. Its help article on the Data safety section states the rule plainly: "All developers must declare how they collect and handle user data," and that includes data handled by third-party libraries and SDKs.

The answers you give are turned into the Data safety section of your store listing. A visitor sees whether the app shares data with third parties, which data types it collects, whether data is encrypted in transit and whether they can ask for it to be deleted. It sits on the same page as your screenshots and reviews, so it is part of your store listing whether you think of it that way or not.

Who has to fill it out#

According to Google's help article:

• Every app with a closed, open or production track, including apps that collect no user data. Google: "Even developers with apps that do not collect any user data must complete this form."
• A privacy policy is required for every app, again including apps that collect nothing.
• Exempt: apps that are exclusively on the internal testing track, system services and private apps.

If you are on a newer personal account, the form is one of the App content items you must finish before closed testing starts. Our guide to the Google Play 12 testers for 14 days requirement covers that path end to end.

The definitions that decide your answers#

Most mistakes in the form come from reading "collect" and "share" in their everyday sense. Google defines them narrowly, and the exceptions matter.

What counts as "collected"#

Google says collect means "transmitting data from your app off a user's device." That includes:

• data your own code sends to your server;
• data sent off the device by any library or SDK in your app;
• data from a webview your app controls (open-web browsing in a webview is not included).

Three cases do not need to be disclosed as collection:

• On-device processing. Data that never leaves the phone.
• End-to-end encryption. Data that no one except the sender and recipient can read.
• Ephemeral processing. Data handled only in memory and kept "for no longer than necessary" to serve the request. It is still part of your form answers, but it is not shown on the listing. Google is explicit that data used for advertising or user profiles cannot be ephemeral.

Pseudonymous data, such as an analytics ID that is not tied to a name, still counts.

What counts as "shared"#

Sharing means transferring collected data to a third party, whether from your server or from the device to another app. These transfers are not sharing:

• Service providers that process data on your behalf, such as your hosting or crash reporting vendor. A provider that builds ad profiles across its customers does not qualify.
• Legal transfers, such as a response to a government request.
• User-initiated transfers the user reasonably expects, or that follow a prominent in-app disclosure and consent.
• Fully anonymized data that "can no longer be associated with an individual user."

Optional or required#

A data type is optional only if every user, on every device and in every region, can decline it and still use the app's core features. If any version of the app requires it, declare it as required.

How to fill out the data safety form, step by step#

Step 1: Build a data inventory before you open Play Console#

The form is quick once you know the answers and painful when you do not. Before you start, write down a table like this for your app, one row per data type:

To fill the "Sent off device by" column:

1. List every SDK from your build.gradle files (or pubspec.yaml, package.json for React Native, and the Expo config plugins). A one-line check for an Android project:

   ./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -E "firebase|gms|ads|analytics|crash|facebook|appsflyer|adjust|onesignal|sentry"
   

2. Read each SDK's data disclosure page. Most large SDKs publish one for this form, and the Google Play SDK Index links to many of them.

3. Check your own API calls: every field in sign-up, profile, upload, search and support requests.

4. Check permissions in the merged manifest. Location, contacts, camera and microphone usually mean you collect something, even if you only use it briefly.

The data inventory starts in your dependency list, not in Play Console. Photo: Cláudio Emanuel / Pexels

Step 2: Open the form in Play Console#

In Play Console, select your app, open the App content page, and choose Start under Data safety. Read the overview and select Next.

Step 3: Answer the data collection and security questions#

The first section asks:

• Does your app collect or share any of the required user data types? Answer Yes if any row of your inventory exists, which is the case for almost every app that uses analytics, crash reporting or ads.
• Is all of the user data collected by your app encrypted in transit? Answer Yes only if it is true for all data, including every SDK. Google recommends standards such as TLS and HTTPS.
• Do you provide a way for users to request that their data is deleted? You can answer yes if you offer a deletion request or if you automatically delete or anonymize data within 90 days.

If your app lets people create an account, Google's account deletion requirements also apply: you must offer deletion inside the app and on a web page, and you enter that web link in this form. The page must load without errors, make the deletion path easy to find, and name the app or developer as it appears on your listing.

Step 4: Select the data types#

Google groups data into 14 categories: Location, Personal info, Financial info, Health and fitness, Messages, Photos and videos, Audio files, Files and docs, Calendar, Contacts, App activity, Web browsing, App info and performance, and Device or other IDs. Tick every type in your inventory. The two that people most often forget are App info and performance (crash logs, diagnostics) and Device or other IDs.

Step 5: Describe how each data type is used#

For each type, the form asks whether it is collected, shared or both; whether it is processed ephemerally; whether it is required or optional; and why. The purposes are fixed:

• App functionality
• Analytics
• Developer communications
• Advertising or marketing
• Fraud prevention, security, and compliance
• Personalization
• Account management

Pick every purpose that applies to that data type, including the purposes of the SDKs that send it.

Step 6: Preview and submit#

The last page shows a Store listing preview of how your Data safety section will look. Read it as a stranger would. Then select Submit, or Save as draft if you need to check something. Google's review of the form happens alongside app review, and the help article warns that expanded reviews can take "up to 7 days or longer in exceptional cases". Our guide to how long Google Play review takes explains what to expect while you wait.

Managing several apps: the CSV option#

Near the top right of the form, Export to CSV downloads your answers, and the import option loads a completed file. Google provides a sample CSV to fill offline, with one response per row and TRUE or FALSE values. Importing overwrites your existing answers, so export a backup first. If you publish several apps built on the same stack, one reviewed CSV per stack saves time and keeps answers consistent.

Data safety answers for common SDKs#

The table below summarizes what the SDK vendors themselves publish. Treat it as a starting point and check the vendor page for the version you ship, because SDKs change what they collect.

Firebase says it "encrypts the data in transit using HTTPS", and Google says all data the Mobile Ads SDK collects "is encrypted in transit using TLS". That helps you answer the encryption question, but only if your own endpoints use HTTPS too.

Two details catch people out:

• What you attach is yours to declare. If you send a user's email as a Crashlytics user ID, you now collect Personal info through Crashlytics.
• Ads change the sharing answer. Ad SDKs typically share identifiers with ad networks for advertising, which is sharing under Google's definition, not service-provider processing.

Every SDK you add is a new row in your data inventory. Photo: cottonbro studio / Pexels

How to fix "Invalid Data safety form"#

The most common rejection reads like this one, which a developer posted on the B4X forum in December 2024: "We detected user data transmitted off device that you have not disclosed". The notice named the data type, Device Or Other IDs, and a possible SDK, the Google Play services measurement library that Firebase Analytics depends on. Threads on the MIT App Inventor and Kodular forums show the same pattern.

To fix it:

1. Read the full notice in Play Console or in the email Google sends. It names the version code, the data type and usually the SDK.
2. Find where that SDK comes from. It is often a transitive dependency: an ads mediation adapter, an analytics package pulled in by a game engine, or a billing library. Run the Gradle dependency command above and look for the package name in the notice.
3. Choose one of the two fixes Google offers: declare the data type in the form with the right purposes, or remove or reconfigure the SDK so it no longer sends the data. AdMob, for example, documents a manifest setting that stops advertising ID collection.
4. Update the form, then submit a new release if you changed code. The old version code stays flagged until it is replaced.
5. Check your privacy policy says the same thing. A form that lists location while the policy never mentions it is an inconsistency reviewers notice.

Google's help article is clear about where responsibility sits: its review "is not designed to verify the accuracy and completeness of your data safety declarations," you alone are responsible for them, and apps that stay non-compliant can have updates blocked or be removed from Google Play.

A data safety form checklist#

Run this before every release that adds an SDK, a permission or a feature that touches user data:

• Data inventory updated, one row per data type, with the code or SDK that sends it.
• Every SDK's vendor disclosure page checked for the version in this release.
• Device or other IDs declared if you use analytics, crash reporting with IDs, or ads.
• Encryption in transit answered Yes only if every endpoint, yours and the SDKs', uses HTTPS or TLS.
• Account deletion offered in the app and on a working web page, with the link in the form, if users can create accounts.
• Privacy policy URL works and describes the same data types and purposes.
• Store listing preview read once as a stranger would read it.
• CSV export saved as a backup and committed next to the code.

The form is only half the store privacy work if you ship on both platforms. Apple asks similar questions for its App Privacy details in App Store Connect, and the same data inventory answers both. If you are setting up a store account for the first time as a company, our guide to the DUNS number for Apple Developer and Google Play accounts covers the identity side, and the guide on how to name an app covers the name your listing will carry.

A clear listing is easier to promote#

Google does not say the Data safety section changes your search ranking. What it does change is how safe your listing looks to the people who reach it, and an app that has updates blocked over an unresolved form cannot ship the fixes and features that keep it visible. Treat the form like your screenshots: part of the page that has to be right before you send traffic to it.

Once it is, the next job is getting people to that page. AppRanker is one way to do that from day one: it is a pay-to-rank app leaderboard where rank is set by what each listing has paid, and every row links straight to your Google Play or App Store page. To see what a spot would cost, paste your Google Play link on the AppRanker home page; every rank shows its price before you pay.

FAQ#

Do I need to fill out the data safety form if my app collects no data?#

Yes. Google says even apps that do not collect any user data must complete the form and provide a privacy policy. You answer No to the collection question and submit, and the listing then shows that no data is collected.

Does the internal testing track need a data safety form?#

No. Apps that are active only on the internal testing track are exempt. As soon as the app is on a closed, open or production track, the form is required.

Do I have to declare data collected by Firebase or AdMob?#

Yes. Data that SDKs send off the device counts as collected by your app. Firebase and Google Mobile Ads publish data disclosure pages for this form; use them together with your own data inventory.

What does "Invalid Data safety form" mean?#

Google detected data leaving the device that the form does not declare, usually Device or other IDs sent by an analytics or ads SDK. Declare the data type with the right purposes, or remove or reconfigure the SDK, then submit a new release.

Does the Data safety section affect Google Play ranking?#

Google does not document any ranking effect. It does affect what visitors see on your listing, and an unresolved policy issue can block updates or lead to removal, which hurts visibility far more.

How often should I update the data safety form?#

Whenever your data practices change: a new SDK, a new permission, a new feature that sends data, or a new purpose for existing data. Google asks developers to keep the form accurate and complete at all times.

Image credits#

• Cover, hand holding an Android phone with app icons: photo by MOHI SYED on Pexels, Pexels License. Cropped to 1200x630.
• Developer reviewing code at a desk: photo by Cláudio Emanuel on Pexels, Pexels License. Resized.
• Typing code on a laptop: photo by cottonbro studio on Pexels, Pexels License. Resized and cropped.