The account deletion URL Google Play asks for
What the account-deletion requirement actually asks of you, what the page has to let a user do, and the mistakes that get a submission sent back.
Checked 15 September 2026. Store policies change, sometimes without notice. Everything below links to the official documentation, and that page — not this one — is the authority. If the two disagree, the store is right.
If your app lets people create an account, Google Play asks you for a web URL where a user can request that their account and data be deleted — and asks that they can do it without installing the app or signing in. You enter that URL in Play Console under App content → Data deletion.
Two things are being asked for here, and they are easy to confuse:
- A public page where a request can be submitted.
- Actually deleting the data in your own systems when a request arrives.
The first is a hosting problem. The second is yours alone, and no service can do it for you — anyone who says otherwise does not have access to your database.
What the page has to let a user do
The requirement is written from the user’s side, so read it from there. Someone who has uninstalled your app, forgotten their password, or never had one, should still be able to reach the page and ask you to delete their account.
That rules out some common setups:
- A page behind a login. If the user has to sign in to ask for deletion, the people most likely to need it cannot use it.
- A page inside the app. The requirement is for a web URL, reachable from the store listing.
- A URL that 404s. This is the one that actually gets caught, because it is trivial to check.
The page should say what data is deleted, what is kept and for how long (billing records often must be kept by law), and how long deletion takes.
The part people get wrong: receiving the request
A page that displays a form is not enough on its own — the request has to reach you.
This is where a static host breaks down. GitHub Pages, Netlify’s free tier, a bucket behind a CDN: they serve files, they cannot receive a submission. So the usual DIY route ends in one of three places:
- an email address printed on the page, and nothing to stop it being scraped;
- a third-party form service, which now sees your users’ email addresses;
- a small server you have to keep running for what might be two requests a year.
Whichever you pick, decide it deliberately. A deletion page that quietly drops requests is worse than not having one: you are telling a user their request was received.
Keep a record
Whatever you build, keep a log of requests: the address, the date, what you did about it. If a regulator or a store ever asks, “we deleted it” is an assertion, and a dated list is evidence.
What AppFoyer does here
We host the page and relay the request. A user submits it, we store it as your audit trail, and we notify you by email, Telegram or Slack. You do the deletion in your own systems — we have no access to them, and we never claim to.
That page stays online even if you stop paying us, because your users had no part in that.
The authoritative source
- Provide information about data deletion — Google Play Help. Read this before you submit; it is the page that decides, not this one.
Do this in a few minutes instead
AppFoyer hosts the pages this guide is about — privacy policy, terms, support, account
deletion and app-ads.txt — on their own
subdomain, with no domain or server of your own. One app is free, and nothing a store
requires is ever behind a paywall.