The Data safety form in Play Console looks like a checklist, but the hard questions are rarely about your own code. They are about the SDKs you added: Firebase Analytics, Crashlytics, AdMob, sign-in, billing. Google counts whatever those libraries send off the device as your app's collection, and you answer for it.
This guide covers the parts that trip up indie developers, with every rule linked to Google's own documentation, because the form changes and so do the SDKs.
SDK vendor pages tell you what their code collects. They do not fill out your form. Every one of them says you alone are responsible for your answers, so confirm each row against your own dependencies and configuration.
What does the Google Play Data safety section ask for?
The Data safety form asks whether your app collects or shares any user data types, whether all of it is encrypted in transit, and whether users can request deletion. For each data type you select, you declare whether it is collected, shared or both, whether it is optional, and why you use it.
You fill it out under App content in Play Console. According to Google's Data safety help article, every app on closed, open or production tracks must complete it, including apps that collect nothing. Apps only on internal testing are exempt. You need a privacy policy link to submit.
The 14 categories are Location, Personal info, Financial info, Health and fitness, Messages, Photos and videos, Audio files, Files and docs, Calendar, Contacts, App activity, Web browsing, App info and performance, and Device or other IDs. The purposes are App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security, and compliance, Personalization, and Account management.
There is one form per package name, covering every version currently distributed on Google Play. If any live version collects something, the form must say so. You can also export your answers to CSV and import them back.
What is the difference between collected and shared?
Collected means data is transmitted off the user's device by your app, including by any SDK inside it, wherever it goes. Shared means data is transferred to a third party. Sending data to a service provider that processes it only on your behalf and on your instructions is collection, not sharing.
Google lists four transfers that are not sharing: to a service provider, for legal purposes, initiated by the user in a way they reasonably expect (or after prominent in-app disclosure and consent), and of fully anonymized data. Its FAQ draws the line clearly: an analytics provider processing your data solely on your behalf typically qualifies as a service provider, but an SDK that builds advertising profiles across multiple customers does not, and that is sharing.
Data your app only processes on the device does not need declaring. Neither does a permission you hold but never use to collect anything: Google's FAQ says you only declare data that is actually collected or shared.
How do I declare Firebase Analytics, Crashlytics and AdMob in the Data safety form?
Start from each vendor's Data safety disclosure page, list what it says the SDK collects automatically, then map each item to Google's data type definitions. Firebase says it only passes data to subprocessors or where you instruct it. AdMob says its SDK collects and shares data for advertising, analytics and fraud prevention.
The table is built only from Firebase's Play data disclosure page, Google Analytics' Android disclosure, AdMob's Play data disclosure page, and the type definitions in Google's Data safety article, as published in October 2026. Treat the last column as types to evaluate, then confirm against your own config.
| SDK | What the vendor says it collects automatically | Data safety types to evaluate |
|---|---|---|
| Google Analytics for Firebase | App-instance ID, advertising ID, coarse location from masked IP, in-app purchase events (product ID, name, price), screen views and sessions | Device or other IDs; Approximate location; Purchase history; App interactions |
| Firebase Crashlytics | Stack traces, app state and device metadata at crash time, a Crashlytics installation UUID | Crash logs; Device or other IDs |
| Firebase Performance Monitoring | App start time, network latency, CPU and memory use, device metadata, IP address mapped to country | Diagnostics; Approximate location |
| Firebase Authentication | IP address for abuse prevention; depending on sign-in method, email, display name, phone number, provider details; a Firebase user ID | Email address; Name; Phone number; User IDs |
| Google Mobile Ads SDK (AdMob) | IP address (may estimate general location), interactions such as launches, taps and video views, diagnostics such as hang rate, advertising ID and app set ID. Collected and shared. | Approximate location; App interactions; Diagnostics; Device or other IDs |
Notes that change answers in practice:
- Transitive SDKs count. Crashlytics pulls in the Firebase installations and sessions SDKs. Google's definition of Device or other IDs names the Firebase installation ID as an example.
- Firebase Analytics collects the advertising ID even without AdMob, unless you change its data collection settings.
- The ad ID permission can arrive by itself. Google's advertising ID article says the Mobile Ads SDK declares
com.google.android.gms.permission.AD_ID, which merges into your manifest by default. Check the Merged Manifest tab in Android Studio (see Android's manifest merging guide). - Linking changes sharing. Firebase transfers data to third parties "in accordance with your instructions", such as when you link it to other services. Revisit sharing if you link Analytics to ad products.
For other SDKs, Google points to the Google Play SDK Index, where many vendors link their guidance.
How do I declare Google Sign-In and Play Billing?
For sign-in, declare the account data your app receives and stores, such as name, email address and an account ID, usually for Account management and App functionality. For Play Billing, you do not declare card details Google collects directly, but you may need Purchase history if your app or analytics records purchases.
I could not find a dedicated Data safety page for Sign in with Google, so work from what reaches you. Through Firebase Authentication, Firebase's page lists the email, display name and provider details it can collect. Google defines User IDs as identifiers relating to an identifiable person, such as an account ID.
For payments, Google's FAQ says that with Google Play's billing system you need not declare payment data such as a card number, as long as your app never accesses it and the service collects it directly under its own terms. It also tells you to consider purchase history. Firebase Analytics' automatic in-app purchase events are exactly that.
What counts as App activity and App info and performance?
App activity covers what users do in your app: App interactions such as pages visited and taps, In-app search history, Installed apps, Other user-generated content, and Other actions. App info and performance covers technical data: Crash logs, Diagnostics such as loading time, latency and battery, and Other app performance data.
Analytics events, screen views and the taps AdMob records belong under App interactions. Notes or open-ended text users type that you sync to a server is Other user-generated content. Crashlytics is Crash logs. Performance Monitoring, and part of what AdMob collects, is Diagnostics.
Pseudonymous data still counts. Google's FAQ says diagnostics collected with a device identifier must still be declared as Diagnostics, with the identifier under Device or other IDs.
When is data optional, and what counts as ephemeral processing?
Data is optional only if every user, in every region and on every device, can use the app without it or can opt in or out. If your primary functionality needs it, mark it required. Ephemeral data is used only in memory for a real-time request and not stored. You still enter it, but it is not shown.
Google's example of optional data is information collected only at sign-in, where people can use the app without signing in. If any version of your app requires the data, declare it required.
Google's ephemeral example is a weather app that sends location to fetch the current weather and does not store it afterwards. Anything used to build advertising or user profiles cannot be ephemeral, and if you log a request and use it later, declare that use.
Location inferred from an IP address must be declared under Approximate location. Analytics, Performance Monitoring and AdMob all say they use IP addresses to estimate location.
What does "encrypted in transit" require?
You can only answer yes if all user data your app collects and sends off the device, including through every SDK, is encrypted in transit. Google points to TLS and HTTPS as common protocols. One plain HTTP request carrying user data, from your code or a library, makes the answer no.
The "all" comes from Google's guidance to SDK vendors. Firebase says it encrypts collected data in transit using HTTPS, and Google Analytics and AdMob both say they use TLS. Your own backend and any other API you call are on you.
Do I need a data deletion URL?
Yes, if users can create an account from within your app. Google's account deletion requirement says you must offer an in-app path to delete the account and its data, and a web link where users can request deletion without reinstalling. You enter that link in the Data deletion questions of the Data safety form.
The details in Google's account deletion article are where forms fail:
- Account creation counts even if most of the app works without one, and Google's definition of an app account includes single sign-on.
- The page must load without errors, feature deletion prominently, and name the app or developer as on your store listing. A privacy policy works only if its deletion section is prominent, for example via an anchor link.
- Users must be able to request deletion there, by link, form or support email. If they must cancel a subscription first, say so.
- Google's User Data policy says temporary deactivation or freezing is not deletion. You may keep data for security, fraud prevention or regulatory compliance, but must disclose it.
The deletion badge is looser: Google lets you claim it if you offer any discoverable way to request deletion, such as an email alias, or automatically delete or anonymize collected data within 90 days.
Worked example: mapping IOn Sleep's privacy policy to the form
The fastest way to fill out the form is to start from a privacy policy that lists every data flow, then map each row to a data type. Here is that exercise using the published IOn Sleep privacy policy. It shows the method, not a copy of the store listing.
- Sleep sessions, alarms and settings stay on the phone. On-device processing, nothing to declare.
- Optional Google sign-in stores name, email, profile photo link and a Firebase user ID: Name, Email address and User IDs. Guests can use the app without signing in, which matches Google's example of optional data.
- AdMob for free users receives the advertising ID, IP address, device information and ad interactions. Per AdMob's page, shared data for advertising.
- Crashlytics gets stack traces, device details and an installation ID: Crash logs and Device or other IDs.
- Analytics gets events such as app opens, sounds played and purchase attempts, with an app instance ID and the advertising ID: App interactions, Device or other IDs, and Purchase history to evaluate.
- Payments go through Google Play and the app never receives card details, matching the billing exception.
- A ZIP code, never GPS, goes to OpenWeather for weather themes. That is location data: unless it meets the ephemeral test, it belongs under the matching Location type.
The policy also answers the last two questions: data sent to Google and OpenWeather is encrypted in transit, and deletion is available in the app (Settings, Delete Account), by email, and on a dedicated account deletion page, which is the web link the form asks for.
Which mistakes cause rejections or policy warnings?
The common failures are declaring no data while shipping Firebase or AdMob, missing data that transitive SDKs collect, mislabeling ad SDK data as not shared, claiming encryption when one request is plain HTTP, and a deletion link that is broken or does not name the app. Google can block updates or remove apps that stay inaccurate.
If Google finds you misrepresented your data practices, it requires a fix, and apps that do not comply face enforcement such as blocked updates or removal. Problems with the Data deletion answers get new submissions and updates rejected. Google's review is not designed to verify your declarations, so a form that passed can still be enforced on later.
Check these in order:
- "No data collected" with Firebase or AdMob in the build. SDK transmissions are your collection.
- Dependencies of dependencies, such as the installations SDK and the merged
AD_IDpermission. - Inferred location from IP addresses.
- Optional data some users cannot avoid. One required path makes it required.
- A form that disagrees with your privacy policy. The User Data policy requires them to be consistent where relevant.
- No update after an SDK change. Answers must stay accurate, and Firebase asks you to recheck its page whenever you update SDK versions.
For the rest of App content, see the content rating questionnaire guide, 3 Play Console checks before you publish, and the Android 16 target API deadline.
IOn Emit is the Windows desktop app I built for the publishing side of this. Its 9-step Pre-Flight Wizard walks through the Play Console setup questions, including Data Safety, in plain English, and its AAB analyzer detects permissions and maps them to Data Safety. Permissions are only a starting point, since SDKs like Analytics collect data without a dangerous permission, so the vendor pages above still matter.
This post is part of our app publishing guides for indie Android developers.