Google Play Data Safety Checklist: Get Your Listing Submission-Ready

Every app on Google Play has to complete the Data safety form, and the answers you give become the public "Data safety" section on your store listing. For a solo developer or a small studio, this form is one of the most common ways a release quietly stalls in review — not because the app is wrong, but because the declarations, the privacy policy link, and the account-deletion route do not all line up.

This checklist breaks the Data safety section into concrete items you can actually tick off before you hit submit. It is written for an indie builder shipping a real app, not for a privacy team. Each item maps to a public signal LaunchTrust can passively detect on your live listing or website, so you can confirm the markers a reviewer looks for are genuinely present before review does.

What the Data safety section actually covers

Google's Data safety policy asks you to disclose, in plain terms, how your app handles user data. The form is built around a few core questions:

• What data your app collects — identifiers, location, contacts, photos, financial info, app activity, and so on.
• What data your app shares — anything sent off the device to a third party, including ad networks, analytics, crash reporters, and backend providers.
• How that data is handled — whether it is encrypted in transit, and whether users can request deletion.
• Whether collection is required or optional, and the purpose of each data type.

Crucially, your declarations must cover data sent by any third-party SDK you bundle, not just the code you wrote yourself. An analytics or ads SDK that phones home is your responsibility to declare. The published answers, your privacy policy, and your app's actual behavior all need to tell the same story — mismatches are a leading cause of rejections and post-launch enforcement.

The Google Play Data safety checklist

Work through these before you submit. Each is phrased as something you can confirm, and where a public signal exists, the linked detector tells you whether that signal is present on your surface.

• You have completed every section of the Data safety form in the Play Console — data collected, data shared, security practices, and deletion options — and submitted it.
• Your declarations include all third-party SDKs. Audit your dependencies; if an ads, analytics, or crash SDK sends data off-device, it must be reflected in the form.
• A reachable privacy policy URL is set in the Play Console and resolves with no 404 or redirect loop. → maps to privacy policy
• The privacy policy matches the form. Every data type and sharing practice you declared should be described in the policy too — the two must not contradict each other.
• The public listing shows both a privacy policy link and a Data safety section once published. → maps to Google Play Data safety
• If your app supports account creation, it offers an account-deletion route — and a web-reachable deletion path, not only an in-app button. → maps to account & data deletion
• The deletion route is discoverable on a public URL, since Google's Data deletion policy expects a path users can reach without installing the app.
• "Data is encrypted in transit" is answered truthfully — confirm your app and APIs actually use HTTPS everywhere before you claim it.
• Data collection purposes are accurate, and anything marked "optional" really is optional in the app.
• You've cross-checked overlapping rules — GDPR's transparency and erasure expectations apply to the same data if you have EU users. → see the GDPR checklist for indie apps, and mirror the same care on iOS via App Store privacy

Ticking the privacy-policy, listing, and deletion items covers the parts of the Data safety section most likely to be checked first for a typical indie app.

What LaunchTrust checks for this framework

LaunchTrust does not assess "Data safety readiness" as a verdict — no scanner can read your form answers or judge whether they are accurate. What it does is surface the observable signals a reviewer would look for, by fetching your public pages and inspecting the HTML an anonymous visitor receives:

• The play_listing detector fetches your live listing by package id and reports detected when both a "privacy policy" reference and a "data safety" section appear in the markup. Because Play listings are heavily localized and JavaScript-rendered, it returns unable to determine rather than a false "missing" — a prompt to confirm in a browser, not an alarm.
• The privacy_policy detector reports whether a privacy-policy link or recognizable wording is present on the page you point it at.
• The data_deletion detector reports detected when it finds a deletion-oriented link or deletion wording (e.g. "delete your account", "data deletion"), not detected when neither is present, and unable when the page can't be fetched.

Each result is a signal, not a judgment. "Detected" means the marker is on the page; it does not confirm the form is complete, the policy is sufficient, or the deletion flow actually purges data on your backend.

A concrete example

When the listing detector reads a healthy public page, both phrases appear in the markup, roughly like this:

<!-- public Play listing markup (simplified) -->
<a href="https://yourapp.example/privacy">Privacy Policy</a>
...
<section aria-label="Data safety">Data safety</section>

With both "privacy policy" and "data safety" present, the result is detected. A new or mistyped-package listing, or one where the section only paints in after JavaScript runs, returns unable to determine — verify it in a browser and in the Play Console rather than treating it as a gap.

How to address it

1. Complete and submit the Data safety form in the Play Console, answering every section based on what your app — and its SDKs — actually do.
2. Set a reachable privacy policy URL that resolves cleanly and describes the same data practices you declared on the form.
3. Add an account-deletion route if you support accounts, and expose a deletion path on a public web URL, not only inside the app.
4. Confirm data is encrypted in transit by checking your app and APIs use HTTPS before you answer "yes" to that question.
5. Publish or update the listing, then open it in a normal browser to confirm the Data safety section and policy link both appear.
6. Re-scan and confirm the signals flip to detected, and treat any unable to determine result as "verify manually," not as evidence of a problem.

Check this in 30 seconds

Run your app and website through the free LaunchTrust scanner. It fetches your live Play listing by package id and your public page, then reports whether the privacy-policy reference, Data safety section, and account-deletion route are showing up — so you can spot a missing signal or a wrong package id before review does. No signup, no crawl of private pages: it reads the same public HTML your users and reviewers see.

FAQ

Does completing this checklist mean my app meets Google Play's requirements? No — it surfaces signals, not a verdict. The checklist helps you confirm the markers a reviewer expects are present, but LaunchTrust cannot read your form answers, verify they are accurate, or confirm your data practices satisfy Google's policies or any law. It is a compliance aid, not legal advice or certification. For your specific situation, consult a qualified professional.

Do I have to declare data collected by third-party SDKs? Yes. Google's Data safety policy holds you responsible for data your app sends off the device, including via ads, analytics, and crash-reporting SDKs. Audit your dependencies and reflect their behavior in the form, even if you did not write that code yourself.

Does my app need an account-deletion option for the Data safety form? If your app supports account creation, Google's Data deletion policy generally expects you to offer account deletion — and a deletion path users can reach via a public web URL, not only inside the app. The account & data deletion check reports whether that route is referenced on the page you scan.

My listing scan says "unable to determine" — is something wrong? Not necessarily. Play listings are localized and JavaScript-rendered, so a single server-side read can miss text a browser would show. The detector returns "unable to determine" instead of a false "missing" — confirm the section and policy link in a browser and that the form is submitted in the Play Console.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.