Google Play Data Safety Section: How to Fill It In Correctly
Don't answer the Data Safety form from memory — derive it from your app. Your manifest's permissions and your SDK list determine nearly every answer: match each data type to the permission or SDK that collects it, flag the uncertain ones, and declare exactly that. Rejections almost always mean the form contradicts what the app actually does.
Start from the AAB, not the questionnaire
Open your app's permissions and SDK list first. Camera permission means photos are in play; location permissions mean location answers need care; each SDK (Auth, Analytics, Crashlytics, AdMob, Maps, payment SDKs) maps to a known set of disclosures to verify. Our Data Safety generator automates this mapping from your uploaded AAB and shows the evidence behind every suggestion.
Data Safety vs privacy policy — what's the difference?
The Data Safety section is the structured, user-visible summary on your store listing; the privacy policy is the full hosted document. Google compares them. If your policy mentions analytics but your Data Safety form says no data collected, expect a rejection. Generate both from the same reviewed profile and they stay consistent by construction.
Common Data Safety mistakes that get apps rejected
The repeat offenders: location permissions with no location declared; an ads SDK with no advertising ID; analytics SDKs with "not collected" checked; health or fitness data treated casually; and stale forms after an SDK was added two versions ago. Each is a five-minute check against your manifest — or one upload through the analyzer — versus weeks lost to a review cycle.
Data Safety answers for common SDKs
AdMob apps: advertising ID collected and usually shared for advertising — review personalization carefully. Firebase Analytics apps: app interactions plus device/app-instance identifiers for analytics. Stripe/Paystack/RevenueCat apps: purchase history, with financial details depending on what you handle versus the processor. Firebase Auth apps: email, name, and user IDs for account management. Treat every line above as a suggestion to verify, never as a declaration to copy.
Frequently asked questions
Data Safety vs privacy policy — what's the difference?
The Data Safety section is a structured declaration inside Play Console (data types, purposes, sharing) that users see on your store listing. The privacy policy is a hosted document going into detail. They must agree with each other — contradictions between the two are a classic rejection trigger.
What are the most common Data Safety mistakes that get apps rejected?
Declaring no location collection while requesting location permissions; forgetting the advertising ID when an ads SDK is present; marking analytics data as not collected while shipping Firebase Analytics; and letting the form go stale after adding a new SDK. Every one of these is checkable from your AAB before you submit.
How do I answer Data Safety for a Firebase app?
Firebase Auth typically means email, name, and user IDs for account management. Analytics means app interactions and device IDs for analytics. Crashlytics means crash logs and diagnostics. Confirm each against what you actually use — then declare exactly that.
How do I update my Data Safety form after adding a new SDK?
Re-check the SDK's data practices, update the affected answers in Play Console, and update your privacy policy to match. If you generated your original form with our tool, upload the new AAB and regenerate the profile for the new version.
Keep going
Fill the form from evidence
Upload your AAB, review the draft, download the CSV.