How to Fill Out Google Play's Data Safety Section (Without Getting Rejected)
The Data Safety section is the single most common place no-code makers get tripped up on Google Play. It looks like a quick form, but every answer is a legal declaration Google now checks against your actual app binary and your privacy policy. Get it wrong and you get a rejection email days later, right when you thought you were done.
This is a field-by-field walkthrough. You'll know exactly what each question means, how to answer it honestly, and where the traps are.
What is the Data Safety section?
The Data Safety section is a form inside Google Play Console (under App content → Data safety) where you declare what user data your app collects, what it shares, why, how it's protected, and whether users can request deletion. Google turns your answers into the "Data safety" card that shoppers see on your Play Store listing.
Two things make it high-stakes in 2026:
- Automated binary checks. Before you can even submit, Play Console scans your APK/AAB. If your app touches a data type you didn't declare, it flags you before a human ever looks at the app.
- Privacy policy cross-checks. Reviewers compare your form to your privacy policy. If your form says you collect email addresses but your policy never mentions them, that's a mismatch and a likely rejection.
The fix for both is the same: declare honestly, and make your privacy policy match. If you don't have a policy yet, generate one that lists your data types with the app privacy policy generator before you touch this form, so the two documents line up from the start.
First, figure out what data your app actually collects
Before you open the form, make a list. Most no-code makers forget that data collection isn't just the fields in your own forms; it's also everything your integrations and SDKs do behind the scenes.
Check every one of these:
- Your own database fields — sign-up forms, profiles, anything a user types or uploads.
- Authentication — email, phone, name, or social login IDs you store.
- Analytics — Google Analytics, Firebase, or any usage tracking sends app-activity and device-ID data.
- Crash reporting — crash and diagnostic tools collect app info and device IDs.
- Ads — ad SDKs almost always collect the Advertising ID and app activity.
- Payments — Stripe, RevenueCat, or in-app purchases touch financial info and purchase history.
- Push notifications — Firebase Cloud Messaging uses device identifiers.
- Location, camera, photos, contacts — anything your app requests permission for.
If you're not sure what a service collects, check its documentation; most major SDKs publish a "Data Safety" mapping you can copy. When in doubt about whether something counts, see the full breakdown of when an app needs a privacy policy — the same collection triggers apply here.
The 14 data categories Google asks about
Google groups everything into 14 categories. For each one you'll either mark it out of scope or answer a short set of questions. Here's what each category covers.
| Category |
What it includes |
| Location |
Approximate location (≥3 sq km, e.g. from IP) and precise location (<3 sq km, GPS) |
| Personal info |
Name, email, user IDs, address, phone number, race/ethnicity, political or religious beliefs, sexual orientation, date of birth, gender |
| Financial info |
Payment info, purchase history, credit score, salary |
| Health and fitness |
Health records, symptoms, exercise and fitness data |
| Messages |
Emails, SMS/MMS, other in-app messages |
| Photos or videos |
Image and video files |
| Audio files |
Voice or sound recordings, music files |
| Files and docs |
General file and document storage access |
| Calendar |
Calendar events and related data |
| Contacts |
The user's contact list |
| App activity |
App interactions, in-app search history, installed apps, other user-generated content |
| Web browsing |
Browsing history |
| App info and performance |
Crash logs, diagnostics, performance data |
| Device or other IDs |
Advertising ID, Android ID, Firebase installation ID, IMEI, MAC address |
Most simple no-code apps end up declaring a handful: Personal info (email/name from sign-up), App activity and Device IDs (analytics), and App info and performance (crash reporting). If you take payments, add Financial info. If you use maps, add Location.
The questions you answer for each data type
Once you mark a data type as collected or shared, Google asks the same set of follow-up questions. Answer each one for that specific data type.
1. Is this data collected, shared, or both?
- Collected = your app transfers the data off the device (to your servers or a third-party SDK).
- Shared = you transfer the data to a separate company or third party.
Important nuance: data sent to a provider that only processes it on your behalf (like your hosting or database provider) counts as collected but not shared. Sharing means the third party can use the data for their own purposes. Data you're legally compelled to disclose, fully anonymized data, and data a user knowingly sends to another party through an in-app action are also excluded from "shared."
2. Is this data processed ephemerally?
If the data is only accessed in memory, used momentarily, and never stored or sent off the device, it's "processed ephemerally" and you can mark that instead of "collected." The moment you write it to a database or send it to a server, it's collected and must be declared.
3. Is collection required or optional?
- Required = the user can't turn it off and still use the app.
- Optional = the user can choose whether to provide it, or it's tied to a feature they can skip.
4. Why do you collect or share it? (select all that apply)
- App functionality
- Analytics
- Developer communications
- Advertising or marketing
- Fraud prevention, security, and compliance
- Personalization
- Account management
Only tick the purposes that are genuinely true. Over-declaring purposes (e.g. marking "Advertising" when you run no ads) can trigger questions of its own.
The security section
After the per-type questions, Google asks two overall security questions. These apply to how you handle all the data you declared.
- Is all of this data encrypted in transit? You can only answer "Yes" if data travels over HTTPS/TLS. Any app built on a modern no-code platform and reputable SDKs will be, but confirm your custom API calls and webhooks use
https://, not http://.
- Do you provide a way for users to request that their data be deleted? If yes, you'll be asked for details. If your app supports account creation, Google separately requires a publicly accessible deletion URL that works without logging in and links directly to a data-deletion request — you set this under App content → Data deletion.
A worked example: a simple no-code app
Say you built a habit-tracker in Adalo. Users sign up with email, you use Firebase Analytics, and you have crash reporting on. No ads, no payments, no location. Here's how the form fills out:
| Data type |
Collected? |
Shared? |
Required? |
Purpose |
Encrypted in transit |
| Email address (Personal info) |
Yes |
No |
Required |
App functionality, Account management |
Yes |
| Name (Personal info) |
Yes |
No |
Optional |
App functionality |
Yes |
| App interactions (App activity) |
Yes |
No |
Required |
Analytics |
Yes |
| Advertising ID / device ID |
Yes |
No |
Required |
Analytics |
Yes |
| Crash logs (App info & performance) |
Yes |
No |
Required |
Analytics |
Yes |
Everything else stays out of scope. You'd answer "Yes" to encryption in transit, offer in-app account/data deletion, and provide a deletion URL because the app supports accounts. Simple, honest, and it matches a privacy policy that lists exactly these five items.
Common mistakes that get apps rejected
- Declaring "no data collected" while running analytics or ads. This is the #1 automated flag. Firebase Analytics alone collects device IDs and app activity.
- Forgetting SDK-collected data. Your ad, attribution, or crash SDK collects data even if your own forms don't. Map every SDK.
- Marking "not shared" when an ad or analytics network uses the data for its own purposes. That's sharing.
- Answering "encrypted in transit: Yes" while calling an
http:// endpoint. Any non-TLS call breaks this claim.
- A privacy policy that doesn't list a data type you declared. The two must match exactly.
- Skipping the account-deletion URL on an app that lets users create accounts.
For the rest of the pitfalls that sink no-code submissions on both stores, read why apps get rejected from the app store.
Where this fits in your launch
The Data Safety section is one line item on a longer publishing to-do list. Do it right after you've finalized your privacy policy and before you push your release for review. To make sure nothing else slips, run through the full app store submission checklist before you hit submit.
Frequently asked questions
Is the Data Safety section required for every app?
Yes. Every app on Google Play must complete the Data Safety form before it can be published or updated, even apps that collect no data at all. If your app collects nothing, you still declare that explicitly by answering "no" to the collection and sharing questions.
What's the difference between collecting and sharing data?
Collecting means your app transfers data off the device (to your server or a third-party SDK). Sharing means you transfer that data to a separate company or third party. Data handled by a service acting on your behalf, like a hosting provider, counts as collected but usually not shared.
What is 'processed ephemerally' and can it exempt me from declaring data?
Data is processed ephemerally when it's only accessed in memory, used for a single moment, and never written to storage or sent off the device. Ephemeral data does not need to be declared as collected. If you store it or transmit it, it must be declared.
Does my Data Safety form need to match my privacy policy?
Yes. Google cross-checks your Data Safety declarations against your privacy policy and, increasingly, against your app binary. Mismatches are one of the most common causes of rejection, so your privacy policy must list every data type you declared collecting or sharing.