Google Play Data Safety form for solo devs: a row-by-row example
An example walkthrough of Google Play's Data safety section for an indie app that uses Stripe, Supabase, PostHog, and Resend — with the categories Google's documentation defines and cautious wording where the docs leave room for judgement.
Google Play’s Data safety section in the Play Console is the structured equivalent of Apple’s App Privacy Details — a long, mandatory form where you declare which data your app collects, which it shares, why, and whether you encrypt data in transit. Google’s own documentation (Provide information for Google Play’s Data safety section, accessed 2026-05-25) is the source of truth for what each row asks; this post maps it onto a real indie stack so you have a starting point.
TLDR
The Data safety form asks four questions per data type:
- Is the data collected? (“Collected” = sent off-device by your app or any third-party library.)
- Is the data shared? (Sent to a third party beyond your service provider.)
- Is collection optional?
- What is the purpose? (Account management, app functionality, analytics, developer communications, advertising, fraud prevention, personalization, etc. — the list is fixed.)
For each category you also confirm: is data encrypted in transit, can users request deletion, and have you committed to following Google Play’s Families policy and Data safety practices.
A typical indie-stack walkthrough
This is example wording for a hypothetical app that uses Stripe for payments, Supabase for auth and database, PostHog Cloud for product analytics, Resend for transactional email, OpenAI for an AI feature, and Sentry for error monitoring. The exact answer depends on your data model — confirm against your code, not this table.
| Data type (Google’s category) | Collected? | Shared? | Optional? | Purpose | Notes |
|---|---|---|---|---|---|
| Email address (Personal info) | Yes | Yes — with Resend, Supabase | No | Account management, app functionality | Disclose all processors. Encrypted in transit. |
| User IDs (Personal info) | Yes | Yes — with Supabase, PostHog, Sentry | No | Account management, analytics | Disclose all processors. |
| Purchase history (Financial info) | Yes | Yes — with Stripe | No | App functionality | Stripe is named as a financial processor. |
| Payment info (Financial info) | Yes | Yes — with Stripe | No | App functionality | Tokenized on the client by Stripe.js; the raw card never reaches your servers. |
| App interactions (App activity) | Yes | Yes — with PostHog | Yes if you offer an opt-out | Analytics | PostHog session-replay disclosure if enabled. |
| In-app search history (App activity) | Yes if you log it | Yes — with PostHog | Yes | Analytics | Only if you actually log searches. |
| Crash logs (App info and performance) | Yes | Yes — with Sentry | No | App functionality | Strip PII before sending where possible. |
| Diagnostics (App info and performance) | Yes | Yes — with Sentry | No | App functionality | Performance telemetry. |
| Other user-generated content (Messages → Other in-app messages) | Yes if AI feature | Yes — with OpenAI | Yes | App functionality | Disclose what the AI feature does with the input. |
| Device or other IDs (Device or other IDs) | Yes | Yes — with PostHog, Sentry | Yes | Analytics, app functionality | The analytics SDK’s distinct_id usually counts. |
For every row above:
- Encrypted in transit: yes (all of the named vendors require TLS).
- Users can request deletion: yes if you have a “Delete my account” path. Document it in your privacy policy.
- Data shared: yes for the named third parties. Google’s form distinguishes “Collected” (sent off-device) from “Shared” (sent to a third party that uses the data for its own purposes). Most processors do not count as “Shared” if they are bound by a DPA and act only on your instructions — but Google’s guidance has shifted, so check the current wording.
Step-by-step fill workflow
- Inventory every network call your app makes. Use a packet capture or network logger if needed. Every domain you reach is a candidate.
- For each domain, identify the vendor and the data sent. A request body
to
api.stripe.comcarrying a card token is “Payment info” — not just “Financial info” generically. - Map each (vendor, data type) pair to a Google category. Google’s data types and purposes list is the canonical reference.
- Decide “Collected” vs “Shared” per category. A processor (Stripe, Resend, Supabase) acting on your instructions is typically “Collected, shared with service providers”. A third party using data for their own analytics or ads is “Shared”. When in doubt, treat the row as Shared and review.
- Confirm encryption in transit. All major indie vendors use TLS by default; confirm and tick the box.
- Confirm deletion path. You need a working “Delete my account” route, or a documented manual deletion process, before you can answer yes.
- Cross-check against your Apple Privacy Details form. They describe the same data — discrepancies attract review.
Common mistakes
- Treating “Shared” as identical to “third party”. Google’s docs draw a narrow line between processors and third parties. Read the Data safety section docs before committing.
- Forgetting the AI provider in the form. If your app sends user prompts to an LLM API, that’s a data-sharing flow. Declare it.
- Mismatched answers vs Apple. App reviewers on both sides cross-reference. Keep them aligned.
- Skipping the Families policy section when your app could plausibly attract under-13 users.
FAQ
What if I add a new third-party SDK after I submit the form? You re-edit the Data safety section in the Play Console and re-submit. Google’s docs note that the form is meant to stay in sync with your app’s actual data practices.
Does Google Play accept “service providers” as a way to avoid the Shared flag? Yes, but only when the third party acts on your instructions and is bound by a data processing agreement — and you must still declare them in your privacy policy. Google’s documentation is the controlling source; do not rely on forum advice.
Is the form public? Yes. Once approved, your Data safety section appears on your Play Store listing and is one of the things reviewers and savvier users look at.
Related reading
S-003, S-006, S-009, S-010. Each source row is listed in the full disclosure matrix .
Open the Indie App Privacy Disclosure Matrix for a side-by-side view of which platforms expect which disclosures for the services in your stack.