A privacy policy is a hard requirement for publishing on Google Play, and getting it right is both a policy obligation and a matter of user trust. Google requires a valid, accessible privacy policy for essentially every app, and it must accurately reflect how your app collects, uses, and shares data. Because any app from a new personal account must also complete a closed test with at least 12 testers opted in for 14 continuous days before requesting production access, the smart move is to prepare your privacy policy during that mandatory window so it is ready and accurate when you launch.
This guide explains what your privacy policy must contain, how it relates to the Data safety form (they must agree), where developers commonly get it wrong, and how to use your closed-testing period to produce a policy you can stand behind. Treating the privacy policy as real compliance work rather than a copied-and-pasted afterthought is what keeps your launch from stalling on an avoidable rejection.
Why a privacy policy is required
Google Play policy requires a privacy policy for any app that handles user or device data, which in practice means almost every app — even simple ones typically collect some identifier or diagnostic data through their code or SDKs. The policy must be provided as a URL in the Play Console and be publicly accessible, and it must genuinely describe your data practices. Missing, inaccessible, or inaccurate privacy policies are a common cause of rejection, so this is not a box to tick carelessly. See Google's user data policy and the Data safety form guide.
Beyond Google's rules, many jurisdictions legally require a privacy policy if you handle personal data — GDPR in Europe, various national laws, children's protections, and more. So your privacy policy serves both the Play Store requirement and your legal obligations, which is why accuracy matters on two fronts at once. See GDPR compliance.
What your privacy policy must include
A compliant privacy policy should clearly state what data you collect, why you collect it, how you use it, whether and with whom you share it, how you secure it, how long you retain it, and how users can request access or deletion. It should identify you as the data controller, provide contact information, and cover data collected by third-party SDKs, not just your own code. Vague or generic policies that do not match your actual app are a red flag. Write it to describe your real practices specifically. See this guide.
| Section | What it covers |
|---|---|
| Data collected | Every data type, including via SDKs |
| Purpose | Why each data type is collected |
| Sharing | Third parties and reasons |
| Security & retention | How data is protected and how long kept |
| User rights | Access, deletion, contact |
Cover children's data specifically if your app targets or appeals to kids. See COPPA and kids apps.
How it relates to the Data safety form
Your privacy policy and your Data safety form must tell the same story. The Data safety form is Google's structured declaration shown on your listing, while the privacy policy is your fuller narrative document — and Google checks them for consistency. If your form says you collect location but your policy is silent, or your policy mentions sharing data your form omits, you invite scrutiny and possible rejection. Prepare both together so they describe the same data types, purposes, and sharing. See the Data safety form guide.
The practical workflow is to audit what your app actually collects (including SDKs) once, then use that single source of truth to fill in both the Data safety form and the privacy policy. Doing it this way guarantees consistency and saves you from reconciling two documents written independently. See analytics and SDK testing.
Do not forget third-party SDKs
The most common reason a privacy policy is inaccurate is that developers describe only their own data collection and forget the SDKs they embed. Analytics, ads, crash reporting, attribution, and social-login SDKs frequently collect identifiers, usage data, or location and may share it with third parties — all of which your privacy policy must disclose. During your window, audit every dependency: list each SDK, determine what it collects and shares, and reflect it in your policy. Undeclared SDK behavior is exactly the kind of mismatch that gets apps flagged. See SDK testing.
This audit does double duty, feeding both your privacy policy and your Data safety form. It is the single most valuable piece of privacy work you can do, because it turns guesswork into an accurate declaration grounded in what your app truly does. See ad policy compliance.
Hosting and accessibility
Your privacy policy must live at a stable, publicly accessible URL that you enter in the Play Console, and ideally is also linked from within your app. It should remain reachable — a dead link is treated as a missing policy — so host it somewhere reliable rather than a temporary page. Many developers use a dedicated page on their website or a free hosting option; what matters is that it stays live and loads for anyone, including Google's reviewers. See the Play Console beginner guide.
Keep the URL consistent so you do not have to update it repeatedly, and make sure the page is the policy itself, not a login-gated or region-blocked page. Accessibility problems are an easy, avoidable cause of rejection that a quick check during your window eliminates.
Preparing the policy during your window
Because the 14-day closed test runs regardless, use the window to write and finalize your privacy policy properly. You are already examining your app's behavior for testing, so it is the natural time to audit data flows and translate them into an accurate policy. Have the policy live and linked in the Play Console before you request production access, so it is one less thing gating your launch. Developers who leave the policy to launch day often scramble or copy a generic template that does not match their app. See the first-app checklist.
The window also lets you verify your policy against real behavior: as testers use the app, confirm the data flows you described actually match what happens. This empirical check produces a defensible policy grounded in reality rather than assumptions. See the testing checklist.
Common privacy policy mistakes
The frequent mistakes are predictable: using a generic template that does not describe your actual app, omitting SDK data collection, contradicting your Data safety form, hosting the policy at an unstable or inaccessible URL, and failing to cover children's or sensitive data when relevant. Each is easy to avoid with a careful audit and a policy written specifically for your app. Reviewers and users can tell the difference between a real policy and a copied one, and only the real one keeps you compliant. See app not eligible for production access.
Another mistake is treating the policy as a one-time artifact. It must stay accurate as your app changes, so build the habit of updating it whenever you add data collection or a new SDK. A policy that drifts out of date reintroduces exactly the mismatches you worked to avoid.
Legal considerations beyond Google
Depending on where your users are, laws like GDPR, CCPA, and children's protections impose specific requirements — consent mechanisms, data-subject rights, lawful bases for processing, and more — that your privacy policy must reflect. Google's requirement is a floor, not a ceiling; meeting it does not automatically make you legally compliant everywhere you distribute. If you serve regulated markets, ensure your policy and consent flows meet those laws, and consider professional advice for anything complex or high-stakes. See GDPR compliance and testing requirements by country.
Use your window to verify that region-specific mechanisms actually work — for example, that a consent prompt appears for European users if required. Aligning your policy with the laws of your target markets, not just Google's rules, is what keeps you safe both on the platform and legally. See COPPA and kids apps.
Keeping the policy current after launch
A privacy policy is living documentation. After launch, update it whenever you add a feature or SDK that collects new data, change how you handle data, or enter a new market with different requirements. Keep it consistent with your Data safety form at all times, since both must continue to match your app. An app whose policy keeps pace with its behavior stays compliant; one whose policy freezes at launch drifts into mismatch as the app evolves. See updating after release and post-launch monitoring.
Build the audit-and-update habit now during your window, and maintaining an accurate policy becomes routine rather than a periodic crisis. Transparency about data, kept current, is a genuine trust asset with your users as much as a compliance requirement.
Writing a policy that actually fits your app
The difference between a policy that passes and one that gets flagged is specificity. A policy that reads like a generic template — listing every conceivable data type "in case" and describing practices you do not have — is nearly as problematic as one that omits real collection, because it fails to describe your actual app. Write from your audit: state the specific data your app and its SDKs collect, the concrete purposes, the real third parties you share with, and the genuine choices users have. Reviewers and privacy-conscious users can tell the difference, and only an accurate, specific policy holds up.
Structure it so a reader can quickly find what data you take and why, then the details of sharing, security, retention, and their rights. Plain language beats legalese for user trust, while still covering the required ground. A policy written specifically for your app, grounded in what it truly does, satisfies Google, informs users, and aligns cleanly with your Data safety form. See the Play Console beginner guide.
Key takeaways
- A valid, accessible privacy policy is required for essentially every Google Play app.
- It must accurately describe your data practices, including data collected by third-party SDKs.
- It must agree with your Data safety form, which Google checks for consistency.
- Prepare and verify it during your closed-testing window so it is ready and accurate at launch.
- Keep it current as your app and data practices change.
Frequently asked questions
Does my app really need a privacy policy?
Almost certainly. Google requires one for any app handling user or device data, which nearly all apps do through their code or SDKs.
Must my privacy policy match my Data safety form?
Yes. Google checks them for consistency, so the same data types, purposes, and sharing should appear in both to avoid rejection.
Do I have to disclose data collected by SDKs?
Yes. Your policy must cover data collected or shared by third-party SDKs, not just your own code, so audit every dependency.
Where should I host my privacy policy?
At a stable, publicly accessible URL you enter in the Play Console. A dead or gated link is treated as a missing policy.
Can I use a generic template?
Only as a starting point. It must be customized to describe your app's actual data practices, or it risks being inaccurate and rejected.
When should I prepare it?
During your closed-testing window, alongside your Data safety form, so it is live, accurate, and verified against real behavior before launch.
Do I need to update it later?
Yes. Update it whenever you add data collection or a new SDK, keeping it accurate and consistent with your Data safety form.
Does meeting Google's requirement make me legally compliant?
Not necessarily. Google's rule is a floor; laws like GDPR or CCPA may add requirements. Ensure your policy meets the laws of your target markets too.
What most often makes a privacy policy inaccurate?
Forgetting third-party SDK data collection. Developers describe only their own code and omit what analytics, ad, or crash SDKs collect and share, which is exactly the kind of mismatch Google flags.
Should the policy be linked inside the app too?
Ideally yes. Provide the URL in the Play Console and also link it from within your app so users can reach it easily at any time.