Data Safety Form: A Plain-Language Walkthrough for Indie Developers

The Data safety form asks one thing: what user data does your app collect or share, and why? It looks bureaucratic, but if you know what your app and its libraries actually do, you can finish it in an hour. The hard part is knowing that. This walkthrough shows how to find out and how to answer.

Google changes the form and its wording from time to time, so treat this as a map, not a rulebook. For current definitions, read Google's Data safety help page in Play Console Help.

What the form is for

The form fills in the "Data safety" section on your store listing. Users read it before installing. Google also expects it to match your privacy policy and your app's real behavior. You'll find it in Play Console under the App content section, next to the other declarations (privacy policy, ads, target audience and so on).

In practice, expect to complete it before you can roll out a release. Check Play Console Help for exactly which tracks it applies to, because that can vary.

Step 1: Inventory your data before opening the form

Don't start by clicking through the questionnaire. Start with a plain list. Write down every piece of user data that leaves the device, or that you can read from the device and use.

1. Your own code. Sign-up forms, profile fields, uploaded photos, saved locations, in-app purchases, support messages.
2. Your backend. What does your server store? Check your database tables and server logs. IP addresses in logs count as data in many cases.
3. Every SDK. Analytics, crash reporting, ads, push notifications, authentication, payments, attribution. Open your build.gradle files and list each dependency that isn't pure UI or utility code.
4. Permissions. Read your merged manifest, not just your own. Libraries can add permissions you never wrote.

SDKs are where indie developers most often get caught out. A crash reporter might send device identifiers. An ad library might collect a lot more. Each SDK's documentation usually has a section on data collection for this purpose. If it doesn't, you can watch your app's network traffic with a proxy tool and see what leaves the phone.

Step 2: Understand the key terms

Collected

Generally, data is "collected" when it's transmitted off the user's device, by you or by a library you include. Data that stays on the device, never sent anywhere, usually isn't counted as collected. Confirm the exact definition in Play Console Help, as there are nuances.

Shared

Generally, "shared" means you transfer the data to a third party. There are exceptions, for example for service providers that process data on your behalf, or transfers the user directs. Those exceptions have conditions, so read the current definitions before relying on them.

Required or optional

For each data type you collect, you say whether collection is required or whether users can choose. If the app can't work without it, it's required. If the user can skip it, it's optional.

Purpose

For each data type you pick the reasons: app functionality, analytics, developer communications, advertising or marketing, fraud prevention and security, personalization, account management. Pick what is true, not what looks best.

Step 3: Go through the data categories

The form groups data into categories. At the time of writing these include:

• Location (approximate and precise)
• Personal info (name, email, user IDs, address, phone number and others)
• Financial info
• Health and fitness
• Messages
• Photos and videos
• Audio files
• Files and docs
• Calendar and contacts
• App activity (interactions, in-app search, installed apps and others)
• Web browsing
• App info and performance (crash logs, diagnostics)
• Device or other IDs

Take your inventory from Step 1 and match each item to a category. Some matches are non-obvious:

• An email address used for login is Personal info, collected for account management.
• Crash logs sent to a reporting service fall under App info and performance.
• An advertising ID or a device ID from an SDK goes under Device or other IDs.
• Tapping through screens, if you log it, is App activity.

Step 4: Answer the security questions

The form also asks about your security practices. Two matter most.

• Is data encrypted in transit? If every network call uses HTTPS, the answer is typically yes. Verify that no old endpoints use plain HTTP.
• Can users request data deletion? If you have accounts, you need a way for users to ask for deletion, and Google has requirements around this, including a web option for apps that let users create accounts. Check Play Console Help for current rules.

Don't tick a box because it sounds good. If you claim encryption and one analytics call goes out unencrypted, your form is wrong.

Step 5: Make the privacy policy match

Your privacy policy should be a public URL and should describe the same data practices as the form. If the form says you collect email addresses and the policy never mentions email, that's a mismatch. A short, honest policy that lists data types, purposes, sharing, retention and a contact address is better than a long template you didn't read.

Common mistakes

• Answering "no data collected" by default. If you have analytics, crash reporting or ads, that's almost certainly wrong.
• Forgetting SDK data. Collection by a library you included is generally your responsibility to declare.
• Not updating after a release. Add a new SDK or feature that uses new data and you should revisit the form.
• Copying another app's answers. Their code isn't yours.
• Guessing about sharing. If unsure, read the definition rather than choosing the answer that looks cleaner.

Use your closed test to double-check

A closed test is a good time to verify the form against reality. Before inviting testers, run a build on your own phone, go through every feature, and watch network traffic. Compare what you see with your answers. If you plan to add testing tooling, include it in the review too.

If you use TesterMob, the optional Android SDK (an .aar file) shows daily tester activity in your dashboard. It's a library like any other, so treat it as one: read the details in the documents, decide what it means for your declarations, and check Play Console Help if you're unsure how to classify it. Using the SDK isn't required. The service works without it, and you can read about the process on the developer page.

A quick final checklist

1. List all data your app and backend handle.
2. List every SDK and read its data disclosures.
3. Map each item to a category, with purpose and required/optional status.
4. Confirm HTTPS everywhere and a working deletion path.
5. Check the privacy policy says the same thing.
6. Save your notes so you can update the form at the next release.

No form can guarantee a smooth review, and neither can anyone else, TesterMob included. But an accurate Data safety form removes one avoidable problem. For more on how the testing side works, see the FAQ.