Filling Out Google Play Data Safety Details Correctly

1. What the Data Safety form specifically requires

The Data Safety form in the Play Console asks, for every defined data category such as location, personal information, financial data, or device identifiers, whether the app collects that data at all, for what purpose it's used, and whether it's additionally shared with third parties. Each of these three questions has to be answered independently for every applicable data category.

The details then appear directly on the app's public Play Store listing, visible to every potential user before they even download it. That makes it not just an internal compliance formality but a visibility factor that directly influences the install decision of privacy-conscious users.

2. Why guessing isn't a viable strategy

Many teams fill out the form based on what the app is supposed to do according to its product description, rather than on what the actually shipped code and integrated SDKs technically collect. This gap typically arises because third-party SDKs like analytics, crash-reporting, or advertising libraries collect data independently, without that being explicitly visible in the app's own code.

An ad SDK, for instance, can collect device identifiers, approximate location, and usage behavior in the background, entirely independent of whether the app itself actively requests that data. Teams that fill out the form based only on their own feature list systematically overlook such SDK-driven data collection.

3. Conducting a systematic SDK inventory

The most reliable starting point is a complete list of every dependency referenced in package.json plus every native Pod and Gradle dependency, paired with a check for which of them actually make network requests to external servers. Every SDK with network access deserves a targeted review of its official privacy documentation.

For common SDKs like Firebase Analytics, Sentry, AdMob, or the Facebook SDK, vendors usually publish their own Data Safety mapping documents, listing exactly which data categories to check in the Play Console form for that particular SDK. These documents don't replace an independent review, but provide a reliable starting point instead of a pure guess.

# Roughly identify network-relevant SDKs in a React Native project
grep -E "analytics|crashlytics|sentry|admob|facebook|amplitude|mixpanel" \
  package.json ios/Podfile.lock android/app/build.gradle

# Roughly spot native network endpoints in a built Android bundle
grep -rE "https?://[a-zA-Z0-9.-]+" android/app/build/outputs/apk/release/ 2>/dev/null | sort -u

4. Mapping data categories correctly

The Play Console distinguishes between location, personal information, financial information, messages, photos and videos, audio files, device identifiers, and app activity, among others. Within each category, a further distinction between collected and merely processed data is required, which in practice frequently leads to mix-ups.

One example: a photo upload feature that processes an image purely locally and never sends it to a server does not need to be declared as collected under photos and videos. If the same image ends up even temporarily on cloud storage for analysis, say for an AI-driven image description, that already counts as collection under the form's definitions.

5. Distinguishing third-party sharing from pure processing

Google draws a clear line between merely collecting data to run the app itself and sharing that data with a separate company for that company's own purposes. A cloud hosting provider that stores data solely on behalf of the app generally does not count as third-party sharing under the form, as long as the provider has no independent use for that data.

An ad network or analytics provider that additionally uses collected data for its own purposes, such as market research or improving its own product, clearly counts as third-party sharing and must be declared as such in the form, regardless of whether a separate contractual agreement exists for it.

6. Peculiarities in React Native and Expo projects

In React Native projects using Expo, it's worth also checking Expo's own modules and their permissions in app.json or app.config.js, since Expo itself can technically request additional data categories like location or contacts depending on which modules are used, even without those being explicitly requested in the app's own code.

In bare React Native projects with manually integrated native modules, the review is more involved, since every native module has to be checked individually for actual data collection instead of relying on a central configuration format like app.json. A full code search for permission requests in AndroidManifest.xml and Info.plist remains the most reliable starting point here.

7. Consequences of incorrect declarations

Google doesn't just check Data Safety details once at submission time, it automatically spot-checks them against the app's actual behavior on an ongoing basis, among other things through an analysis of actual runtime network communication. If a discrepancy is found, this typically leads to a correction request with a deadline first, but repeated or severe violations can result in the app being removed from the store.

Beyond the immediate store consequence, a later-discovered false declaration damages user trust lastingly, especially if media outlets or privacy organizations make the discrepancy public. Unlike a technical rejection, that kind of lost trust can't simply be undone by correcting the form entry.

8. Making Data Safety a fixed part of the release process

Since an app's SDK footprint can change with every release, the Data Safety review shouldn't remain a one-time event at first launch but should become a fixed part of every major release cycle. A newly integrated analytics SDK without a corresponding form update is one of the most common causes of later discrepancies.

In practice, a short checklist in the release process works well, explicitly checking every new or updated dependency with network access for whether it changes the Data Safety details, rather than leaving that check to chance or to individual team members' memory.

9. Common sources of error in practice

A common mistake is correctly declaring an SDK's data category but getting the purpose wrong, for example checking analytics when the SDK actually also uses the data for personalized advertising. Another frequent mistake involves push notification services, whose device token collection regularly gets overlooked even though it falls under device identifiers.

It's also frequently overlooked that optional features like a camera upload or a location search have to be declared as data collection even if only a small share of users actually enables that feature. The declaration follows the technical possibility of collection, not the actual frequency of use in the field. A final, often underestimated point concerns internal test and debug builds: even if tracking SDKs are only active there for development purposes, that technically still counts as data collection and should consistently feed into the same review process as the production release.

10. Summary

11. FAQ: Google Play Data Safety: Key Takeaways