Google Play Data Safety Form: A Complete Guide

The Data safety form is a questionnaire you must complete for every app you upload to Google Play; in it you declare what data types your app collects, why, and whether that data is shared with third parties. In Play Console, it lives under Policy > App content > Data safety after you select your app.

This form feeds the "Data safety" section users see on your store listing; every item you declare becomes part of a list prospective users see before installing. The form does not replace the separately required privacy policy URL — both must be completed.

You cannot reach production without completing the form; a Data safety section that is left blank or never opened shows up as a blocking warning in the release flow.

The form asks along two separate axes: data collection and data sharing. Google's official definition of collection is transmitting data off the user's device — by your app or an SDK it uses; data that is only processed on the device and never sent anywhere (ephemeral, on-device processing) does not count as collection and doesn't need to be disclosed. Sharing means transferring collected user data to a third party (an ad network, an analytics provider) — no matter what purpose the data was originally collected for, transferring it to a third party counts as sharing. The two are not the same, and the form has you check them separately.

For example, an ad SDK that takes the Advertising ID for ad personalization and sends it to its own servers counts as both collection and sharing: the SDK transmits the data off the device (collection), and that data is processed on the ad network's own servers (sharing). By contrast, data sent only to your own backend (a server you operate directly, not a third party) counts as collection but not sharing, since no third party is involved. Data that never leaves the device at all — kept only in local storage, such as a theme or language preference the app remembers locally — doesn't count as collection in the first place; under Google's official definition, that kind of data doesn't need to be declared in the form at all.

For each data type, the form also asks for the purpose (app functionality, analytics, advertising/marketing, fraud prevention, personalization, and similar), whether it is optional, and whether it is encrypted in transit. Not matching these fields to your SDK's actual behavior is the most common source of flagged inconsistencies.

If you use AdMob, you must declare that the Advertising ID is collected and used for ad personalization; AdMob can also process approximate location and device/app information for ad delivery and fraud prevention. This is a declaration AdMob's own publisher policies require from developers — skipping it causes problems both in Play review and in the AdMob console.

If you use Firebase Analytics, you need to check that app interactions and usage data are collected for analytics purposes. If you use Firebase Crashlytics, you separately need to declare that crash logs, device identifiers, and diagnostics data are collected — folding Crashlytics into the same line as Analytics can count as underdeclaring, since they are separate SDKs and deserve separate lines in the form.

If your app collects its own data independently of any SDK — sign-in email or phone, payment details, location permission — declare those separately as well. Each SDK's own documentation section on data-safety/privacy disclosures is the most reliable reference when filling out the form; these can change between SDK versions.

Your Data safety declarations and your privacy policy text must match each other. Checking 'advertising ID collected' in the form while your policy never mentions AdMob — or the reverse — can be flagged as an inconsistency during review, and in the worst case start a process that leads to app suspension.

The practical approach: first list every SDK you use and what each one collects, then carry that same list into both the Data safety form and your privacy policy at matching detail. Whenever you add a new SDK or permission to the app, updating both documents in the same release removes most of the risk of a later inconsistency.

The most common issue is underdeclaration: the app collects data through an SDK, but the form never reflects it. This usually happens when the form isn't updated after an SDK is integrated, and it can be caught as an inconsistency during Play's automated or manual review.

Second is a privacy policy URL that is blank, unreachable, or contains text that contradicts the form's declarations; this mismatch is a separate rejection reason and can be flagged independently of the Data safety form itself.

Third is not revisiting the form after content changes: adding a new SDK, a new permission (location, say), or a new third-party integration without updating the form leaves the existing declaration out of sync with the app's real behavior. Google can re-evaluate releases against this periodically.