How to fix “Invalid Data safety form” on Google Play

The message

The issue is listed as Invalid Data safety form. Developers who receive it usually see an explanation like this:

"We reviewed your app's Data safety form in Play Console and found discrepancies between it and how the app collects and shares user data."

The details often say Google detected user data transmitted off the device that you didn't declare. When Google can tell, it also names the SDK whose code appears to send the data. That detail is the fastest way to the cause.

Who must fill in the form

Every app published on Google Play must complete the Data safety form, with a few exceptions such as apps that are only on the internal testing track. Google is explicit that apps collecting nothing aren't exempt: "Even developers with apps that do not collect any user data must complete this form and provide a link to their privacy policy."

Collected vs shared

Most mistakes come from reading these two words loosely. Google defines them like this:

• Collected means transmitting data from your app off a user's device, including data sent by libraries, SDKs and webviews your app controls.
• Shared means transferring user data collected from your app to a third party, whether from your servers or on the device.

Data that is processed only in memory to answer a request and isn't stored, which Google calls ephemeral processing, doesn't have to be declared as collected. Google also lists cases that don't count as sharing, such as passing data to a service provider that processes it on your behalf. Check the Data safety help page before you rely on an exception.

Common causes

1. An SDK you forgot about. Ads, analytics, crash reporting and attribution SDKs send device IDs, app interactions, diagnostics and sometimes approximate location. Declaring "no data collected" while shipping one of them is the classic mismatch.
2. Device or other IDs left out. The advertising ID, Firebase installation IDs and similar identifiers count as collected data.
3. Crash logs and diagnostics left out. They leave the device, so they have to be declared.
4. An old build on another track. A release still active on a testing track can contain an SDK you have since removed.
5. Wrong security answers. Saying data is encrypted in transit when part of your traffic uses plain HTTP, or offering deletion you don't actually provide.

Fix checklist

1. List every SDK in your app, including those pulled in by plugins.
2. For each one, read the provider's Data safety guidance. Firebase, AdMob and most large SDKs publish what to declare.
3. Update the form under Policy and programs > App content > Data safety, declaring each data type as collected, shared or both, with its purposes.
4. Remove old builds containing SDKs you no longer use from all active tracks.
5. Update your privacy policy so it describes the same data and partners.
6. Submit the changes for review. If you believe the finding is wrong, explain why through the Policy status page.

The form and your privacy policy

The Data safety section is a summary for your store listing. Your privacy policy is the full explanation behind it. Google, and users, compare the two, so a policy that says "we collect nothing" next to a form that declares analytics data is a red flag.

Each time you add an SDK, update the form and the policy together. If your app really collects nothing, see what a no-data privacy policy should say.

Frequently asked questions