Google Play

Google Play Data Safety Form: The Complete Walkthrough for 2026

A section-by-section walkthrough of the Google Play Data Safety form — the 14 data categories, collection practices, sharing, security, and how to answer so your form matches your privacy policy.

9 min read

Google Play Data Safety Form: The Complete Walkthrough for 2026

Your Android build is ready and Play Console blocks submission until you complete the Data Safety form. The form asks you to declare, for fourteen data categories, what your app collects, what it shares, why, how it is secured, and whether users can request deletion. Leave a gap and you cannot submit. Answer differently than your privacy policy and Google may flag it during review. Answer differently than what your binary actually does and you risk enforcement action.

This guide walks through the form section by section, quotes Google's own guidance, and shows how to keep your answers consistent across the form, your privacy policy, and your account deletion page.

TL;DR

  • The Data Safety form is mandatory for every Google Play submission. Incomplete forms block updates, and inconsistent answers trigger review flags.
  • Google defines 14 data categories and expects per-category answers: collected, shared, purposes, optional, encrypted in transit, deletable.
  • Third-party SDKs count as your data collection. Firebase, AdMob, Crashlytics, Sentry, and every other SDK you link must be reflected in the form.
  • A working account deletion URL is part of the same compliance bundle — see our Google Play account deletion URL guide.
  • AppLander's mobile-first privacy questionnaire asks the same questions as the form in the same taxonomy, so whatever you answer in the dashboard maps directly to Play Console fields.

Table of Contents

What the Data Safety Form Actually Is

The Data Safety form is the structured disclosure that powers the "Data safety" section on every Google Play store listing. Developers fill it in through Play Console, under App content → Data safety, and the answers drive the user-facing summary that appears next to screenshots and reviews. Google's position on accuracy is direct: "you alone are responsible for making complete and accurate declarations in your app's Play store listing. Only you possess all the information required to complete the Data safety form."

The form covers five broad question groups for every data type your app touches:

  1. Is this data collected, shared, or both?
  2. Why is it collected or shared? (data use purposes)
  3. Is collection optional for the user?
  4. Is the data encrypted in transit?
  5. Can users request deletion?

Google's guidance to developers on developer.android.com lists concrete indicators — permissions, APIs, and UI patterns — that suggest each category applies. If your binary uses ACCESS_FINE_LOCATION, RECORD_AUDIO, READ_CONTACTS, the Google Play Billing Library, or the Advertising ID, the corresponding category is almost certainly in scope and you must disclose it.

The 14 Data Categories

Google's form groups data into 14 top-level categories. Below is the canonical list with the common Android indicators that put a category in scope.

  1. Location — approximate (≥3 sq km) or precise (<3 sq km). Indicators: ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION.
  2. Personal info — name, email, user IDs, address, phone, race, political or religious beliefs, sexual orientation, date of birth, gender. Indicators: BIND_AUTOFILL_SERVICE, GET_ACCOUNTS, READ_CALL_LOG.
  3. Financial info — payment info, purchase history, credit score, salary. Indicators: Google Play Billing Library, Google Pay, Autofill.
  4. Health and fitness — medical records, symptoms, exercise. Indicators: ACTIVITY_RECOGNITION, BODY_SENSORS, Health Connect, Google Fit.
  5. Messages — emails, SMS/MMS, chat. Indicators: READ_SMS, RECEIVE_SMS, SEND_SMS.
  6. Photos or videos — photo picker, READ_MEDIA_IMAGES, READ_MEDIA_VIDEO.
  7. Audio files — voice or sound recordings, music. Indicators: RECORD_AUDIO.
  8. Files and docs — READ_EXTERNAL_STORAGE, MANAGE_EXTERNAL_STORAGE.
  9. Calendar — READ_CALENDAR, WRITE_CALENDAR.
  10. Contacts — READ_CONTACTS, WRITE_CONTACTS.
  11. App activity — interactions, in-app search, installed apps, UGC. Indicators: AccessibilityService, QUERY_ALL_PACKAGES.
  12. Web browsing — default browser requests, browsing cache. Indicators: WebView usage.
  13. App info and performance — crash logs, diagnostics. Indicators: ActivityManager, ApplicationErrorReport.
  14. Device or other IDs — IMEI, MAC address, Firebase installation ID, Advertising ID. Indicators: AD_ID, AdvertisingIdClient.

Walk the list once per release. If any indicator applies to your binary or any SDK you link, that category belongs in the form.

Collection and Sharing Practices

For every sub-type in scope, Google asks whether the data is collected (your servers or SDKs receive it) and whether it is shared (it leaves your systems for a third party that is not a service provider acting on your behalf). A service provider processing data on your behalf under contract is usually not "sharing," but a third-party analytics vendor that uses the data for its own purposes usually is.

Two important qualifiers per category:

  • Processed ephemerally: data used in memory or within the session and never sent off the device. If true, you may be exempt from declaring collection for that type.
  • Required vs optional: is collection required, or can the user turn it off and still use the feature? Optional collection is viewed more favorably.

If you collect and share a category, declare it in both columns. If the data never leaves the device, you may be able to declare ephemeral-only, subject to Google's guidance.

Data Use Purposes

For every category collected or shared, Google asks which of the following purposes apply. Pick every purpose that applies — one category can serve several:

  • App functionality — the feature requires the data to work (for example, location for a maps app).
  • Analytics — measuring audience, usage, or performance.
  • Developer communications — sending newsletters, product updates, or transactional email.
  • Advertising or marketing — targeting, measurement, attribution.
  • Fraud prevention, security, and compliance — detecting abuse, legal obligations.
  • Personalization — customizing content, recommendations, or experience.
  • Account management — creating and maintaining user accounts.

The user-facing summary groups these purposes, so being specific here improves trust with cautious users and reduces reviewer friction later.

Security Practices and Encryption in Transit

Google's form asks two security questions for every disclosed category:

  • Is the data encrypted in transit? For data flowing between the device and your backend or SDK endpoints, the expected answer is yes if you use HTTPS (which you should for every network call). If even one endpoint is HTTP, the honest answer is no — and that answer will be reflected in the user-facing summary.
  • Can users request that their data be deleted? This is independent of in-app account deletion and Google Play's deletion URL requirement. It asks whether there is a user-initiated path to erase the data from your systems.

Google also asks whether your app has committed to its security practices under an independent audit framework (for example, Mobile App Security Assessment, MASA). If you have not been audited, answer no — do not invent one.

Data Deletion and the Account Deletion URL

Deletion has two intertwined parts on the Data Safety form. First, the per-category question above — can a user request that this specific category of data be deleted? Second, a global declaration: does your app provide a public web URL where users can request account and data deletion, even if they have uninstalled the app? The URL requirement applies to every app that supports account creation and is enforced independently of the rest of the form.

The deletion URL must be publicly accessible without login, HTTPS, and must link directly to the deletion page — not a homepage with a buried link. It also has to describe what gets deleted, what is retained and why, and how long processing takes. A Google Form is often rejected because some configurations require a Google sign-in to submit. Use a purpose-built page instead.

Our Google Play account deletion URL guide covers the page requirements and the three ways to build one. The important thing for the Data Safety form is that the URL you enter in the deletion section must be the same one you reference in your privacy policy, and the disclosures on the page must match the answers on the form.

Third-Party SDKs Are Your Disclosure

The single most common Data Safety form mistake is forgetting that third-party SDKs count. Google is explicit: "If a third-party SDK or library in your app collects or shares user data, you must reflect this collection and sharing in the Data safety form." That includes every analytics, crash reporting, advertising, attribution, monetization, push notification, and backend-as-a-service SDK your app links against.

Common examples of what each SDK adds to your form:

  • Firebase Analytics — analytics, device IDs, app interactions, crash logs.
  • Crashlytics, Sentry, Bugsnag — crash logs, diagnostics, device IDs.
  • AdMob, AppLovin, Unity Ads, ironSource — advertising ID, device info, shared with ad networks.
  • RevenueCat, Adapty — purchase history, user IDs, shared for subscription management.
  • OneSignal, Braze — device tokens, user IDs, shared for communications and marketing.
  • Branch, AppsFlyer, Adjust — device identifiers, app interactions, shared for attribution.
  • Stripe, Paddle — payment info (most is handled by the vendor, but metadata flows through).

For each SDK, read the vendor's Data Safety mapping (most major SDKs publish one) and reflect those answers on your form. If a vendor does not publish a mapping, err on the side of disclosing more.

Cross-Checking the Form Against Your Privacy Policy

After you finish the form, Google reviewers cross-check three documents against each other:

  1. The Data Safety form itself.
  2. Your privacy policy, linked from the form and from your app's Play store listing.
  3. Your app's actual behavior, verified through binary scanning and runtime observation.

A discrepancy between any two is a review flag — and the most common rejections are caused by privacy policies that do not list the same data categories the form declares. If the form says "device IDs are collected for analytics and advertising" but the policy does not mention advertising IDs at all, the form is fine on its own but the combination is not.

The cleanest way to avoid drift is to generate all three artifacts from a single source. That is exactly what AppLander's mobile-first privacy questionnaire does. It asks the same questions as the Data Safety form, in the same taxonomy — device IDs, location, camera, contacts, health, financial, user content, web browsing — and produces a privacy policy, a Data Safety mapping you can paste into Play Console, an account deletion page, and a support center that all reference the same underlying answers. You answer the questions once; everything stays in sync. See our privacy policy generators for mobile apps comparison for where that editor sits alongside the rest of the market.

AppLander also tracks which SDKs are enabled per app from a curated library of 100+ mobile services and prompts you when a change requires a new Data Safety answer — so you never forget to update the form when you add a new analytics SDK next sprint.

Honest limitations. AppLander is newer than mainstream compliance tools and is not a law firm. Jurisdictions outside the MVP set (LGPD, PIPL, APPI, KVKK, Australian APPs, expanding US state laws) are on the roadmap. If you only need the Data Safety form and nothing else, complete it directly in Play Console — AppLander earns its keep when the privacy policy, deletion page, and support center also need to stay in sync.

Frequently Asked Questions

Do I have to fill in the Data Safety form if my app collects nothing?

Yes. You still declare "no data collected" — there is no way to skip the section. Google asks you to confirm the declaration applies to your app and any SDKs you link.

What if a third-party SDK collects data but I never see it?

You still have to disclose it. Google's guidance is explicit that third-party SDK data collection counts as yours. Read the SDK vendor's Data Safety mapping and include those categories on your form.

Can I get away with "we do not share data" if our SDKs share on our behalf?

No. If an SDK shares user data with its parent for the parent's own purposes (typical for ad networks and attribution vendors), that is "sharing," not "collection by a service provider." Mis-declaring this is one of the most common causes of enforcement action.

How does the form relate to the account deletion URL?

The deletion URL is a required field on the form for any app that supports account creation. It must work, describe what gets deleted, and match your privacy policy. See our account deletion URL guide.

Does the form update when I change my app?

Not automatically. You update it manually in Play Console when your data practices change — new SDK, new permission, new feature. Google reviews the updated form before publishing.

Is the Data Safety form the same as Apple's App Privacy Details?

They serve the same purpose but use different taxonomies and live in different consoles. You fill both in separately; the safest move is to keep one internal inventory you can answer both forms from.

What happens if my form does not match my privacy policy?

Google flags it during review. In mild cases you fix the inconsistency; in repeat cases the update is rejected or the listing is temporarily removed.

Conclusion

The Data Safety form is a structured contract with Google Play that covers every data type your app touches — yours and every SDK's. Filling it in honestly is table stakes. Keeping it in sync with your privacy policy, your deletion page, and your actual binary behavior is the harder, ongoing job — and the one that gets apps rejected when it drifts.

If you only need to answer the form once for a simple app, Google's own guidance is enough and you can complete it directly in Play Console. If you want one source of truth that keeps the form, the privacy policy, the deletion page, and the support center consistent as your app evolves, try AppLander and answer the questions once, in one place.

Sources

Ship your app faster with AppLander

The all-in-one compliance and landing-page platform for mobile app developers.

Start Free