The law that puts a banner on your site is the ePrivacy Directive, not the GDPR. What Article 5(3) says, when measurement is exempt, and how to remove it.
·6 min read·DataSpice· Updated
Almost every founder who adds a cookie banner adds it for the wrong reason: other sites have one and it feels safer. That instinct is expensive. A consent banner is the largest single source of data loss in a modern analytics setup, because every visitor who declines is a visitor you cannot see and every visitor who bounces off the banner is one you never had. Ten minutes to find out whether you need it is time well spent.
Why the cookie banner is not a GDPR requirement
This trips up nearly everybody. The GDPR governs the processing of personal data: your lawful basis, how long you keep it, what rights the person has over it. It says nothing about cookies specifically.
The banner comes from somewhere else. It comes from the ePrivacy Directive, transposed into each EU member state's own national law, and in the United Kingdom into PECR, which the ICO enforces. Different instrument, different enforcement, and a different trigger. You can be perfectly compliant with one and in breach of the other.
What ePrivacy Article 5(3) actually covers
The operative provision is Article 5(3) of the ePrivacy Directive, and the thing to notice is that the word *cookie* does not appear in the mechanism at all. The rule is about storing information on, or gaining access to information already stored on, a user's terminal equipment. Terminal equipment means their phone or their laptop.
That wording is technology-neutral on purpose, so all of the following sit inside the rule:
Cookies, first party as well as third party. Being first party does not exempt you.
`localStorage` and `sessionStorage`, which several tools switched to precisely so they could stop saying the word cookie.
Device fingerprinting, meaning reading the screen size, the fonts, the canvas rendering and so on to build a stable identifier. That is accessing information stored on the terminal equipment, squarely inside 5(3), and European regulators have said so.
Anything else that writes a durable marker onto the visitor's machine.
A tool that advertises itself as cookieless while fingerprinting the device has not solved the problem. It has renamed it. The test that matters is not *does it set a cookie* but does it store or read anything on the visitor's device at all.
The two exemptions that remove the consent requirement
Article 5(3) exempts two cases. The first is storage whose sole purpose is carrying out the transmission of a communication. The second is storage strictly necessary for a service the user explicitly requested, and that is the one people reach for.
*Strictly necessary* is narrow, and it is read from the user's point of view rather than yours. A session cookie holding a shopping basket qualifies, because the visitor asked for a basket and a basket cannot work without one. Analytics does not, in the general case. The visitor asked to read your page. They did not ask to be counted. Your business needing the number is not the same as the service requiring it, and that distinction is the whole of the argument.
How the audience-measurement carve-out applies to analytics
There is a real middle position. Several regulators accept that basic audience measurement sits closer to a site working properly than to advertising, and have published criteria under which it can be exempt from consent. France's CNIL is the clearest example and the shape of its criteria is representative:
Strictly limited to measuring the site's own audience, with no cross-site tracking and no combining with data from other sites.
First party, with the data not shared onward or reused for another purpose such as advertising.
Producing anonymous, aggregate statistics only.
A limited lifetime on the identifier and a bounded retention period on the data.
Two warnings. This is a national position rather than a harmonised EU one, so what is exempt in Paris may not be in Berlin. And the exemption is granted against the criteria, not against a product name. Some configurations of a given tool qualify and others do not.
How cookieless analytics removes the banner entirely
If nothing is stored on the device and nothing is read from it, Article 5(3) is not engaged. Not exempted. Not engaged, because the act the rule governs never happens. There is no consent to collect for storage that does not exist, and the banner has nothing left to ask about.
This is achievable, and the mechanism is worth understanding because it is what you should ask any vendor to describe. A visit arrives. The server has the IP address and the user-agent string, because that is how the internet works. Instead of writing an identifier back to the browser, it hashes those together with a secret salt that rotates every day and stores only the hash. It never stores the IP. Tomorrow the salt is different and the old one is deleted, so the same visitor produces a different identifier and yesterday's identifier can no longer be recomputed by anyone, us included.
That is how DataSpice counts. The trade is real rather than free: a person who comes back three days running is counted as three people. We think that is the right trade for a product that does not want to ask your visitors for permission, and we would rather state the cost than let you find it later. There is more on what it does to your numbers in why your analytics thinks you are three people.
What the GDPR still requires once the banner is gone
Removing the banner removes the ePrivacy question. It does not remove the GDPR one, and this is where otherwise careful setups get sloppy.
An IP address can be personal data. The Court of Justice held in *Breyer* that a dynamic IP can be personal data in the hands of a website operator, so processing it, even briefly, even only to hash it, is processing.
You still need a lawful basis. For genuinely privacy-preserving first-party audience measurement, legitimate interests is the basis normally relied on, and it requires you to have done the balancing rather than assumed the outcome.
You still owe transparency. Your privacy notice has to say what is collected, why, and for how long. Ours is at /privacy and it was written against the running system rather than from a template.
Your analytics vendor is a processor. You need the agreement and you need to know where the processing happens.
Retention is a decision you have to make and be able to state. Keeping everything forever because storage is cheap is not a position you can defend in writing.
How to decide whether your site needs a cookie banner
Ask the only question that mattersDoes this tool store or read anything on the visitor's device? Cookie, localStorage, fingerprint, anything at all. Ask the vendor in writing and expect a one-word answer. Hesitation is an answer.
If the answer is yes, you need consentThat means a real banner with a reject option as easy as accept, and the tool must not load until consent is given. A banner that loads the script anyway is worse than no banner, because you get the breach and the friction.
If the answer is no, drop the banner and write down whyRecord how you concluded the rule is not engaged. The written reasoning is what makes it a position rather than a hope.
Handle the GDPR half regardlessLawful basis, privacy notice, processor agreement, retention period. Four things, one afternoon.
Ask a lawyer before you rely on itEspecially if you operate in more than one member state, or if your product touches anything sensitive.
The banner is not the safe default. It is a choice with a cost, and you pay the cost in the data you were trying to collect.
GA4 is the tool that puts the banner on most sites, because it sets first-party cookies by default. DataSpice vs Google Analytics 4 lays out that difference, and the several places where GA4 is still the better choice.