Google Play Data Safety Rejection: The Form Is Wrong, Not the App

A Data Safety rejection is unusual among Google Play rejections because the app is almost never the problem. The form is. More precisely: the gap between what the form says your app collects and what the reviewer can observe it actually collecting.

That gap usually exists because nobody on the team knows the full answer. The app's own code collects three things; the analytics SDK collects nine; the ad SDK collects an identifier the developer has never looked at; the crash reporter uploads device state. The form asks one person to declare all of it.

The form is a declaration, not a setting

This is the first thing to internalise. Filling in the Data Safety section does not change your app's behaviour, restrict any SDK, or turn anything off. It is a sworn statement about behaviour that already exists, published verbatim on your store listing.

Two consequences follow. First, an inaccurate form is a policy violation regardless of intent — "we did not know the SDK did that" is an explanation, not a defence. Second, you cannot fix a mismatch by editing the form alone unless the form was genuinely wrong; if the app really does collect the thing, the accurate declaration is the one that includes it.

The mismatch that causes almost every rejection

Reviewers compare your declaration against observable behaviour: network traffic during review, the SDKs detected in the bundle, permissions requested, and the privacy policy you linked.

The rejection notice will usually name the specific data type it believes is undeclared — device identifiers, approximate location, app activity, installed apps. That name is the most useful thing in the notice. It tells you which subsystem to audit.

Frequent shapes:

• The form says no data is collected, while an analytics or ad SDK is present in the build. A build containing any mainstream ads or attribution SDK almost certainly collects at least a device or advertising identifier.
• Data is declared as collected but not as shared, while an SDK transmits it to a third party. Collection and sharing are separate declarations and the distinction is where a lot of forms go wrong.
• The privacy policy contradicts the form — commonly because the policy was written later, or by someone else, or covers the website rather than the app.
• The declared purpose is narrower than the actual use: "app functionality" declared for an identifier that is in fact used for advertising or personalisation.

Finding out what your app actually collects

Three methods, in increasing order of reliability:

Read the SDK documentation. Every mainstream analytics, attribution, ad, and crash-reporting SDK publishes a data-collection disclosure, often with a Play-form-shaped mapping table. This is the fastest route and covers most cases. Note the default behaviour specifically — many SDKs collect more unless explicitly configured not to.

Inventory the bundle. List every third-party dependency in the build, including transitive ones pulled in by another SDK. Attribution and mediation SDKs frequently bundle others. The dependency you did not add directly still counts as yours.

Observe the traffic. Run the app against a proxy on a clean device and watch what actually leaves it on first launch, after consent, and during normal use. This is the only method that catches an SDK behaving differently from its documentation, and it is the method that matches what the reviewer does.

Do all three for the first submission after a rejection. The cost is a day; the cost of a second rejection on the same cause is much higher, because repeated inaccuracy on the same point starts looking deliberate.

The declarations that are routinely wrong

Optional versus required. Data is "optional" only if the app genuinely functions when the user declines. If declining blocks the feature, it is required.

Collected versus shared. Sending data to a third-party SDK that processes it for its own purposes is sharing. Sending it to a service acting purely as your processor may not be. Get this distinction right per SDK rather than applying one answer to all of them.

Ephemeral processing. Data processed in memory and never stored off-device can be excluded — but only if it truly is never transmitted or retained. This exclusion is claimed far more often than it applies.

Account deletion. If the app supports account creation, you must offer a route to request deletion, including a web route that does not require the app. A missing or app-only deletion path is its own rejection cause and frequently arrives bundled with a Data Safety rejection.

Encryption in transit. Declaring this requires it to be true for all transmitted data, including whatever your third-party SDKs send.

Ad and attribution SDKs are the usual culprits

If your app monetises through advertising or measures acquisition, the identifier question is unavoidable. Advertising IDs, install referrer data, and device signals used for attribution are collected data, are typically shared with the SDK vendor, and their real purpose is advertising or analytics rather than app functionality.

Declaring these accurately does not hurt you. The listing shows a data-collection summary that most users never open, and the vast majority of installed apps declare the same categories. What does hurt is a clean-looking declaration that a reviewer can disprove in ten minutes of traffic inspection.

Fixing the form versus fixing the app

Once you know the true behaviour, you have two honest options:

Declare it accurately. Usually the right answer. Update the form, align the privacy policy so the two documents say the same thing, and resubmit.

Change what the app collects. Appropriate when the collection was unintentional or unnecessary — an SDK left in from an experiment, a permission requested but unused, a default configuration nobody reviewed. Remove or reconfigure it, verify the traffic stops, then declare the new behaviour.

What is not an option is declaring the behaviour you intend to have later. The form describes the build you are submitting.

Resubmission

Update the Data Safety section, confirm the privacy policy matches, and submit the build. If the rejection cited a specific data type, make sure your resubmission visibly addresses that type — either it is now declared, or it is genuinely no longer collected.

The general reading-and-resubmission mechanics are the same as any other rejection; how to read a Google Play rejection reason and resubmit covers the shared parts. Two neighbouring policy faces come up often in the same audits: what the deceptive behaviour policy actually covers and the four violations behind a spam removal.

Frequently asked questions

Why was my app rejected for Data Safety when I do not collect any data? Almost always because an SDK in the build does. Analytics, ads, attribution, and crash reporting SDKs collect data on your behalf, and their collection is yours to declare.

Does declaring more data collection hurt installs? There is no meaningful evidence that it does. The data-collection summary sits behind a tap on the listing, and nearly every comparable app declares similar categories.

Is the advertising ID considered collected data? Yes, when it leaves the device. It is normally declared as a device identifier, usually shared with the SDK vendor, and usually for advertising or analytics purposes rather than app functionality.

Do I need a separate privacy policy for the app? You need one that accurately describes the app. A website policy that never mentions the app's SDKs or identifiers will contradict your form, and reviewers do read it.

Can I fix this by only editing the form, without a new build? Sometimes — if the form was inaccurate and the app's behaviour is acceptable, a corrected declaration plus an aligned privacy policy may be enough. If the fix requires removing an SDK, you need a new build.

The short version

Data Safety rejections are declaration mismatches, not code defects. The notice names the data type it thinks you missed; audit that subsystem three ways — SDK docs, dependency inventory, and observed traffic — then either declare the behaviour accurately or change the app so the accurate declaration is smaller. Align the privacy policy with the form, because reviewers compare them. And do not claim ephemeral processing or in-transit encryption unless it is true of every SDK in the build.