App Privacy Labels and the Google Play Data Safety Form

Both stores now show privacy information prominently on the product page, and both treat inaccurate answers as a policy problem, not a typo. The forms look like a questionnaire you can fill in from memory. They are not. They are a summary of your data flows, and they are only as accurate as your knowledge of what your app and its SDKs send where.

What each store asks

The key definitions differ in detail. Apple considers data "collected" when it is transmitted off the device in a way that lets you or a third party access it for longer than needed to service a request in real time. Google distinguishes "collected" (transmitted off the device) from "shared" (transferred to a third party), with exceptions such as service providers processing data on your behalf. Read the current definitions in Apple's and Google's help pages before you answer; they are more precise than any summary.

Build a data inventory first

Create a simple table with one row per data flow. For each flow, note:

1. Data type, using the store categories: contact info, location, identifiers, usage data, diagnostics, user content, financial info, health data and so on.
2. Source: your own code, your backend, or which SDK.
3. Destination: your servers, an analytics provider, an ad network, an AI API, a payment provider.
4. Purpose: app functionality, analytics, personalization, advertising, fraud prevention, account management.
5. Linked to identity? Is it tied to an account, email or device ID?
6. Optional or required for the user.
7. Retention and deletion: how long it is kept and how users can request deletion.

Then check every SDK's own privacy documentation. Many SDK vendors publish guidance on how to answer the data safety form and ship Apple privacy manifests; use them, but verify against your configuration.

The usual blind spots

• Crash reporting and analytics collect device identifiers and usage data even if you never look at them.
• Ad SDKs often mean "used to track you" on Apple and "shared" on Google.
• Support chat widgets collect names, emails and message content.
• WebView content: if your app wraps a website, the website's analytics, forms and embedded third parties count as well.
• AI features: text, images or voice that users enter and that you send to an LLM API are user content transmitted off the device. Declare them with the right purpose, and mention the provider in your privacy policy.
• Logs on your own backend that capture email addresses or free text.

AI features need extra care

Apps that send user input to services like OpenAI, Anthropic or Google models create data flows that are easy to overlook in the forms and sensitive under GDPR. Three questions help:

• Does the prompt contain personal data, and does it need to?
• Does the provider retain or use the data, and under which agreement?
• Can the same feature work with anonymized or pseudonymized input?

Removing personal data before it leaves the device reduces both legal exposure and what you send to third parties. A local anonymization layer such as Textwash Pro, which removes personal data from text fully offline, is one way to do this in front of ChatGPT, Claude and similar services. Your labels still have to describe what is actually transmitted, so update them to match the real flow after you implement any such measure. For techniques and limits, see how to anonymize data before sending it to ChatGPT or Claude and the GDPR checklist for AI product teams.

A worked example

Take a note-taking app with accounts, crash reporting and an AI summary feature. The inventory shows: email address (account management, linked to the user), crash logs and device identifiers (diagnostics, via the crash SDK), notes content (app functionality, stored on your backend) and note text sent to an LLM API for summaries (app functionality, processed by a service provider). Each row maps to a category in both forms. Without the inventory, the AI flow and the crash SDK are exactly the rows teams tend to forget.

Keeping the answers accurate over time

1. Make the data inventory part of your definition of done: a new SDK, permission or API call means an inventory update.
2. Review both forms before every release that adds features, not only once a year.
3. Keep your privacy policy, the store forms and the in-app consent dialogs consistent. Mismatches are what reviewers and regulators notice first.
4. Check Play Console's policy status page and Apple's review messages for privacy-related findings.
5. Assign an owner. Privacy forms without an owner drift out of date within a few releases.

Inaccurate data safety answers are one of the most common Play issues, covered in our Google Play rejection guide; on the Apple side, labels belong on the App Store submission checklist. If you want a second pair of eyes on forms and declarations as part of a release, appsubmitter.io includes guidance through store requirements in your own accounts.