Google Play account deletion requirement: the in-app path, the web URL, and the data-only option

If your app lets a user create an account, Play requires two ways to delete it: one inside the app, and one on the open web that works without installing the app at all. Most rejections here are the second. The in-app button exists, the web URL does not, or it points at a privacy policy that never mentions deletion.

How it is worded

Often surfaced as a Data safety issue on the App content page, and often as a policy email:

"Your app allows for app account creation but does not provide an in-app path and a web resource for users to request account and data deletion."

The wording tells you which half failed. A finding about the URL is a website fix, not an app release.

What it means

Both routes are required. In the policy's own words, an app that allows account creation must "provide users with an in-app path to delete their app accounts and associated data" and "provide a web link resource where users can request app account deletion and associated data deletion".

The web link has explicit quality requirements. It must be "functional (for example, loads without error)", "relevant in scope (for example, the pathway to request account deletion should be prominently featured and easily discoverable on the page)", and it must "reference the app or developer name (that is, as it appears on your store listing in Google Play)".

The point most developers miss is reachability. The user "must be able to request deletion of their account through the pathway" without "sending the user back to the app and requiring them to re-download it". A URL saying "open the app and go to Settings" fails. It has to be a route, not a signpost.

The distinction that catches people

Deleting the account removes the account itself and, per the policy, "must also delete the user data associated with that app account". This is the full exit.

Deleting some data is narrower: wipe my history, remove my uploads, keep the account. The policy expects this to be available too, and treating it as optional causes a second rejection after the first fix. The two need different confirmation copy: "Delete my data" should not lose the login, and "Delete my account" should say what disappears before confirming.

Retention is allowed where you have a real reason. The policy accepts that "your app may need to retain certain data for legitimate reasons such as security, fraud prevention or regulatory compliance", and requires you to "clearly inform users". Invoice records kept for tax law are fine. Keeping the whole profile because deleting it is hard is not.

Why it happens

• There is no web URL at all. The most common cause. The in-app flow was built, the Data safety form was filled in months earlier, and the URL field was empty or pointed at the homepage.
• The URL points at a privacy policy that describes data rights in general terms and never gives a way to request deletion, or at a generic company support page that never names the app.
• The page requires a login you cannot complete on the web, because your product has no web app. A form collecting an email address and a request is enough.
• The in-app path is buried, three levels into Settings under a heading that does not say "delete", or it is a support ticket in disguise. "Email us and we will delete your account" is not an in-app path.
• Google Sign-In only. Because the identity is Google's, developers assume the account is not theirs. Your app record is yours. Any signup, social logins included, counts as account creation.

How to fix it

1. Build the web page first, because it is the half that usually fails and needs no app release. One page at a stable URL, titled with the app name, with a short form: email address, optional account identifier, a choice between "delete my account and all data" and "delete specific data", submit. No login gate.
2. Make it findable and make it work. Link it from your footer and privacy policy, and route the form to a monitored inbox with a documented turnaround. A form that goes nowhere is worse than no form.
3. Add or promote the in-app path. Settings > Account > Delete account, one level deep, with the word "delete" in the visible label. A confirmation screen listing what is removed and what is retained, then one destructive action.
4. Add the data-only option alongside it, where your app holds data a user might want removed without closing the account.
5. Delete server-side, not just locally. Signing out and clearing the local database is not deletion. If your backend keeps the row, the policy is not met.
6. State your retention in the confirmation flow and your privacy policy: what you keep, for how long, under what obligation.
7. Enter the URL in the Data safety form on the App content page in Play Console and resubmit that form. A form submission, not an app release, and frequently the whole fix.
8. Test the URL from a browser with no session, on a phone, on a different network. Reviewers open it cold.

What to send

Account deletion is now available by both routes. In-app: Settings > Account > Delete account, which deletes the account and all associated data server-side, with a separate "Delete my data" option that clears content while keeping the account. On the web: [URL], a public page titled with the app name, reachable without login, with the request form as the primary element. Retained data is limited to [billing records] for [period], as stated on the page and in our privacy policy. The URL has been submitted in the Data safety form.

Appeal, or fix and resubmit?

Fix and resubmit. The fix is in your control and usually takes hours, and an appeal cannot conjure a URL that does not exist.

Appeal only if you genuinely have no account creation and the requirement was applied in error. That case exists: a local-only profile, or an app authenticating against an employer's identity provider where you create no account record. Say where the identity lives, that your app stores no account of its own, and how a reviewer can verify it.

Do not appeal on the grounds that users can email you. The policy names two mechanisms and email is neither.

If you also ship on iOS, the same work satisfies Apple's requirement under App Store Review Guideline 5.1.1(v), with one difference: Apple's rule is about the in-app path, while Play also demands the web URL. Build both together and you clear both stores.

AppSubmit checks that the deletion URL loads, returns a 200, and mentions the app name, before you send the Data safety form. It cannot tell you whether anyone reads the form on the other end, and neither can a reviewer.