What should a cookie banner do when a shopper clears cookies mid-session?
Clearing cookies mid-session wipes the shopper's consent choice along with everything else. The banner has to treat the next pageview as a brand-new visitor, while the analytics stack has to survive the gap without corrupting its data.
The consent record lives where the cookies live
Most consent banners store the shopper's choice in a cookie or in local storage. When the shopper clears cookies mid-session, through the browser settings or a privacy extension, that stored choice disappears with everything else. The banner has no memory of the decision. As far as the site is concerned, a new visitor just arrived.
This is correct behavior, not a bug. Re-showing the banner is the compliant move: the site no longer has a record of consent, so it must ask again before setting non-essential cookies. The failure mode is the banner that does not reappear, because its logic assumed the choice was permanent. Consent state should be read fresh on every page load, never cached in a way that survives the storage being wiped.
The edge case that breaks implementations is partial clearing. Some browsers and extensions clear cookies but leave local storage, or vice versa. If the banner reads from one store and writes to another, a partial clear produces a split-brain state: the banner thinks consent was given while the consent cookie is gone, or the reverse. Store the canonical choice in one place and derive everything else from it.
Re-prompt without punishing the shopper
A shopper who just cleared their cookies is doing privacy hygiene. Rewarding that with a full-screen banner ambush on the next click feels like punishment and trains people to click accept blindly just to make it go away. The re-prompt should be the standard banner, in its standard position, with the same calm copy as the first visit.
Do not try to be clever about detecting the clear. Some implementations attempt to fingerprint the returning visitor or use the consent-mode default state to infer a previous choice. Reconstructing consent from inference defeats the purpose of asking. The shopper cleared their data; honor the blank slate completely.
One refinement is worth making: if the shopper had previously opened the preferences panel and made granular choices, that detail is gone too, and the re-prompt should not pretend otherwise. Present the same full choice, not a shortcut. The five seconds of extra friction are the price of a consent record you can defend.
Mind the measurement gap
Between the cookie clear and the new consent decision, there is a window where tracking state is undefined. Analytics implementations need a defined behavior for this window, and the defined behavior should be the conservative one: no non-essential tracking until the new choice is recorded. Consent Mode's default state exists precisely for this situation; make sure the default is deny and that it applies from the first pageview after the clear.
The messier problem is identity stitching. The pre-clear session and the post-clear session look like two different visitors to most analytics tools. Some teams are tempted to stitch them back together with fingerprinting or server-side identifiers that survived the clear. Resist it. If the identifier survived a cookie clear, it is arguably the kind of persistent tracking the shopper was trying to escape, and stitching it silently is a compliance risk dressed as data hygiene.
Report the gap honestly. A mid-session clear followed by a consent decline will show up as a session that ends abruptly and a new session that begins. That is what happened. Smoothing it over in reporting creates numbers that look cleaner and mean less.
Test the clear, not just the banner
Consent testing usually covers the happy paths: accept, reject, open preferences, save choices. Add the hostile path to the test plan: clear cookies mid-session, in the middle of checkout, with items in the cart, and verify three things. The banner reappears. The cart survives, because cart state should never depend on the same storage as consent. And no non-essential tags fire before the new choice.
Test across browsers, because clearing behavior differs. Safari's clear is aggressive and prompt. Chrome distinguishes cookies from site data in ways shoppers do not expect. Firefox's total cookie protection changes what a clear even means. The banner logic should be robust to all of them, which in practice means: read state fresh, default to deny, ask again, and never assume continuity.
The broader principle is that consent is a per-visit, per-state reality, not a permanent flag. Systems designed around the assumption that the choice persists forever break the moment the shopper exercises control over their own data. Design for the clear and the banner handles everything else.