google-playprivacycompliance

How to Fill Out the Google Play Data Safety Form (Without Getting Your App Suspended)

The Data safety form is mandatory for every Play app and mismatches with real SDK behavior cause policy strikes. What to declare, the account deletion requirement, and how AdMob changes your answers.

The Google Play Data safety form is mandatory for every app — and the most common enforcement actions are not hacking attempts, they're self-declared forms that don't match what the app's SDKs actually do. Here is what the form requires, what AdMob and analytics SDKs force you to declare, and the account deletion rule that surprises most developers.

Who must fill it out

Everyone. Every app on Google Play — production, closed testing, and open testing — must complete the Data safety section. Apps that collect nothing still complete it and must link a privacy policy. There is no exemption for "simple" apps.

What the form asks

The form is a self-declaration, structured as three questions per data type (location, personal info, identifiers, photos, and so on):

  1. Does your app collect or share this data type?
  2. Is it required, optional, or collected only with user consent? (ephemeral processing is handled here too)
  3. Is it encrypted in transit? Can users request deletion?

Your answers produce the Data safety block users see on your listing — Google renders badges like "No data collected" or "Data is encrypted in transit" from it.

The trap: your SDKs collect more than you think

You must account for what your dependencies collect, not just your own code:

  • AdMob — collects device identifiers and the advertising ID, shares them with Google. Apps with ads almost always must declare "App activity" and "Device or other IDs" as collected/shared.
  • Crash reporting (Sentry, Crashlytics) — collects device identifiers, and Crashlytics can collect location-granularity data (coarse) depending on configuration.
  • Analytics — app interactions, device IDs, diagnostics.

The enforcement pattern Play looks for is a mismatch: an app that integrates a known ad SDK but declares "no data collected." If you're unsure what a specific SDK declares, Google's SDK provider guidance lists data disclosures for major libraries.

The account deletion requirement

If your app allows account creation, the User Data policy requires both:

  1. An in-app way to request account deletion (settings page, support flow, etc.).
  2. A web link where users can request deletion without reinstalling the app.

You declare the web link in the Data safety section, and Play may show a data deletion badge on your listing. The resource can be an HTML page with instructions or a form — it must describe what data is deleted and the process, and it must work.

Every app needs a live privacy policy URL — hosted on an active domain, non-editable PDFs excluded, covering the data declared in the form. If your app ships a landing page or admin panel (as BowlerKit projects do), hosting the policy there keeps it on a domain you control — see the privacy policy guide.

Pre-release checklist

  1. List every SDK in your app (ads, analytics, crash, auth) and its data disclosures.
  2. Map each SDK's collection to the form's data types — collect, share, ephemeral, encrypted.
  3. Verify in-app account deletion + web deletion link work (if you have accounts).
  4. Host the privacy policy on a stable URL and link it in the form.
  5. Revisit the form whenever you add or remove an SDK — Play requires updates when practices change.

Compliance by construction

BowlerKit's Account template ships the account flows, notification preferences, and a privacy policy guide so the declarations you make in Play Console match what your app actually does. See the quick start to generate a project with both profile-gated auth and clean Guest variants.