Data Safety Helper

Prepare Google Play’s Data safety form — collection, sharing, and security practices — without guessing.

Compliance & Publishing Tools100% freeNo sign-up required

0 of 18 complete

Progress is saved in your browser.

Data Inventory

List every data type your own code collectsWalk Google’s taxonomy category by category: location, personal info, financial info, health, messages, photos/videos, audio, files, calendar, contacts, app activity, browsing, app info/performance, device IDs.List every data type each third-party SDK collectsSDK collection counts as YOUR collection. Check each vendor’s published Play data-safety guidance â Firebase, AdMob, Facebook, and most major SDKs publish exact disclosure tables.Classify each type as collected, shared, or both"Shared" means transferred to a third party — including SDKs sending data to their own servers for their own purposes. Service providers processing only on your behalf generally do not count as sharing.Check the ephemeral processing exception where it appliesData processed only in memory and never stored can be declared as ephemeral, which softens the disclosure.Note which collection is optional vs. required for each typeThe form asks per data type whether users can use the app without providing it.

Purposes & Sharing

Assign at least one purpose to every collected data typeGoogle’s fixed purpose list: app functionality, analytics, developer communications, advertising or marketing, fraud prevention/security/compliance, personalization, and account management.Verify advertising purposes are declared if any ad SDK is presentAn integrated ad SDK almost always means device IDs are collected and shared for advertising — omitting this is the most common enforcement trigger.Confirm whether any data is used for third-party advertising specificallyCross-check declared purposes against your privacy policyThe Data Safety form and your privacy policy must tell the same story; reviewers compare them.

Security & Deletion

Confirm all data in transit is encrypted (TLS) before claiming itOnly claim "data is encrypted in transit" if every network call — including SDK traffic — uses TLS; cleartext HTTP anywhere invalidates the claim.Provide a working data-deletion request mechanismSince 2024, apps that allow account creation must offer both in-app account deletion and a web link, declared in the form.Verify the deletion mechanism actually deletes server-side dataDecide whether to declare an independent security review (MASA)The optional independent-review badge requires a paid assessment against the OWASP MASVS standard.

Validation & Maintenance

Run a network traffic capture to verify your declarationsProxy the app through Charles or mitmproxy and confirm no undeclared data types leave the device — this is essentially what enforcement does.Preview the generated Data Safety listing before publishingPlay Console shows exactly what users will see; review it as a user would.Establish a process to update the form when adding SDKs or featuresThe form must stay accurate continuously, not just at initial submission; add it to your release checklist.Align the form with your iOS privacy nutrition labelsThe taxonomies differ, but materially different declarations across stores for the same app are a red flag.Keep evidence of your SDK research and traffic auditsIf Google questions a declaration, dated documentation of your due diligence matters.

Google Play’s Data safety section is mandatory: every app must have an approved Data safety form in the Play Console before updates can be published, and the answers appear on your store listing where users compare them against competitors. The form asks, per data type, whether you collect it, whether you share it with third parties, whether collection is optional, and why — plus overall security questions on encryption in transit and whether users can request deletion.

This helper walks Google’s exact data taxonomy — location, personal info, financial info, messages, photos and videos, app activity, device identifiers, and more — and asks the questions in the order the form does, with the definitions that trip developers up spelled out. The result is a completed worksheet you can transcribe into the Play Console in one sitting instead of guessing category by category.

How to fill in the Data safety form correctly

1
Build a data inventory first: list every data type your app code and every SDK collects or transmits — Google’s definition of “collect” covers data sent off the device, even if you never store it.
2
Check each SDK vendor’s published Data safety guidance; major SDKs document exactly which form answers their libraries require.
3
For each data type, answer collection, sharing, optionality, and purpose using the worksheet, noting that ephemeral processing and some on-device handling have specific carve-outs.
4
Answer the security questions honestly — encryption in transit, and whether you offer a way to request data deletion.
5
Transcribe the worksheet into Play Console under App content → Data safety, and update it in the same release as any new SDK or data flow.

How Google defines collection and sharing

“Collection” in the Data safety form means transmitting data off the user’s device — to your servers, your analytics vendor, anywhere. Data processed only on-device and never transmitted does not count, and data sent off-device but processed ephemerally (used only in memory to serve the request and retained no longer than necessary) can also be exempt from disclosure. This is stricter than intuition suggests: a debug log shipped to a crash service “collects” whatever it contains.

“Sharing” means transferring data to a third party — including through SDKs that send data directly from the device to their own servers. There are carve-outs: transfers to service providers processing on your behalf, transfers required by law, and user-initiated transfers (like the user sharing content to another app) do not have to be declared as sharing. Getting the collect/share distinction right matters because the store listing displays them as separate, user-visible claims.

Why SDKs are where Data safety forms go wrong

You are answerable for your whole APK: Google holds developers responsible for declaring the data practices of every library they embed. An ad SDK collecting device identifiers, an analytics kit logging app interactions, a crash reporter capturing logs — each maps to specific form answers regardless of whether your own code touches that data. Most major vendors (Google’s own SDKs included) publish exact Data safety disclosures, and Google’s SDK Index surfaces this information; auditing dependencies against those documents is the single highest-value step in filling the form accurately.

Misdeclarations have real consequences: Google compares declared practices against observed app behavior, and mismatches lead to rejected updates, enforcement warnings, and ultimately removal. The most common real-world failure is drift — the form was accurate at first submission, then someone added an SDK and nobody revisited the declaration. Make “Data safety form still accurate?” a standing item in your release checklist, alongside the iOS privacy label if you ship both platforms.

Frequently asked questions

Is the Data safety form mandatory for all Google Play apps?

Yes. Since July 2022, all apps must have a completed and approved Data safety form; without one you cannot publish updates, and non-compliant apps face removal. Even an app that collects nothing must submit the form stating so.

Does data processed only on the device need to be declared?

Generally no — Google’s “collection” means transmission off the device. On-device-only processing is exempt, and off-device data handled ephemerally (in memory, only to serve the immediate request) also has a disclosure exemption. Anything stored on your servers or a vendor’s must be declared.

Do I have to declare data collected by third-party SDKs?

Yes — you are responsible for your entire app, including embedded libraries. Check each SDK’s published Data safety documentation and merge their required answers into your form; “the SDK collects it, not us” is not a distinction the form recognizes.

What counts as “sharing” in the Data safety form?

Transferring user data to a third party, including SDKs sending data from the device to their own servers. Exemptions exist for service providers acting on your instructions, legal obligations, anonymized data, and user-initiated transfers — those do not need to be declared as sharing.

What happens if my Data safety answers are wrong?

Google treats misrepresenting data practices as a policy violation; consequences range from being required to fix the form, to rejected updates, to enforcement action against the app. If you find an error, correct the form in Play Console promptly — form updates do not require a new APK.

How does the form differ from Apple’s privacy nutrition label?

They cover similar ground with different definitions. Google asks explicitly about encryption in transit and deletion requests, treats optional versus required collection as a formal answer, and has an ephemeral-processing exemption; Apple’s label instead centers on tracking and whether data is linked to identity. Answering one does not answer the other — prepare them separately.

One privacy source of truth for both stores

Appalize’s app privacy setup checklist keeps your Play Data safety answers, iOS privacy labels, and policy URLs consistent per app — and flags drift when your stack changes.

Sync my privacy setup free

Related free tools

Privacy Nutrition Label Helper

Work out your App Store privacy label — tracking, linked, and not-linked data — before you fill in App Store Connect.

Generate a store-ready privacy policy for your iOS or Android app in minutes.

GDPR & COPPA Checker

Check your app against the GDPR and COPPA requirements that apply to mobile developers.

Draft clear terms of service for your mobile app covering accounts, purchases, and acceptable use.