Returning Visitors and Consent Expiry: When to Ask Again
Every consent choice has a shelf life, but nobody agrees on the date. Ask too often and visitors learn to smash the accept button to clear the interruption, which manufactures the appearance of consent while destroying its meaning. Ask too rarely and you are relying on a decision made about a different site, with different tools, in a different year of someones life. Somewhere between amnesia and harassment sits a defensible policy, and it needs to be a policy, written down with triggers, not whatever a platforms default happened to be at installation.
This guide covers how long choices are usually stored, the changes that should force a fresh ask regardless of the calendar, and how to design the return visit ask so a renewed choice is a real one.
How long a stored choice should live
Common practice and several regulators guidance cluster around six to twelve months for a stored consent choice, with advertising related consent strings often expiring sooner by design. The right number for a given site depends on how fast its tracking estate changes: a stable site with three tools can defend a longer period than a marketing heavy site adding vendors monthly. Whatever period you choose, the record itself should carry the timestamp and the banner version, so expiry is computed from evidence rather than guessed from a cookie whose own lifetime may differ. When in doubt, shorter with a painless re-ask beats longer with an argument.
Changes that should trigger a fresh ask early
Expiry is not only about time. Adding a new purpose, a materially new category of vendor, or a new kind of data use makes the old choice stale on the day it ships, because nobody consented to something that was not in front of them. The same logic applies after long inactivity in some guidance, and after a visitor clears storage or arrives on a new device, where there is simply no valid stored choice to rely on. Build these triggers into release processes: a change ticket that adds tracking should include the consent refresh decision as a required field, not an afterthought discovered by the next audit.
Re-asking without training blind acceptance
The return ask should acknowledge reality: a short line noting the visitor chose before, when, and what has changed since. Keep the previous categories visible as the starting point where the law allows storing them, so renewing is a review rather than a rebuild, and keep reject exactly as easy as it was the first time. Frequency caps matter beyond the formal expiry too. A site that re-asks on every visit because its storage is broken is not being cautious; it is conditioning visitors to click anything, and auditors who test with repeated visits notice the difference quickly.
What expiry means for data already collected
A consent choice expiring does not retroactively poison data collected while the choice was valid, but it does end the permission to keep collecting. When a renewed ask results in refusal, processing that depended on the old consent must stop going forward, and the new refusal, not the old acceptance, is the record that governs. Teams should test this path explicitly: expire a test record, decline on the return visit, and watch whether tags actually stay quiet. Expiry logic that lives only in the banner, while tags read a separate stale flag, is a common and entirely avoidable failure.
Related reading
These earlier guides cover connected questions in more depth: How Consent Records Hold Up in a Regulatory Audit, Top Cookiebot Alternatives Worth Switching To, and The Best OneTrust Alternatives for 2026.
Frequently asked questions
How long can we store a visitors consent choice?
Six to twelve months is the widely used range, supported by several regulators guidance. Shorter suits fast changing sites; longer needs a stable tracking estate to defend. The choice, its date, and the banner version should be stored so the expiry can be proven, not just asserted.
Must we ask again if we add a new tracking tool?
If the tool introduces a new purpose or a materially new category of processing, yes: the existing consent never covered it, so the honest move is a fresh ask describing the change. Adding a like for like replacement vendor inside an existing consented category is a greyer area your policy should address explicitly.
Why do some sites ask for consent on every visit?
Usually because the choice is not being stored correctly: cookies blocked, storage cleared by browsers quickly, or a banner misconfiguration. It is a defect, not diligence. Besides annoying visitors, it trains reflexive clicking, which undermines the validity of the acceptances it collects.
If a returning visitor declines after accepting last year, which choice counts?
The newest one. The earlier acceptance covered the period it was in force; the refusal governs from the moment it is made. Processing based on consent must stop, the refusal must be recorded with its own timestamp, and tags must honor it immediately.