How to Fill Out Google Play Data Safety Section: Complete Guide for Developers

Google Play's Data Safety section is mandatory for all apps. It tells users what data your app collects, whether it is shared with third parties, and what security practices you follow. If the form is incomplete, you cannot publish new apps or updates. This guide walks through every section of the form, explains what counts as "collection" and "sharing," covers the most common third-party SDKs and how to declare them, and shows how to avoid common mistakes.

What the Data Safety Section Is

The Data Safety section appears on your app's Google Play listing. Users see it before installing your app, and it influences their decision to download. It replaced the older permissions-based approach with a developer-declared summary of data practices. Google does not verify every claim automatically, but they do audit apps and can take enforcement action if your declarations are inaccurate.

You fill out the Data Safety form in Google Play Console under App Content > Data Safety. The form asks about data collection, data sharing, security practices, and account deletion. Your answers generate the public-facing Data Safety section on your listing.

Key Concepts: Collection vs. Sharing

Before filling out the form, understand how Google defines these terms, because they are narrower than you might expect.

Data collection means transferring data off the user's device to your server or a third-party server. If data stays on the device and is never transmitted, it is not "collected" in Google's definition. However, if any SDK in your app sends data to an external server (even crash logs or analytics events), that counts as collection.

Data sharing means transferring data to a third party. But Google makes an exception: transferring data to a "service provider" that processes it solely on your behalf, under your instructions, and per your privacy policy is not considered "sharing." This means your backend hosting provider or a cloud database typically does not count as sharing. However, an ad network that uses your users' data for its own targeting purposes does count as sharing.

This distinction matters because "shared" data is displayed prominently on your listing, while "collected but not shared" is shown differently.

Walking Through the Form

Section 1: Data Collection and Sharing Overview

The first question asks: "Does your app collect or share any of the required user data types?" If your app collects any data at all (including through third-party SDKs), answer Yes. Almost every app collects at least device identifiers and crash logs through default SDKs.

Section 2: Data Types

Google organizes data into categories. For each one, you indicate whether it is collected, shared, or both. Here are the categories and what typically falls into each:

Location — Approximate or precise location. If you use GPS, IP-based geolocation, or any location SDK, declare it. Note: even IP-based "approximate location" from analytics counts if the analytics provider records it.
Personal info — Name, email, phone, address, user IDs. If users create accounts, you collect at least some of these.
Financial info — Purchase history, payment info. If you have in-app purchases managed by Google Play Billing, Google handles the payment info, but you may still store purchase history on your server.
Health and fitness — Health data, fitness data. Only relevant for health/fitness apps.
Messages — If your app has messaging features, in-app messages, or email integration.
Photos and videos — If your app accesses the camera or photo library and uploads content.
Audio files — Voice recordings, music files if uploaded or recorded.
Files and docs — If users upload documents or files to your service.
Calendar — Calendar events if your app accesses them.
Contacts — Contact list access.
App activity — Page views, taps, search history, installed apps. If you use analytics (Firebase, PostHog, Mixpanel, etc.), you almost certainly collect app activity data.
Web browsing — Browsing history if your app has a built-in browser that tracks URLs.
App info and performance — Crash logs, diagnostics, performance data. If you use Crashlytics, Sentry, or any crash reporting tool, you collect this.
Device or other IDs — Advertising ID, Android ID, device fingerprints. Most analytics and ad SDKs collect these.

Section 3: For Each Data Type — Purpose and Handling

For each data type you declared, the form asks why you collect it and how you handle it. Purposes include: app functionality, analytics, developer communications, advertising, fraud prevention, personalization, and account management. Select all that apply honestly.

You also answer whether the data collection is optional (user can opt out) or required (app does not work without it), and whether the data is processed ephemerally (used in memory only, never stored).

Section 4: Security Practices

This section asks whether data is encrypted in transit (it should be — use HTTPS everywhere), whether users can request data deletion, and whether your app follows Google's Families Policy (relevant if you target children). If your app supports account deletion, you can check the appropriate box and provide your deletion URL here.

Section 5: Account Deletion

Added in 2024, this section asks whether your app lets users create accounts and, if so, whether it lets them delete those accounts. You must provide a web URL where users can request deletion (this URL appears on your Play Store listing). You also declare what data is deleted vs. retained when an account is deleted.

Common Third-Party SDKs and What to Declare

This is where most developers get confused. Every SDK that sends data off-device needs to be accounted for. Here are the most common ones:

Firebase Analytics — Collects: device IDs, app activity (events, screen views), app info/performance. Declare under App Activity and Device IDs.
Firebase Crashlytics — Collects: crash logs, device info, app state. Declare under App Info and Performance.
Google AdMob — Collects: device IDs, approximate location (sometimes), app activity. This is sharing for advertising purposes. Declare as both collected and shared.
Facebook SDK — Collects: device IDs, app activity, potentially personal info if using Facebook Login. If used for ads, it is sharing.
Google Sign-In — Collects: personal info (name, email, profile photo). Declare under Personal Info.
PostHog — Collects: device IDs, app activity, app performance. Similar to Firebase Analytics. Usually service provider (not sharing).
Sentry — Collects: crash logs, device info. Declare under App Info and Performance.
Stripe — Collects: financial info if you handle payments outside Google Play Billing. Usually service provider.
OneSignal / Firebase Cloud Messaging — Collects: device IDs (push tokens). Declare under Device IDs.

Check each SDK's documentation for their specific data disclosure guidance. Most major SDKs now publish a "Google Play Data Safety" or "Data Disclosure" page that tells you exactly what to declare.

Common Mistakes and How to Avoid Them

Forgetting about SDK data — The most common mistake. You declare only data your own code collects but forget that Firebase, ad networks, and crash reporters also collect data. Audit every dependency.
Declaring "no data collected" for an app with analytics — If you use any analytics tool, you collect data. Period.
Confusing collection with sharing — Sending data to your own backend via a third-party hosting service (AWS, Google Cloud) is collection, not sharing. Sending data to an ad network that uses it for targeting is sharing.
Not providing a privacy policy URL — The Data Safety form requires a link to your privacy policy. It must be live and accessible. Every app needs one, even if it collects no personal data (Google requires the policy URL regardless).
Missing the account deletion URL — If your app has accounts, you must provide a web-based deletion URL. This cannot be "email us" — it must be a URL.
Inconsistency with privacy policy — Your Data Safety declarations and your privacy policy must match. If your policy says you collect location data but your Data Safety form says you do not, that is a policy violation.

How to Keep It Updated

Every time you add or remove an SDK, change what data you collect, or modify your data retention practices, you need to update the Data Safety form. Google enforces this: if they audit your app and find your declarations do not match your actual practices, you can face warnings or removal. Build a habit of reviewing the form whenever you update your app's dependencies or features.

Keeping your privacy policy in sync is equally important. App Club generates privacy policies that are based on the same settings as your project (analytics, ads, data collection, third-party services), so both documents stay consistent. When you change a setting and regenerate, both the privacy policy and the information you need for Data Safety are updated together.