Google Play Data Safety Form (2026): How to Fill It Correctly

The Google Play Data Safety form is a required disclosure that tells users what data your app collects, how it is used, and how it is protected. The form is mandatory for all apps on Google Play, and the most common reason for rejection is a mismatch between what the form says and what your app's SDKs actually do. This article covers how to fill the form accurately, avoid contradictions, and get your Play Store submission approved on the first try.

Quick checklist: What the Data Safety form covers

Section	What to declare
Data collection	Whether your app collects any user data
Data types	Location, personal info, financial info, photos, files, etc.
Data use	App functionality, analytics, advertising, personalization
Data sharing	Whether data is shared with third parties
Security practices	Encryption in transit, data deletion mechanism
Family policy	Whether your app targets children

The mismatch problem

Google cross-checks the Data Safety form against your app's actual behavior — including SDK behavior. If the form says your app doesn't collect location data, but your analytics SDK requests location permissions, Google will flag the mismatch. This is the single most common rejection reason for the Data Safety form.

To avoid mismatches, audit every SDK in your app before filling the form. Check what data each SDK collects, whether it transmits data off-device, and whether it shares data with third parties. The 14-day testing requirement gives you time to catch these issues before production submission.

Implementation checklist

1. Audit your SDKs

List every third-party SDK in your app: analytics (Firebase, PostHog), crash reporting (Sentry, Crashlytics), advertising (AdMob), authentication (Supabase, Firebase Auth), and any AI APIs. For each SDK, document what data it collects and whether it shares data with third parties.

2. Declare all data types

In the Data Safety form, declare every data type your app or its SDKs collect. Common types include: approximate location, email address, user ID, device ID, crash data, performance data, and diagnostic data. When in doubt, declare it — over-disclosure is safer than under-disclosure.

3. Match your privacy policy

Your privacy policy must align with the Data Safety form. If the form says you collect email addresses for analytics, your privacy policy must state the same. Inconsistencies between the form and the policy trigger rejection.

4. Declare data sharing accurately

If any SDK shares data with third parties (e.g., an advertising SDK sharing device IDs with ad networks), declare it in the Data Sharing section. Failure to declare third-party data sharing is a policy violation.

5. Verify encryption claims

If you claim data is encrypted in transit, ensure all network traffic uses HTTPS. Google may test your app's network traffic. If you claim encryption but some requests use HTTP, that is a mismatch.

6. Provide a data deletion mechanism

Google Play requires apps that collect user data to provide a way for users to request data deletion. This can be an in-app option, a web form, or a link to a deletion request page. The deletion mechanism must be declared in the Data Safety form.

Common rejection mistakes

• Undeclared SDK data: An analytics or advertising SDK collects data that is not declared in the form.
• Contradicting privacy policy: The form says "no data sharing" but the privacy policy mentions sharing with advertising partners.
• Missing data deletion: The form claims users can delete data, but no in-app or web deletion mechanism exists.
• False encryption claim: The form says data is encrypted in transit, but some API calls use HTTP.
• Stale form after SDK update: You add a new SDK that collects data but forget to update the Data Safety form.

Before you submit

Data Safety form mismatches are a top rejection reason on Google Play. Run a free Launch Score check to audit your app's data collection, SDK behavior, and privacy compliance before submitting.

Run your free Launch Score