Google Play Data Safety Form: Evidence-Based Guide

What Is the Data Safety Form?

The Data safety declaration in Play Console tells users what data the released app collects or shares and describes selected security practices. It must reflect actual app, backend, and third-party behavior; a permission list alone is not a data-flow inventory.

The published store section is based on the developer's answers. Treat the declaration as a controlled release artifact, with an owner, evidence, and a review whenever code, SDKs, backend flows, or account features change.

When Is It Required?

Requirement and exemption details depend on publication state. Google's current guidance documents an exemption for apps active only on the internal testing track; do not generalize that exemption once the app moves to another track or publication state.

• Check the Data safety status and required actions shown for the app
• Complete the declaration before moving beyond an exempt internal-only state
• Review the answers when an app update changes data behavior
• If no data is collected or shared, verify that claim against code, backend requests, and every included SDK

Inaccurate declarations can lead to review questions or policy enforcement. Use the status and correction route supplied by Google for the specific app.

Data Types You May Need to Declare

Google's current form groups data into categories such as the following. Use the definitions and subtypes in the live form rather than inferring an answer from the label alone:

• Location — Approximate or precise location data
• Personal info — Name, email, user IDs, address, phone number
• Financial info — Payment info, purchase history, credit score
• Health and fitness — Health data, exercise data, sleep data
• Messages — Emails, SMS/MMS, other in-app messages
• Photos and videos — Photos, videos taken or stored
• Audio files — Voice recordings, music files, other audio
• Files and docs — Files stored or created
• Calendar — Calendar events
• Contacts — Contact list data
• App activity — Page views, taps, search history, installed apps
• Web browsing — URLs visited within the app
• App info and performance — Crash logs, diagnostics, performance data
• Device or other IDs — Device ID, advertising ID, Android ID

Step-by-Step Guide

Step 1: Audit Your App's Data Collection

Before filling out the form, create a complete inventory of all data your app collects. Include data collected by your own code and by all third-party SDKs. For each data type, note whether it is collected, shared with third parties, and whether users can request deletion.

Step 2: Open the Data Safety Form

Open the app in Play Console and find the current Data safety task under the policy or app-content workflow. Console labels can move, so use search or the setup checklist if that path is not visible.

Step 3: Answer the Initial Questions

Answer the current opening questions from the released app and SDK inventory. Console wording can change, so do not rely on a fixed question count or an older screenshot; preserve the form version and the evidence used for each answer.

Step 4: Declare Each Data Type

For each data type you collect, specify: Is it collected? Is it shared? Is it processed ephemerally? Can users request deletion? What is the purpose (app functionality, analytics, advertising, etc.)?

Step 5: Security Practices

Answer the security, deletion, and applicable Families questions from the implemented behavior and current policy definitions. Do not infer encryption in transit from one HTTPS endpoint while another app or SDK flow remains unverified.

Step 6: Review and Submit

Google shows a preview of how your Data Safety section will appear on the Play Store. Review it carefully before submitting.

Third-Party SDK Evidence Matrix

Build one row for every production dependency. Vendor documentation is a starting point; configuration and observed network behavior determine the app-specific answer.

Declaration Checks Before Submission

• Omitting SDK behavior — The declaration covers data handled through included SDKs as well as first-party code
• Unsupported "no data" answer — Confirm the claim against the release build, backend, diagnostics, push, authentication, payments, ads, and other enabled services
• Not updating after SDK changes — Adding or updating an SDK may change your data collection
• Inconsistency with privacy policy — Your Data Safety declarations must align with your privacy policy
• Assuming encryption coverage — Verify each relevant first-party and third-party transfer before answering

Privacy Policy Requirements

The privacy policy, in-app disclosures, consent surfaces, deletion flow, and Data safety declaration should describe the same implemented data lifecycle. Check the current User Data policy for the app's applicable requirements.

• Keep the policy URL publicly reachable for users and reviewers
• Identify the app or developer and the data covered by the policy
• Explain collection, use, sharing, security, retention, and user-control practices that actually apply
• Provide the contact and deletion information required for the app's data flows
• Update the policy and declaration together when implementation changes

Frequently Asked Questions

What happens if I fill it out incorrectly?

Google may block a release or take another policy action. Use the notice and Policy status record to identify the exact mismatch and available correction or appeal route.

Do I need to fill it out for internal testing?

Check the current Data Safety requirement for the app's track and publication state. Google documents an exemption for apps active only on internal testing, while apps moving beyond that state need the applicable declaration completed.

Can I say my app collects no data?

Yes, if the released app, backend, and every enabled SDK satisfy Google's current definition of no collection and no sharing. Preserve the dependency and runtime evidence used for that answer.