Google Play Data Safety Form: What to Declare Before Review

Your app builds cleanly, your closed test is running, and Play Console still will not let you submit. The blocker is a form on the App content page you may not have opened yet: the Data safety declaration.

It is required for every app published on Google Play, and that includes apps that are only on a closed, open, or production testing track. Developers routinely discover it mid-testing, when a submission is rejected for something that has nothing to do with their code.

This guide covers what the form actually asks, what Google classifies as data collection, why your third-party SDKs are your responsibility, what the account deletion questions require, and what happens when a declaration turns out to be wrong.

Do you have to complete the Data Safety form before launch?

Yes, and earlier than most developers expect. Google's requirement is not limited to production releases:

All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks. This also applies to pregranted and preloaded apps that update through Google Play.

That sentence catches a large number of developers out, because the instinct is to treat compliance as a launch activity. If you have published a closed testing release, you have an app published on Google Play, and the form applies to you now rather than at launch.

Two exemptions exist, and both are narrow. Apps that are active only on internal testing tracks do not need to complete the form, so a project that has never left the internal track is genuinely out of scope. System services and private apps are also exempt. Anything beyond that, including an app that collects nothing at all, falls inside the requirement.

The zero-data case is worth stating plainly because it surprises people: if your app collects no user data, you still complete the form, and it still expects a privacy policy link. The declaration in that situation is simply that nothing is collected or shared. There is no version of this where the form can be skipped.

One practical consequence of the timing rule: if you are running a closed test with the twelve testers Google Play requires for production access, the Data safety form is a parallel workstream, not a post-approval task. Handling it during the test window is usually free time you already have.

What does Google count as data collection?

The form's definition is broader than most developers assume, and it is not about what your app stores on the device. Google's definition is about transmission off the device:

"Collect" means transmitting data from your app off a user's device.

Three clarifications in Google's guidance do most of the work here, and each of them has caught out a real category of app.

The first concerns libraries and SDKs. Data transmitted off device by a library or SDK inside your app counts as collection, and it does not matter whether that data goes to your own server or to a third party's. This single rule is the reason most inaccurate declarations exist, and it is covered in its own section below.

The second concerns webviews. Data collected from a webview that your app opened, where your app controls the code or behaviour delivered through that webview, is in scope. The exception is a webview in which the user is navigating the open web, which is not collection. The distinction is control over what is rendered, not the mere presence of a WebView.

The third concerns ephemeral processing, which is the most misunderstood. Data transmitted off device and processed ephemerally must still be included in your form response, but if it meets Google's standard it will not be disclosed in the store listing. Processing data ephemerally means accessing and using it while it is only stored in memory and retained no longer than necessary to service that specific request in real time. Google's own example is a weather app that sends location off device to fetch a forecast and does not store it once the request completes.

The limit on that exception matters more than the exception itself. Using data to build advertising profiles or other user profiles cannot be treated as ephemeral and must be declared as collection or sharing. An analytics SDK that turns your event stream into user profiles is not doing ephemeral processing, however briefly the raw event existed.

Finally, pseudonymous data is in scope. Data that can reasonably be re-associated with a user must be disclosed, so renaming a user identifier rather than removing it does not move it out of scope.

Do third-party SDKs count as your data collection?

Yes. This is the single most common cause of an inaccurate declaration, and it is the one Google is least forgiving about.

Google's guidance is explicit that the form includes data transmitted off device by libraries and SDKs used in your app, irrespective of whether the data is transmitted to you or to a third-party server. The reason this trips developers up is structural: you cannot see what an SDK does from your own source code. A crash reporter, an analytics library, an ad network, or a push notification service can each transmit identifiers and usage data without any code you wrote being involved.

The practical fix is an audit rather than a guess. Before opening the form, list every third-party dependency in your build and check what each one transmits. Google points developers at the Google Play SDK Index, where providers publish their own data safety guidance, and recommends referring to your providers' published information. Reading the SDK vendor's mapping is far more reliable than inferring from the permission list, although the permission list is a useful cross-check.

Two habits make this manageable. First, pin your SDK list to a document and update it whenever a dependency changes, because the form has to be re-checked whenever your code changes. Second, treat adding a new SDK as a compliance event rather than a routine version bump, since a library swap can silently introduce a new data type into your declaration.

The reason the stakes are high is that responsibility does not transfer. Google's review process for the form is not designed to verify the accuracy and completeness of your declarations, which is stated plainly in the guidance. The obligation to be complete and accurate sits with you, including for data movement you did not intend and cannot see directly.

What happens if your Data Safety form is inaccurate?

Two separate things, and they escalate differently.

The first is administrative and immediate. If you answer that your app collects data, the form asks you to confirm whether all of that data is encrypted in transit and whether you provide a way for users to request that their data be deleted. Incomplete or inconsistent answers block submission in Play Console, which is the rejection most developers actually encounter. It is a gate on your release process rather than a penalty.

The second is enforcement, and it is more serious. Google states that when it becomes aware of a discrepancy between your app's behaviour and your declaration, it may take appropriate action, including enforcement action. That is deliberately open-ended language, and it covers the case where your app does something your form does not mention.

The asymmetry between those two outcomes is worth internalising. The form does not verify itself, so an under-declaration is unlikely to be caught at review. It gets caught later, when a re-review, an automated check, or a user report surfaces the mismatch, at which point you are defending a published declaration rather than correcting a draft. Under-declaring is not a shortcut that is merely unethical. It is a delay that converts a paperwork problem into a policy problem.

There is also a trust dimension that is easy to dismiss and should not be. The declaration appears on your store listing next to your screenshots and reviews, in the section users see before installing. A declaration that contradicts what the app actually does is not a neutral error, because it is the specific thing Google built the section to prevent.

What are Google Play's account deletion requirements?

If your app lets users create an account from inside the app, the User Data policy requires that it also lets them request deletion of that account. Google's wording sets out the trigger condition precisely:

If your app allows users to create an account from within your app, our User data policy requires that it must also allow users to request for their account to be deleted.

Two channels are required, not one. The requirement covers both an in-app path and a web resource, meaning a user who has uninstalled your app must still be able to reach a deletion route without reinstalling it. A settings screen that hides the option behind a login the user cannot complete is not a compliant in-app path, and an in-app option with no web equivalent is not compliant either.

Deleting the account is only half of it. Google's guidance states that when you delete an app account based on a user's request, you must also delete the user data associated with that app account. The requirement is about the account and its data, so retaining records after closure needs a specific justification rather than being the default.

The consequences for incomplete answers are unusually direct. Where there are issues with your answers to the Data deletion questions in the Data safety form, new submissions and app updates are rejected in Play Console, and you will not be able to publish a new app or an app update while those questions are incomplete or have unaddressed issues.

This is why the account deletion questions are worth handling before you are under release pressure. They are the one part of the form where an incomplete answer reliably stops a release rather than producing a warning, and the work they imply is real engineering rather than form filling, because a deletion route has to exist in your product before you can declare that one does.

What should you have ready before starting the form?

Three things, and gathering them first is what turns the form from an afternoon of guessing into a short task.

The first is a live privacy policy, linked from your store listing. This is not optional even for an app that collects nothing, because the form requires a privacy policy link in every case. It cannot be a placeholder page, since the link is part of what is declared and shown to users.

The second is an audit of your declared permissions and the APIs your app uses. Google's developer guidance for completing the form maps data types to concrete indicators, listing the permissions, API calls, and UI patterns that suggest each category applies. Reviewing your declared permissions against that mapping tells you which categories are in scope before you start answering questions.

The third, and the one most developers skip, is an inventory of every third-party library and SDK in the build, with what each one transmits. Google recommends reading the requirements for completing the form and reviewing how your app collects and shares data, and it is explicit that third-party code counts as yours.

Once those are in hand, the shape of the exercise is straightforward. You are asked whether your app collects or shares any required user data types, then asked to confirm encryption in transit and whether users can request deletion, then to select every applicable data type, and then to answer per-type questions about how the data is used and handled. Before you submit, Play Console shows a preview of exactly what will appear on your store listing, which is worth reading as a user would.

If you need to pause, the form can be saved as a draft and returned to. If you are at the stage of publishing your first release, the sequence of requirements you are working through is covered in Google Play publishing requirements for new developer accounts, and the testing side of the same preparation is in how to set up closed testing in Play Console.

How do you keep the form accurate after launch?

By treating it as a living document rather than a launch checkbox, because the form describes behaviour that keeps changing.

Google's guidance is that you alone are responsible for making complete and accurate declarations, and that the review process is not designed to verify the accuracy and completeness of what you submit. Read together, those two statements mean nobody is going to tell you when your declaration has drifted out of date. The correction arrives as enforcement rather than as feedback.

Drift has a small number of predictable sources. Adding an SDK introduces data types you did not previously declare, which is the most common. Adding a permission or enabling an API that reads identifiers has the same effect. Introducing an account system brings the deletion questions into play for the first time. And changing an advertising or analytics integration can move data from the ephemeral category into collection or sharing, because building user profiles is never ephemeral.

The practical discipline is a short checklist attached to your release process: re-read the form whenever a dependency, permission, or account feature changes, and re-check it before each update rather than only at launch. Keep your SDK inventory current as part of that, since the inventory is what makes the re-check quick instead of a full re-audit.

One more habit is worth building early, which is to answer honestly even when the honest answer is less flattering. Declaring that data is not encrypted in transit, or that users cannot request deletion, is a real answer that appears in your store listing. That is a better outcome than a declaration that reads well and does not match the app, because the first is a known gap you can close deliberately and the second is a liability with a delayed trigger.

Frequently asked questions

Is the Data Safety form required for closed testing?

Yes. Google requires the form for all apps published on Google Play, explicitly including apps on closed, open, or production testing tracks. Only apps that are active exclusively on internal testing tracks are exempt, along with system services and private apps.

Do I need the Data Safety form if my app collects no data?

Yes. Every app must complete the form, including apps that collect nothing, and you must provide a privacy policy link. In that case the form and privacy policy state that no user data is collected or shared.

Do third-party SDKs have to be declared on the form?

Yes. Data transmitted off the device by libraries or SDKs counts as collection regardless of whether it goes to your server or a third party's. Check each provider's published data safety guidance rather than inferring from your own code, since SDK behaviour is not visible in your source.

What counts as ephemeral processing in the Data Safety form?

Data transmitted off device and used only in memory, retained no longer than necessary to service that specific real-time request. It must still be included in your form response, but it is not disclosed in the store listing. Building advertising or other user profiles cannot be treated as ephemeral.

What happens if my Data Safety declaration is wrong?

Incomplete or inconsistent answers block submission in Play Console. Separately, when Google becomes aware of a discrepancy between your app's behaviour and your declaration, it may take enforcement action. The review process is not designed to verify accuracy, and responsibility for the declaration sits with you.

Do I need to offer account deletion in my app?

If your app allows users to create an account from within the app, the User Data policy requires that they can also request deletion of that account, through both an in-app path and a web resource. Incomplete answers to the Data deletion questions block new submissions and app updates.

Sources

Everything in this guide is drawn from Google's own documentation for Play Console and Android developers, and the distinction between official policy and general advice is worth keeping in mind as you read. The scope of the requirement, including the rule that apps on closed, open, and production testing tracks must complete the form while internal-testing-only apps are exempt, the definition of collection covering libraries, SDKs and app-controlled webviews, the treatment of ephemeral and pseudonymous data, and the statement that Google's review does not verify accuracy all come from Google's Help Center article on providing information for the Data safety section, with the concrete permission and API indicators documented in the corresponding Android developer guidance on declaring data use. The account deletion requirement, including the in-app and web resource condition, the obligation to delete associated user data, and the rule that incomplete Data deletion answers block new submissions and app updates, comes from Google's Help Center article on understanding Google Play's app account deletion requirements, with the policy announcement that introduced the requirement available in the April 2023 policy announcement. Because Google revises these requirements and the form itself, verify the current wording on the linked pages before relying on any specific detail here, particularly if you are working to a deadline.

• Provide information for Google Play's Data safety section - Google Play Console Help
• Declare your app's data use - Android Developers
• Understanding Google Play's app account deletion requirements - Google Play Console Help
• Policy announcement: April 5, 2023 - Google Play Console Help
• Google Play Developer Program policies - Google Play Console Help