Google Play Data Safety Form: A Practical Walkthrough

Before your app reaches anyone outside your internal testers, Play Console asks you to describe what user data it collects, what it shares, and how you protect it. Your answers become the Data safety section on your store listing. The definitions are precise, and a wrong answer is a policy issue, not a typo. This guide covers the form, the rest of the App content page, and Google's export declaration. Google's wording below is from its own pages as of 10 September 2026. This is a practical guide, not legal advice.

The short version

• Every app published on Google Play needs a Data safety form, including apps on closed, open or production tracks. Apps that are active on internal testing alone are exempt.
• An app that collects nothing still completes the form and links a privacy policy.
• "Collected" means the data leaves the device. "Shared" means it goes to a third party. A service provider processing data on your behalf is not sharing.
• Data your SDKs send counts as your app's data. You answer for it.
• Play has no encryption questionnaire like TestFlight's. You acknowledge a US export laws declaration when you create the app, and compliance is your responsibility.

Who has to complete the form

As of 10 September 2026, Google's help article Provide information for Google Play's Data safety section says every developer with an app published on Google Play must complete the form, including apps on closed, open or production testing tracks. Apps exclusively active on internal testing are exempt, as are system services and private apps. An app that collects no user data still completes the form and links a privacy policy.

The form is global, per package name. It must describe the sum of what every version of your app still distributed on Play does, in every region, so an older build that still ships an analytics SDK counts.

Before you start

1. Add a privacy policy. The form requires one. Google's User Data policy asks for a link in Play Console and inside the app, on an active public URL that is not a PDF.
2. Review your permissions, APIs and SDKs. Data that libraries and SDKs send off the device counts as your app's, whether it goes to your server or theirs. Google suggests checking each provider's published Data safety guidance and the Google Play SDK Index.

Collected, shared, or neither

• Collected means transmitted off the user's device. Data processed on the device alone, or end-to-end encrypted so that nobody but sender and recipient can read it, is out of scope.
• Ephemeral processing, held in memory just long enough to answer a request, goes in your form but is not shown on the listing.
• Pseudonymous data counts if it can reasonably be re-associated with a user.
• Shared means transferred to a third party. Transfers to a service provider that processes data on your behalf and on your instructions are not sharing, and neither are legal transfers, transfers the user starts and expects, or fully anonymised data.

So hosting, crash reporting or a feedback tool that processes data for you, not for its own purposes, is collection, not sharing.

Data types and purposes

The form lists categories from location and financial info to contacts and device IDs. The types a typical app touches are Name, Email address and User IDs under personal info; App interactions, Other user-generated content and Other actions under app activity; Crash logs and Diagnostics; and Device or other IDs, such as an advertising identifier.

For each type you pick purposes: App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security and compliance, Personalization, and Account management. Choose what your app actually does with the data.

You also mark each type required or optional. Optional means users control it, such as a field they can leave blank, and it has to hold for every user on every device and in every region. If any version of the app requires the data, declare it required.

Security practices

• Is all user data encrypted in transit? Google names TLS and HTTPS. "All" means every piece of user data your app and its SDKs send.
• Can users request deletion? No mechanism is prescribed; Google gives in-app features, contact forms and an email alias as examples. Separately, the User Data policy requires apps with account creation to offer account deletion in the app and on the web.

Filling it in

The form is under Data safety on the App content page in Play Console. You select the types you collect or share, answer usage questions for each, and check a preview of your listing. Answers can be saved as a draft, or exported to and imported from CSV.

Google says its review is not designed to verify your answers and that you alone are responsible for them. If it finds a mismatch with your app's behaviour, it may block updates or remove the app. Update the form whenever your data practices change, including when you add an SDK.

The rest of the App content page

As of 10 September 2026, Google's article Prepare your app for review lists the other declarations on the same page:

• Ads: whether your app shows ads, including through ad SDKs. If it does, the listing shows "Contains ads".
• Sign-in details: how reviewers get past a login.
• Target audience and content: your app's age groups. Including children brings in the Families policy.
• Content ratings: a questionnaire whose answers produce ratings from the IARC authorities. Google warns that "Unrated" apps may be removed.
• Permissions declarations for high-risk permissions such as SMS or Call Log, plus declarations for news and a few other app types.

Start early: Google's content rating requirements say the target audience section needs the ads declaration, sign-in details and privacy policy done beforehand.

Export compliance on Google Play

If you know TestFlight's Missing Compliance status, expect something much shorter. As of 10 September 2026, Google's article Create and set up your app says you acknowledge the "Developer Program Policies" and "US export laws" declarations when you create an app. There is no per-build encryption questionnaire and no Info.plist-style key.

Google's page on export compliance explains why: Google is a US company hosting your app, and the US government treats a download from outside the US as an export, so US export rules on encryption software may apply even if you are not in the US. Open source does not exempt you, and calling encryption in another program can count. Google says it cannot give legal advice and that it is up to you to determine your compliance requirements. So the thinking Apple's questionnaire forces still applies on Play; nobody asks you to show it. Decide your answer with whoever handles legal questions, and write down why. If you also ship on iOS, see TestFlight Missing Compliance for Apple's version.

How FeedbackKit fits in

If your app includes FeedbackKit, its data belongs in your form like any other SDK's. We checked what the Kotlin SDK sends by reading its source as of 10 September 2026. In production, every request goes over HTTPS to FeedbackKit's API, with your project's API key, and with the user ID you configured when you set one.

What we did not find: the Kotlin SDK does not read a location, an advertising ID, a device identifier, your contacts, files or photos, and it does not post a user's revenue. If you send each user's MRR to FeedbackKit by another route, such as the REST API, declare that financial information yourself.

Notes to help you decide:

• Collected, not shared, in our reading. FeedbackKit's privacy policy says FeedbackKit acts as a data processor for its customers' end-user data, which fits Google's service-provider exception. If you move the data elsewhere, review your answers.
• Purposes are yours. App functionality fits a request board; add marketing or analytics if you use the data that way.
• Deletion. The SDK has no deletion call. Project owners and admins on Pro and Team can delete a request, and the native admin apps can remove a comment. Check that this covers what a deletion request needs in your app before you answer yes, and describe the route in your privacy policy.
• Other SDKs differ. The Flutter and React Native SDKs have their own request bodies. Check the one you ship in the Flutter or React Native docs.

Your app and your other code shape the final answers, so treat the table as a starting point, not a declaration. Setup for Android is in the Kotlin docs and our guide to adding a feedback board in Kotlin.

Here is how collecting feedback looks in FeedbackKit, with sample data from a fictional hiking app:

Once the form is in, the next steps are your testing tracks; our guide to Google Play testing tracks picks up from here. To give your Android users a place to ask for what comes next, start free.