VaferBlocking stops tomorrow's tracking. Deletion deals with yesterday's. When a shopper rejects, most consent tools merely stop new trackers loading — while _ga, _fbp and friends, set on an earlier visit or before the choice, stay on the device and keep being sent with every request. The banner said no; the browser keeps saying yes.
Why cookies survive a reject
A consent tool's blocking layer intercepts scripts as they load. Cookies are a different mechanism: they were written earlier, they live in the browser's jar, and they ride along on every request to their domain automatically. Unless the tool actively deletes them at the moment consent is withdrawn, nothing about a reject touches them.
What deletion can and cannot reach — honestly
| Cookie type | Deletable on reject? |
|---|---|
First-party tracking cookies on your store's domain (_ga, _fbp, _ttp…) | Yes — if the tool knows their names |
| localStorage / sessionStorage identifiers | Yes |
| HttpOnly cookies | No — invisible to JavaScript by design |
| Cookies set by a third party on its own domain | No — browsers reserve that to the setting domain |
| Strictly necessary cookies (cart, checkout, session) | Must never be touched — deleting the cart honours nobody |
Two consequences follow. First, a tool that claims it deletes everything is overclaiming — the browser itself forbids some of it. Second, deletion is only as good as the store's cookie declaration: you can only safely delete what you can name. An undeclared cookie could be anything, including something checkout depends on.
Check your own store in one minute
- Private window → accept cookies → browse two pages.
- Reopen preferences → reject all.
- Devtools → Application → Cookies:
_gaand_fbpshould be gone;cartshould remain.
If the trackers survive, your reject is a note in a log somewhere, not an action on the device. The full version of this test — including catching banners that never blocked in the first place — is in the five-minute banner test.