Google Play — Data safety form mismatch
Google compared your declaration against what the app actually transmits, and they disagree. SDKs are the usual reason — analytics and ad libraries collect more than developers expect.
What the rejection usually says
Your Data safety section does not accurately reflect your app's data collection.
We found that your app collects data types not declared in your Data safety form.
Wording varies between reviewers; the substance does not.
Why it gets triggered
- An analytics or advertising SDK collecting identifiers you did not declare.
- A crash reporter sending device or user information.
- Declaring data as not shared while a third party receives it.
- The form not updated after adding a dependency.
How to fix it
1.Inventory every SDK
List each dependency and what it transmits. Most vendors publish a data-safety guide with the exact rows to tick.
2.Verify with traffic, not assumptions
Inspect network calls from a real device session and reconcile them against the form.
3.Declare sharing honestly
Data sent to a third party for their own use is sharing, even when you never see it.
A reply you can adapt
Short, specific, and stating what changed — reviewers read hundreds of these.
Thank you. We audited every SDK and network call, and have updated the Data safety form to declare the identifiers collected by our analytics provider and the fact they are shared with it.
AppSubmit does this for your app, specifically
Paste the rejection and the decoder reads it against your actual listing, build and release history — then writes the fix plan and drafts the reply. It also watches your submissions, so the next rejection reaches you as a notification rather than a surprise.
Decode a rejection free