Google Play Data Safety Form: 2026 Walkthrough

Google Play rejected your update for an "invalid Data safety form," or you are filling it in for the first time and want to get it right: the form has to describe every piece of user data your app and its SDKs touch, and Google now cross-checks your answers against an automated scan of your app bundle. This is a section-by-section walkthrough for 2026, including a large SDK-to-data-types mapping table. Generate a matching privacy policy from your real SDK list →

What the Data safety form is and why it gets rejected

The Data safety section shows on your Play Store listing as a summary of what your app collects, what it shares, and your security practices. You complete it in Play Console under App content, Data safety. Google's rule is that the declaration must cover all user data collected or shared by your app, "including data collected and handled through any third-party libraries or SDKs" you bundle. It applies across every app version available to users and every region you ship to.

Getting it wrong is not a soft warning. An inaccurate or incomplete form is an "invalid Data safety form" and is grounds to reject the update, block further updates, or remove the app. In 2026 the common trigger is drift: the form still describes last year's SDK set, an SDK was added or upgraded, and Google's binary scan now sees a data flow the form does not mention.

Section 1: Data collection and security

The form opens with a few yes/no questions that decide how much of the rest you have to fill in:

Does your app collect or share any of the required user data types? If yes, you move on to the data-types list. "Collect" means the data leaves the device; "share" means it is transferred to a third party.
Is all of the user data collected by your app encrypted in transit? This is all-or-nothing — see the dedicated section below.
Do you provide a way for users to request that their data is deleted? If yes, you supply a URL. If your app has accounts, there is a separate, stricter account-deletion declaration.
Optional badges: an independent security review against the Mobile Application Security Assessment (MASA) programme, and Families policy / "Designed for Families" compliance.

Section 2: Data types

You then pick, from 14 groups, every specific type your app or an SDK collects or shares:

Location — Approximate location, Precise location
Personal info — Name, Email address, User IDs, Address, Phone number, Race and ethnicity, Political or religious beliefs, Sexual orientation, Other info
Financial info — User payment info, Purchase history, Credit score, Other financial info
Health and fitness — Health info, Fitness info
Messages — Emails, SMS or MMS, Other in-app messages
Photos and videos — Photos, Videos
Audio files — Voice or sound recordings, Music files, Other audio files
Files and docs — Files and docs
Calendar — Calendar events
Contacts — Contacts
App activity — App interactions, In-app search history, Installed apps, Other user-generated content, Other actions
Web browsing — Web browsing history
App info and performance — Crash logs, Diagnostics, Other app performance data
Device or other IDs — Device or other IDs (includes the Advertising ID and any resettable or hardware identifier)

Section 3: the follow-up questions for each data type

For every type you select, Google asks the same set of questions:

Collected, shared, or both. "Collected" is transfer off the device for any length of time. "Shared" is transfer to a third party. Data handed to a service provider that only processes it on your instructions is not "shared"; data sent to an advertising network, an attribution partner, or any company that uses it for its own purposes is "shared". Legally compelled transfers and transfers for a user-initiated action also do not count as sharing.
Is this data processed ephemerally? Yes only if the data is accessed in memory, not written to persistent storage, and kept no longer than needed to service the request. This is rare; most logging or analytics use fails it.
Is collection required or optional? "Users can choose whether this data is collected" (there is a real toggle or the feature is opt-in) versus "Data collection is required to use the app".
Purposes. One or more of: App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention security and compliance, Personalization, Account management. You answer purposes separately for collection and for sharing.

"Data is encrypted in transit"

You can only answer yes if every network call that carries user data — yours and every SDK's — uses TLS. A single SDK endpoint on plain HTTP, a legacy analytics beacon, or an Android build with android:usesCleartextTraffic="true" and no network security config means you must answer no. Check your network_security_config.xml and run the app through a proxy if you are unsure. Answering yes when a scan finds cleartext is a fast way to an invalid-form rejection.

"Users can request data deletion" and the Delete Account URL

There are two related things here. The first is a general data-deletion request method: a URL where any user can ask you to delete their data. The second applies if your app supports account creation — Google's account-deletion policy, enforced since May 31, 2024 (the original deadline was December 7, 2023), requires both:

an in-app path to delete the account and its associated data, and
a public web URL where users can request account and data deletion without reinstalling the app.

The URL must be functional, not behind a login wall, and it must feature the deletion request prominently rather than bury it in a generic support page. You declare, per data type, whether it is deleted or retained; retention is allowed only for narrow reasons such as security, fraud prevention, or legal compliance, and you must state those in your privacy policy. Play shows the URL and a data-deletion badge in the Data safety detail page on your listing. Use the account deletion page generator to produce a compliant page, and see the Google Play account deletion requirement for the full policy.

SDK to Data safety data types

Most rejections come from SDK data that the developer never declared. Work from the SDKs your app actually links — generate a dependency tree (gradlew app:dependencies) or use the SDKs list in Play Console — and map each one. The table below covers the common cases in a default configuration. Every SDK name links to a full privacy-policy clause; the app SDK privacy policy clauses hub explains the "tracking" and processor-versus-controller distinctions that decide the "Shared" column.

SDK	Play Data safety data types	Collected / Shared	Typical purposes
Google Analytics for Firebase	Device or other IDs; App activity (App interactions, In-app search history, Other actions); App info and performance (Diagnostics)	Collected; shared only if Google ad features or data-sharing settings are enabled	Analytics, App functionality (Advertising if ad features on)
Firebase Crashlytics	App info and performance (Crash logs, Diagnostics); Device or other IDs	Collected; not shared	App functionality, Analytics
Firebase Performance Monitoring	App info and performance (Diagnostics, Other app performance data); Device or other IDs	Collected; not shared	Analytics, App functionality
Firebase Cloud Messaging	Device or other IDs (registration token); Messages (Other in-app messages, if you send content payloads)	Collected; not shared	App functionality
Firebase Authentication	Personal info (Email address, Name, User IDs; Phone number for phone auth)	Collected; not shared	App functionality, Account management
Google Sign-In	Personal info (Name, Email address, User IDs)	Collected; not shared	App functionality, Account management
Sign in with Apple	Personal info (Name, Email address or private relay, User IDs)	Collected; not shared	App functionality, Account management
Google AdMob	Device or other IDs (Advertising ID); Location (Approximate); App activity (App interactions, Other actions)	Collected and Shared	Advertising or marketing, Analytics, Fraud prevention
Meta Audience Network	Device or other IDs; App activity	Collected and Shared	Advertising or marketing, Analytics
AppLovin MAX	Device or other IDs; App activity; Location (Approximate)	Collected and Shared	Advertising or marketing, Analytics
Unity Ads	Device or other IDs; App activity	Collected and Shared	Advertising or marketing, Analytics
ironSource LevelPlay	Device or other IDs; App activity	Collected and Shared	Advertising or marketing, Analytics
AppsFlyer	Device or other IDs; App activity (App interactions, Other actions); Location (Approximate, from IP); Financial info (Purchase history) if you send revenue events	Collected and Shared	Advertising or marketing, Analytics, Fraud prevention
Adjust	Device or other IDs; App activity; Location (Approximate)	Collected and Shared	Advertising or marketing, Analytics, Fraud prevention
Branch	Device or other IDs; App activity	Collected and Shared	Advertising or marketing, Analytics, App functionality (deep links)
Amplitude	Device or other IDs; App activity (App interactions, In-app search history, Other actions)	Collected; not shared (processor)	Analytics
Mixpanel	Device or other IDs; App activity	Collected; not shared (processor)	Analytics
PostHog	Device or other IDs; App activity (none as a third party if you self-host)	Collected; not shared	Analytics, App functionality
Segment	Device or other IDs; App activity; Personal info (any traits you pass)	Collected and Shared (fan-out to downstream destinations)	Analytics, App functionality
Sentry	App info and performance (Crash logs, Diagnostics); Personal info (only if you attach user context)	Collected; not shared	App functionality, Fraud prevention and security
OneSignal	Device or other IDs (push token); App activity; Location (Approximate, optional)	Collected; shared with OneSignal as processor — declare per your contract	App functionality, Analytics
RevenueCat	Financial info (Purchase history); Device or other IDs (app user ID)	Collected; not shared	App functionality, Analytics, Fraud prevention
Stripe	Financial info (User payment info, Purchase history); Personal info (Name, Email address, Phone number, Address)	Collected and Shared (Stripe is an independent controller for fraud and compliance)	App functionality, Fraud prevention
Superwall	App activity (App interactions); Financial info (Purchase history); Device or other IDs	Collected; not shared	Analytics, App functionality
Supabase	Whatever you store: Personal info, App activity, Files and docs	Collected; not shared (your sub-processor)	App functionality

Notes on the table:

Processor versus third party decides "Shared". Analytics, crash, backend and auth SDKs that only act on your instructions are "collected, not shared". Ad networks and attribution partners use the data for their own measurement and modelling, so they are "shared".
Self-hosting removes the transfer. Run PostHog, Sentry or Supabase on your own infrastructure and there is no third-party sharing — you still declare collection.
Advertising ID. If any SDK reads it, declare Device or other IDs, and remember that apps targeting Android 13 or later must also declare the com.google.android.gms.permission.AD_ID permission.
Configuration expands the row. Enabling revenue events, a customer user ID, IP geolocation, or extra SDK modules adds data types beyond what is listed here.
Keep three things in sync: this form, your App Store privacy label, and your hosted privacy policy. Reviewers on both stores compare them.

How mismatches trigger enforcement

Google runs static and dynamic analysis on your bundle. When the scan sees a data flow — AdMob or a Firebase library sending a device identifier to Google, a crash reporter uploading diagnostics, an SDK deriving approximate location from an IP address — and your form does not declare it, the form is marked invalid. The most common misses are the ones that "feel like infrastructure": crash reporting, push tokens, and attribution SDKs initialised in a wrapper library. Because the check runs on every submission, an app that passed for a year can be rejected right after a Play Console policy update with no code change on your side. The fix is always the same: rebuild the form from the current dependency list rather than editing last year's answers.

Pre-submission checklist

Produce a full dependency list and flag every SDK that opens a network connection.
For each SDK: collected? shared? which data types? required or optional? processed ephemerally?
Confirm every endpoint is HTTPS; check usesCleartextTraffic and the network security config.
Add a data-deletion request URL. If the app has accounts, add the account-deletion URL and confirm the in-app path works without reinstalling.
Re-open and re-verify the form after every SDK add, removal, or major version bump.
Diff the form against your App Store privacy label and your published privacy policy.
Keep a dated screenshot of the submitted form for your records.

Reply template for a Data safety rejection

Hello,

Re: Data safety declaration - com.example.app

We have re-reviewed our Data safety form against our current SDK set
(app version 3.4.0). Changes made:

- Device or other IDs: now declared as Collected and Shared, purpose
  Advertising or marketing, for the Google AdMob SDK.
- App info and performance (Crash logs, Diagnostics): now declared as
  Collected for Firebase Crashlytics.
- Location (Approximate): now declared as Collected, derived from IP by
  our attribution SDK.
- Data deletion: added https://example.com/delete-account and confirmed
  the in-app path Settings - Account - Delete account.

All user data in transit is encrypted with TLS. Our privacy policy at
https://example.com/privacy lists the same processors and purposes.
Please re-review.

Thank you,
Sam Lee

This article is practical guidance, not legal advice; you alone are responsible for making complete and accurate declarations for your app.

Pair this with Sign in with Apple and account deletion for the token-revocation side, the Google Play account deletion requirement for the deletion URL policy, app SDK privacy policy clauses for per-SDK policy text, the Firebase privacy policy generator guide for Firebase-heavy stacks, and the account deletion page generator for the public request page.

Google Play Data Safety Form: Complete 2026 Walkthrough