Fix this class once, properly: inventory every SDK, map its data behavior from the Play SDK Index and the vendor's own disclosure, then write the form and the policy from that inventory — not the other way around. Account deletion (in-app path + web link + declared URL) is part of the same paperwork chain.
Got the actual message? Paste it into the free rejection decoder — it matches your rejection against documented store rules and returns the fix steps, the resubmission checklist, and a reply draft. Three free decodes, no account.
User Data Policy — Data Safety Section — Data Safety Section Inaccurate or Inconsistent
Your Data safety declaration doesn't match what the app actually does — most often an ad, analytics, or crash-reporting SDK collecting data (advertising ID, device IDs, app interactions) that the form says you don't collect, or a form that contradicts your privacy policy. Google's position: you are responsible for complete and accurate declarations, and its review is not designed to verify them — a wrong form can pass review and still be enforced later.
Severity: blocker · Decoder confidence for this class: A (see the honesty note below)
The fix
- Read the rejection carefully: Google names the section/data type that failed. Start there.
- Inventory every SDK in the build and map its data collection/sharing from the Play SDK Index and the vendor's own Data safety guidance (AdMob, Firebase, etc.).
- Correct the Data safety form (App content > Data safety): every collected/shared data type, purposes, and whether collection is required or optional — 'shared' includes transfers to SDK providers.
- Make the privacy policy and the form tell the same story, in the same taxonomy.
- Update all active release tracks (production and testing) — Google scans older builds too.
Resubmission checklist
- Flagged data type corrected in the form
- Full SDK audit completed, not just the flagged item
- Privacy policy consistent with the form
- All active tracks updated
Reply draft
What the decoder can diagnose here: The three directions a mismatch can run: collecting something the form omits; declaring something the app doesn't do; or form vs privacy policy disagreeing. Google's notice usually names the data type (commonly 'Device or other IDs'). What it cannot: Each SDK's true data behavior from the notice alone — map it from the Google Play SDK Index and each provider's published data disclosure, then audit the manifest and SDK list line by line.
Rule text: “When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action... Developers are responsible for making complete and accurate declarations in the Data safety section.” — Google Play User Data policy / Play Console Help, 'Provide information for Google Play's Data safety section', retrieved 2026-10-23
User Data Policy — Privacy Policy — Privacy Policy Missing, Dead, or Non-Disclosing
Your app accesses personal and sensitive user data but the privacy-policy chain is broken: no policy URL in Play Console, a URL that doesn't load, a policy that doesn't disclose what the app actually does, or missing in-app prominent disclosure and consent before collecting sensitive data. Every app on Play must complete the Data safety form and provide a privacy policy link — including apps that collect nothing.
Severity: blocker · Decoder confidence for this class: A (see the honesty note below)
The fix
- Post a privacy policy at a stable, publicly accessible URL (no login, no geoblocking) and enter it in Play Console (App content > Privacy policy).
- Cover in the policy: data collected (including via SDKs), purposes, sharing, retention, deletion, and contact details.
- Add in-app prominent disclosure and obtain consent before collecting personal/sensitive data where the User Data policy requires it — not buried in a settings page after collection starts.
- Verify the URL loads from a clean browser session before resubmitting.
Resubmission checklist
- Privacy policy URL live and set in Play Console
- Policy specific to the app's actual practices
- In-app prominent disclosure + consent where required
- Data safety form consistent with the policy
Reply draft
What the decoder can diagnose here: Which link in the chain failed (missing URL, dead URL, non-specific policy, missing in-app disclosure) from Google's wording. What it cannot: Whether a generic generator policy will survive scrutiny — policies that don't name your app's actual data practices are the mismatch source in the Data safety class as well. Write the policy from your SDK inventory, not from a template.
Rule text: “All developers that have an app published on Google Play must complete the Data safety form and provide a link to their privacy policy, including apps that do not collect user data.” — Google Play User Data policy / Play Console Help (Data safety section), retrieved 2026-10-23
User Data Policy — Account Deletion — Account and Data Deletion Requirements
Your app lets users create an account but doesn't give them a working way to delete the account and its data the way Play requires: an in-app deletion path and a web-based deletion option, with the deletion URL declared in the Data safety section and referenced in your privacy policy. All three must point at the same, working mechanism.
Severity: major · Decoder confidence for this class: A (see the honesty note below)
The fix
- Add an in-app account deletion path (e.g., Settings > Account > Delete Account) that deletes or initiates deletion of the account and data.
- Provide a web page where users can request account/data deletion without the app, publicly accessible without login.
- Enter the same deletion URL in the Data safety section and reference it in the privacy policy.
- Test the web link from a logged-out browser before resubmitting.
Resubmission checklist
- In-app deletion path works
- Web deletion page live without login
- Same URL in Data safety form and privacy policy
Reply draft
What the decoder can diagnose here: Which leg is missing: in-app path, web link, Data safety declaration, or consistency among them (the URL in the form must match the one in the policy). What it cannot: Your own retention obligations (legal/financial records) — deletion must cover the account and associated data subject to legitimate retention, and the exceptions belong in the policy text, not as a reason to skip the mechanism.
Rule text: “Apps that allow users to create an account must provide a way for users to request account and data deletion, both in-app and via a web resource declared in the Data safety section.” — Google Play User Data policy / Account deletion requirements (Play Console Help), retrieved 2026-10-23
Related guides
- Rejection decoder — Google Play mode included
- Google Play Pre-Flight — the checks and the enforcement ladder
- App Store Pre-Flight — the other store's rulebook
- Apple 5.1.1 — the same failure, App Store edition
Sources
- Google Play User Data policy / Play Console Help, 'Provide information for Google Play's Data safety section', retrieved 2026-10-23
- Google Play User Data policy / Play Console Help (Data safety section), retrieved 2026-10-23
- Google Play User Data policy / Account deletion requirements (Play Console Help), retrieved 2026-10-23
Last updated October 23, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.
Decode your rejection — free
The decoder covers 41 documented rejection patterns across the App Store and Google Play, grounded in the stores' own published rules. Three free decodes; the $29 Pre-Flight Founding pre-sale unlocks unlimited decoding plus a full pre-flight check credit when the checker ships.
The decoder classifies and guides from the message you paste. It cannot see your app or your binary, and it never promises an approval outcome — that decision is always the store's.