Do You Need a Cookie Banner for Analytics? What EU Law Actually Requires (2026)

If you run a website in the EU, you have almost certainly clicked "Accept" on more cookie banners than you can count — and you have probably wondered whether the one on your own site is actually required, or just something everyone copied from everyone else.

The honest answer is that most people ask the wrong question. They ask "do I need a cookie banner?" when the law never mentions banners, or consent buttons, or even a management platform. It mentions something much more specific — and once you see what the rule actually governs, the question of whether your analytics needs a banner gets a lot clearer, and a lot more interesting.

Updated 18 October 2026: we corrected what Pulse stores and reads in the browser and how its visitor hash works, and we now say what this site's interactions script records.

The cookie banner isn't about cookies

The law everyone calls "the cookie law" is Article 5(3) of the ePrivacy Directive (Directive 2002/58/EC, as amended in 2009). Its operative sentence is worth reading slowly, because almost every misunderstanding starts by skipping it:

"…the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent…"

Notice what is not in that sentence. The word "cookie" does not appear. Neither does "banner", "tracking", or "advertising". The trigger is a technical action — storing information on, or gaining access to information already on, a device — with two narrow exemptions: doing it purely to carry out a transmission, or when it is strictly necessary to provide a service the user explicitly asked for.

Cookies are simply the most common way to do the triggering thing. A cookie is a small file written to your device and read back on later requests. That is textbook "storing" and "gaining access." But the rule is defined by the action, not the technology — which is why the European Data Protection Board (the body that coordinates EU data regulators) adopted guidelines in October 2024 confirming that Article 5(3) also covers tracking pixels, link decoration, browser fingerprinting, some kinds of local processing, and even certain IP-based tracking. If a technique stores or reads information on the device, it is in scope, cookie or not.

One more thing that catches people out: this consent requirement is independent of whether any personal data is involved. In Planet49 (Case C-673/17), the Court of Justice held that a pre-ticked consent checkbox is invalid, and that the consent obligation for cookies applies regardless of whether the stored information is personal data. So "our cookie doesn't contain personal data" is not a defence to the cookie rule. It is answering a different exam question.

Why analytics cookies need consent — and "first-party" doesn't save you

The most common escape hatch people reach for is: our analytics is first-party, so it's essential and exempt. It is a comforting story. It is also, as a general EU rule, wrong.

Back in 2012 the Article 29 Working Party — the EDPB's predecessor — looked at exactly this question in Opinion 04/2012 and concluded that first-party analytics cookies are not covered by the strictly-necessary exemption. Their reasoning was blunt: a visitor "can access all the functionalities provided by the website when such cookies are disabled." The site works fine without counting you. Measuring the audience is valuable to the operator, but it is not a service the user requested — so it does not clear the "strictly necessary" bar.

That position is still the mainstream one. The UK's ICO says analytics cookies require consent. Belgium's Data Protection Authority (Autorité de protection des données / Gegevensbeschermingsautoriteit) says the same in its official cookie checklist, which states plainly that visitor counting does not fall within the strictly-necessary functional-cookie exemption, citing that 2012 opinion directly.

There is exactly one well-developed exception, and it proves the rule. France's CNIL operates a conditional no-consent regime for audience-measurement cookies — but only if the tool clears a demanding list: used solely to measure audience, output that is anonymous only, no cross-site tracking, no combining with other processing, a cookie lifetime capped at 13 months, and data retention capped at 25 months, with users still informed and able to object. Even then, CNIL warns that most large analytics products do not qualify regardless of how they are configured. And crucially, this is a French carve-out. It is not EU law, and — this matters for a Belgian company writing this post — Belgium has not adopted it. If your reasoning is "France allows it," you are quoting the wrong regulator for most of Europe.

So for the ordinary case — a first-party analytics tool that sets a cookie, in most EU member states — the answer to "do I need consent?" is yes. Not because of some aggressive interpretation, but because of the plain text and twelve years of consistent guidance.

The regulation that was supposed to fix this is dead

Here is where a lot of otherwise-current advice goes stale. For years, the standard reassurance was: don't worry too much, the ePrivacy Regulation is coming and it will sort out banner fatigue. You may still read that in articles written as recently as last year.

It is no longer true. The proposed ePrivacy Regulation — the instrument meant to replace the 2002 Directive — was formally withdrawn by the European Commission. It appeared on the withdrawal list in the Commission's 2025 Work Programme, and the withdrawal was published in the Official Journal as notice C/2025/5423 on 6 October 2025. The European Parliament's own legislative observatory now records the file's status as "Procedure lapsed or withdrawn." After roughly eight years of deadlock, it is not a delayed bill awaiting passage. It is a closed file.

The practical consequence: the 2002 ePrivacy Directive, as transposed into each member state's national law, is the operative cookie law in 2026, and will be for the foreseeable future. There is no modernised successor waiting in the wings to relax it.

There is a new reform effort — the Commission's "Digital Omnibus" package, tabled in late 2025 — but it is a different beast. Rather than reviving a standalone regulation, it proposes to fold storage-and-access rules into the GDPR itself via new articles, including a limited carve-out for first-party audience measurement. Legal analysts covering the draft, such as Osborne Clarke, note two things worth holding onto: it is a proposal, still working through Parliament and Council with no adoption in sight, and even as drafted, the Commission's own explanatory text cautions that common commercial analytics tools are "unlikely to fall within the scope" of the exemption. Betting your compliance posture on a bill that might pass in some form, sometime, is not a plan.

What "cookieless" actually has to mean

So if the rule is about device storage and access — could you just not touch the device, and sidestep the whole thing?

In principle, yes. If a method genuinely never stores anything on the device and never reads anything from it, Article 5(3) is not engaged, and no consent question arises for that step. That is the logic behind the entire "cookieless analytics" category.

But this is exactly where honest engineering has to part ways with marketing copy, because the EDPB's 2024 guidelines read "gaining access" much more broadly than most vendors admit:

• A client-side script that reads device attributes and sends them to a server is "gaining access." The guidelines are explicit that when JavaScript instructs the browser to send information back, that transmission itself counts — even if nothing was ever stored. A tool that builds a "cookieless" fingerprint from your screen size, timezone, fonts, and user-agent is doing precisely this. No cookie, still in scope.
• Tracking pixels are in scope through caching alone, with no persistent storage required.
• Even IP-based tracking is presumed in scope. The guidelines say that gaining access to an IP address triggers Article 5(3) "in cases where this information originates from the terminal equipment" — and that unless an operator can affirmatively show the IP does not originate from the user's device, it should assume the rule applies. That is a hard thing to guarantee for a whole site's worth of visitors.

The takeaway is uncomfortable for the "cookieless = free pass" pitch: most tools that call themselves cookieless still run a script that reads and transmits device signals, and that reading is the trigger. Dropping the cookie while keeping the fingerprint changes the technology and not the legal action. And separately — even in the rare case where Article 5(3) genuinely does not apply, if the tool processes personal data such as an IP address, the GDPR still requires a lawful basis for that. Clearing the cookie bar is not the same as clearing every privacy obligation. (We dig into the GDPR side — lawful basis, minimisation, international transfers — in a companion post on GDPR-compliant analytics.)

Genuinely consent-free analytics, then, is a narrower category than the label suggests. It means: no storage on the device, no client-side reading of device signals to build an identifier, and no retained personal data downstream. That is a high bar. It is also, deliberately, the bar we built Pulse to aim at, and the next section says where it does not quite get there.

How Pulse answers the question

Pulse is our own analytics product, and it powers this very site. Rather than ask you to trust that it is cookieless, here is what the tracker and the server actually do, because "receipts, not promises" only means something if we show the receipts. This site also loads Pulse's optional interactions script, which can record the label of a clicked link or button, how many characters were copied and from what kind of element, and the name and field count of a submitted form. Our privacy policy describes it.

It sets no cookie on your site. The tracking script that runs on a measured website sets zero cookies. Its own header comment says so, and more importantly, the server endpoint the script posts to is registered with no cookie or CSRF middleware at all — only rate limiting. There is no code path that could set a tracking cookie on a visitor, because none is wired up.

It keeps no lasting identifier on your device. This is the part that separates Pulse from most "cookieless" tools. Pulse does not run a fingerprinting script. It does not read your canvas or your fonts to synthesise an ID. It does read your viewport size, language and timezone, plus a coarse operating-system hint and a few human-versus-bot signals, and sends them with each pageview, but none of it goes into the hashes. There is no cookie, and no identifier that outlasts the site's identity window (a calendar month by default) or reaches another website.

Unique visitors are counted server-side, from data your browser sends anyway. When a pageview arrives, the backend computes a session identifier as a salted hash of the request's IP address, user-agent, and the site's domain — roughly SHA-256(daily_salt + domain + ip + user_agent). The daily_salt itself rotates every day (derived through a monthly key so that a compromise has a bounded blast radius). The effect: the same visitor on the same day produces the same session hash, so repeat pageviews collapse into one visit, and after the site's midnight the salt changes and the same person produces a completely unrelated one. A second hash, the visitor hash, is built the same way with a salt that resets on the site's identity window instead: a calendar month by default, which owners can shorten to 24 hours, 7 days, 30 days or session only. It is what lets a returning reader count once within the window. Nothing links a reader across sites or across windows, and there is no cross-device thread to pull. "Unique visitors" in the dashboard is then an aggregate that counts a returning reader once within the window, using the visitor hash. The dashboard shows aggregates by default. An owner can switch on a Visitors view, off by default, that lists pseudonymous readers and their visits inside the window, never beyond it, never on share links, the public API or exports.

The raw IP is used for a moment, then wiped. Computing those hashes needs the IP, and so does the location lookup: the country comes from the CDN edge, and the region and city are derived from the IP in process. But the raw IP is never persisted, never logged, and never forwarded: a dedicated middleware scrubs it from the request context immediately after the derived values are computed. The events table has no column for an IP address or a raw user-agent to live in. What survives is two hashes (a session hash that resets daily and a visitor hash that resets monthly by default), a location, and coarse attributes such as device category, referrer and the pages visited. Since 10 September 2026 a new site collects country, region and city by default; the owner can cap it at country or switch it off. The per-reader Visitors view is off by default.

Now the honest caveats, because a post about honesty that hides its own footnotes would be self-refuting:

• The tracker does touch three tiny browser values. Despite the script's own "no localStorage" comment, it keeps two values in your browser's session storage for as long as the tab stays open, and it reads one flag in local storage. ciphera_anchor holds the id of the tab's latest pageview and is sent back to the server as anchor_id, which keeps one visit together. ciphera_last_pv is a refresh guard that stops a page refresh from being counted twice. pulse_ignore is written only when a site owner opens a ?pulse-ignore link, so they can exclude their own visits. None of the three is a cookie, and none can follow you to another site. The two session values do hold the id of a pageview, though, and that id travels back to the server. By the test this post set out, all three count as storing or reading information on your device. They exist, and pretending they don't would be exactly the kind of overclaim this post is arguing against. Our privacy policy takes the position that this storage is strictly necessary and needs no banner. The site operator decides, with counsel.
• The Pulse dashboard uses login cookies — like any product you log into. When you, the site owner, sign in to view your stats, that dashboard sets login cookies and a few preference cookies, all listed in our privacy policy. The login cookies are strictly necessary for a service you explicitly requested, and all of them are completely separate from the tracking script that runs on your visitors' browsers. The cookieless claim is about the tracker, not about logging in to read your own charts.

If you want the deeper accounting of what Pulse can and cannot see, we wrote it all out, including the exact hash mechanics, in what we see about you, and what we don't. And because the servers that count and store the data are in Switzerland rather than in a US cloud, and requests reach them through the global edge network of Bunny, an EU (Slovenian) company, the data-transfer questions that sink so many analytics tools mostly don't arise — a point we made the case for in why Swiss infrastructure matters for data privacy.

So — do you actually need a banner?

Here is the honest synthesis, without the marketing gloss.

If you run a cookie-based analytics tool — Google Analytics and most of its mainstream competitors — on a site aimed at EU visitors, then yes, you almost certainly need consent before those cookies are set, and in most member states, including Belgium, "it's first-party" will not exempt you. (For Google Analytics specifically there is a second, independent problem: several EU regulators ruled its US data transfers unlawful in 2022. You can see how badly the numbers work against cookie-gated measurement in our comparison of Pulse, GA, Plausible, and Fathom.)

If you run a tool that sets no cookie, stores no identifier, and retains no personal data, you have removed the mechanism that cookie consent exists to govern. There is no stored identifier to consent to, and nothing personal being kept. That is a categorically stronger position — but I am not going to tell you it is a guaranteed, universal exemption, because the law is broad and fact-specific and no regulator has issued a ruling blessing any particular vendor's exact model. What I can tell you is that Pulse is built to give you the least to worry about. It sets no cookie, and it touches the device only in the small ways described above. It links a returning reader only within the site's identity window (a calendar month by default), never across sites, and it hosts the result in the EU's neighbourhood rather than shipping it across the Atlantic. The final call for your specific site — and any notice you choose to give — belongs to you and your data protection officer. We publish our own architecture openly at /trust and describe exactly what runs on this site in our privacy policy precisely so that call is an informed one.

The cookie banner became the symbol of privacy law because, for two decades, the dominant way to measure a website was to leave something on the visitor's machine and read it back later. The banner is the price of that choice. The more interesting move is not to negotiate a better banner. It is to stop needing one — by not touching the device in the first place.

This post is an engineering and legal-landscape explainer, not legal advice. Cookie and data-protection obligations depend on your specific setup, jurisdiction, and how a given tool is deployed; consult a qualified adviser or your supervisory authority for a determination about your own site.