"Your app does not comply with the User Data policy" is one of the most-seen rejection messages in Play Console, and a surprising share of the time the cause is mundane: the privacy policy link does not work the way Google needs it to.
What Google actually checks
Reviewers verify a small, mechanical list. Your policy must:
- Live at a publicly accessible URL — no login wall, no interstitial, no geo-block.
- Be non-editable by visitors. A Google Doc with edit access, or a Notion page in edit mode, gets rejected.
- Be linked both in the Play Console store listing and reachable from inside the app itself.
- Name your app explicitly. A generic policy that never mentions the app it covers is treated as unrelated.
- Describe the data you actually collect, how it is used, who it is shared with, and how users can request deletion.
The four failures that cause most rejections
1. The URL is not reachable
A trailing slash, an expired hosting trial, a page that only renders after JavaScript loads, or an http:// link that redirects oddly. Open your policy URL in a private browsing window on mobile data. If it does not render immediately for a logged-out stranger, it fails.
2. The policy contradicts the Data Safety form
This is the subtle one. If your Data Safety declaration says you collect approximate location and device identifiers, but your policy says "we do not collect any personal data", that mismatch is a policy violation on its own. The two documents are cross-checked.
Work in one direction: list every SDK in your build, derive what each collects, write the policy from that list, and then fill the Data Safety form from the same list.
3. SDKs you forgot you shipped
Your app may collect data you never wrote code for. Common culprits:
- Google AdMob — advertising ID, approximate location, device info.
- Firebase Analytics / Crashlytics — app interactions, crash logs, device identifiers.
- Facebook / Meta SDK — device and usage data.
- Any attribution or push SDK — tokens count as identifiers.
Each of these must appear in both your policy and your Data Safety answers.
4. Children's policy obligations
If your app targets children or is in the Families programme, the bar rises: additional disclosures, restrictions on advertising IDs, and compliance with COPPA and, where relevant, GDPR-K. Declaring a children's audience and then shipping a generic adult policy is a direct rejection.
Fixing it without waiting another review cycle
- Generate a policy that names your app, your company and your contact email, and that lists the exact data types your SDKs collect.
- Host it at a stable public URL. A static page on your own domain is best; a free hosting subdomain that may expire is a liability.
- Add an in-app link — usually in Settings or the About screen.
- Re-open the Data Safety form and reconcile every answer against the policy line by line.
- Resubmit, and in the appeal note state plainly what you changed.
Our privacy policy generator builds the document from your SDK list so the two artefacts agree by construction, which is the part developers most often get wrong.
A generated policy is a solid starting point and satisfies Play's structural requirements. It is not legal advice. If you handle health, financial or children's data, have a lawyer review it.