Deletion usually has a cooling-off window during which the request can be withdrawn

What it is

After a deletion request is submitted, many products enter a stretch that is not yet executed and still withdrawable. A cooling-off window is that wait: the account may be marked pending deletion and sign-in may be limited, but the data remains, and the same identity can cancel. It is not the ordinary deletion timeline (how long execution takes) and not delay for the sake of hiding the entry. This entry is whether a wait exists, whether it can be withdrawn, and what state the account is in during it.

Why it happens

Deletion is high-consequence and often happens in emotion or by mis-tap. Immediate execution turns reversible regret into an irreversible blank. Cooling-off pushes irreversibility to the end of the window and buys one undo with time. If the window is invisible, people think deletion already finished and try to register the next day; if it cannot be withdrawn, the wait is only delayed harm. The in-window state must be chosen and stated: fully signed-in so they can withdraw, signed-in only to a withdraw page, or signed-out with a withdraw link in email. Retention marketing during the window is allowed; hiding the withdraw control or silently extending the window is not. When the window ends, real deletion should start on time, not another unexplained queue.

Studying it

Compare no window, a visible withdrawable window, and a window that is hard to withdraw: recovery from mistaken delete versus malicious delay.

Independent variables: visibility of window length, where withdraw lives, whether the product remains usable, whether the product can unilaterally extend the window. Dependent variables: successful withdraw after mistaken delete, treating cooling-off as already deleted, support because withdraw could not be found.

Labs told to “please delete” do not measure regret. Use a script that deletes then immediately regrets. Do not take “how many we kept” as the only success of cooling-off; that incentivizes hiding withdraw. Success is that people who regret can find withdraw, and people who mean it enter deletion when the window ends.

Where it stops holding

When regulation requires deletion without undue delay after the request, the window must be short, voluntary, and skippable with “do it now.” If the account is already taken over in a security incident, cooling-off may give the attacker a window; wait only after proving it is the person, or skip cooling-off on accounts marked stolen. People without sign-in (mailbox already lost) cannot withdraw in-app; a mail withdraw link must go out at submit. Cooling-off is not statutory retention: data in the window is still a live account, not an archive by law.

Applying it

• After submit, show a clear end time and “withdraw deletion”; send email with a withdraw link at the same time.
• Allow skipping the wait to execute now, with a second confirm.
• After withdraw inside the window, the account returns to its pre-deletion state without losing unexpired content; when the window ends, enter the deletion queue on time and change status from “pending deletion” to “deleting.”
• Verify: after submit, without leaving the page, people can name the deadline and tap withdraw, then sign in normally. Withdrawing via the mail link on another device should also work. Advance a test clock past the deadline; the account should enter deletion, not pending forever. Compare a version with withdraw hidden against the current one: uninvolved people should find withdraw within a minute.

Related

• Within the group: H6.14.1 Data that law requires to be kept must be explained separately · H6.14.2 Data already shared with third parties is not undone by this deletion · H6.14.4 Whether the old identifier can be re-registered after deletion needs an explicit policy
• Adjacent: H6.08 Account deletion · H3.08 Soft delete and trash
• Search terms: cooling-off · pending deletion · withdraw erasure request