A deletion request just arrived. What now?

Publishing the deletion page is the part everyone writes about. What happens after someone uses it is the part that decides whether you are actually compliant — and it is a process question, not a hosting one.

Where should requests land?

Somewhere a human sees them within days, not an inbox you check when something breaks.

The failure mode is specific and common: a page collects requests into a mailbox nobody reads, or a form service whose notification emails go to spam. The user believes their request went through. Legally you are now in breach of a deadline you do not know is running.

Practical rules:

• Not a personal address you might abandon. Support mail from a store listing arrives in bursts — nothing for months, then a run of them.
• Somewhere with a notification you cannot miss. For a solo developer that is often a chat channel rather than email, precisely because email is where things go to be ignored.
• More than one route if you can. If one channel silently breaks, you want a second.
• Test it. Submit a request through your own public page and confirm it reaches you. Do it again after any change to the page.

How long do you have?

If any of your users are in the EU or UK, the GDPR clock applies. Article 12(3) requires a response without undue delay and in any event within one month of receipt. For genuinely complex requests the period can be extended by two further months — but you must tell the person about the extension within the first month.

Two details developers routinely miss:

• “We have received your request” is not a response. Where you act on an erasure request, you confirm that erasure was carried out and what was deleted.
• If you refuse, you still have to reply — within the month, with your reasons, and telling the person they can complain to a supervisory authority or seek a judicial remedy.

Other regimes have their own clocks. If you have users in California, Brazil or elsewhere with similar laws, check the one that applies rather than assuming a month covers you everywhere.

What actually has to be deleted?

The account and the personal data behind it — and not only in your own database:

Where the data is	What you do
Your primary database	Delete, not soft-delete-and-forget
Backups	Say honestly in your policy how long backups persist and that they expire
Analytics / crash reporting	Use the vendor’s own deletion API where there is one
Email or CRM tools	Remove from lists you exported them to
Processors and sub-processors	Ask them to delete, and follow up — this is your obligation, not theirs
Logs	Decide a retention window and apply it

If your app relies on service providers to process user data, deleting it from your own servers is only half the job — you also have to ask the provider to do the same.

What may you keep?

Some things, for stated reasons. The common ones:

• Billing and tax records, which are usually retained by law for years.
• A record of the deletion itself — you need to be able to show it happened.
• Fraud or abuse markers, where you have a legitimate reason and have said so.
• Anonymised aggregates, if they genuinely cannot be re-identified.

Say which of these apply in your privacy policy, with the retention period, before anyone asks. Deciding it at the moment of the request is how people end up either over-promising or improvising.

What should the reply say?

Short, specific, dated:

We received your deletion request on 3 March. Your account and the personal data associated with it have been deleted. We have retained your invoices, which we are required to keep for seven years for tax purposes, and a record of this request. Nothing else remains.

That is a compliant response. “Done ✅” is not, because it confirms nothing.

Keep the record

Whatever the volume, keep a log: who asked, when, what you deleted, what you retained and why, when you replied. “We deleted it” is an assertion; a dated list is evidence — and evidence is what a regulator asks for, long after you have forgotten the request.

This is also the reason to keep requests somewhere structured rather than as loose emails. A folder of replies is not a log.

One caveat about everything above

This page describes a process, not your legal obligations. Which regimes apply to you depends on where your users are and what your app does, the deadlines and exemptions differ between them, and the retention periods in the example reply are illustrative rather than a figure you can copy. If you handle deletion requests at any volume, or your app touches health data, finance or children, the hour of a lawyer’s time that turns this into your own written procedure is worth it.

What AppFoyer does here

We host the page, store the request as your audit trail, and notify you on the channels you set up — email on any plan, Telegram or Slack on a paid one, through our own bot and app rather than credentials of yours. The dashboard keeps each request with a done → archive → delete workflow, so the log above is something you already have rather than something you build.

Two things we do not do, and will not claim: we never contact the end user, and we never delete anything in your systems — we have no access to them. The deletion, the reply and the retention decisions are yours. That is what the requirement actually asks of you, and no hosted page can stand in for it.

The authoritative sources

• Understanding Google Play’s app account deletion requirements — Google Play Help
• Right to erasure — the UK Information Commissioner’s Office, a regulator’s own guidance
• GDPR Article 12 and Article 17 — the deadline and the right itself

---