Blog

Do cookie-free analytics need cookie banners?

Published Jun 09, 2022 — last updated Jul 06, 2025

Screenshot of Plausible's claim to not need cookie bannersScreenshot of Fathom's claim to not need cookie banners

To save you a read: yes, they do - at least if you follow the wording of EU’s relevant directives, or listen to the opinion of the European Data Protection Board. What happens in court is another question, which (as far as I know) hasn’t yet been determined.

Most “privacy-aware” or “cookie-free” analytics solutions make the claim that you can forego cookie banners if only you use their product. A claim that is only as good as the evidence backing it up, of course.

In an effort to understand the legalities behind cookie banners, I’ve long wanted to dive into the EU laws that govern data privacy and how they apply to the specific implementations of Fathom and Plausible - the two major players, at the time of original writing.

The technical background

Web analytics track users, that’s the name of the game. HTTP is stateless, so you can’t gain much insight without tracking people. Privacy-aware analytics try do this in a privacy-friendly way however, using a variety of anonymization tricks.

In many ways what they do is essentially the same as classic analytics: when a user visits the website, they’re assigned a trackable identifier. When the user visits the website again, that identifier is used to update various statistics for the site.

The big difference is that a) that identifier is calculated based on various data that makes the user unique, instead of being stored on their device, and b) a lot of care is put into how the data is used, so no single user can ever be tracked in a privacy-compromising way (we’ll assume this is true; as we’ll see later, it has no bearing on our analysis).

The process looks a little something like this:

  1. The user visits the website, and is served a webpage containing the analytics solution’s tracking script.
  2. That script does little more than ask the user’s browser to send a request to the analytics solution, containing the current page (e.g. /).
  3. The analytics solution fingerprints the incoming request by hashing e.g. the User-Agent and IP address. This creates an anonymous but unique identifier for the user.
  4. The analytics solution uses that identifier to update statistics (e.g. store where and when the identifier was last seen, and calculate time spent on the last page the identifier was seen on)

This doesn’t cover all the anonymization aspects (salt rotation and the like), but it’s the general idea. Fathom has a much better explainer if you’re interested in the nitty gritty (I recommend it, it’s a clever algorithm).

Note: I’m not a lawyer. While I have (informally) consulted one for this article, the opinions expressed here are those of a guy with too much free time and not a lot of legal knowledge. I’ll be backing all of my claims up with quotes from EU’s Data Protection Board (EDPB) - but you should keep in mind that legal questions are never quite as black and white as I express them here.

When we’re talking about cookie banners there are primarily two different EU legal texts we’ll need to cover: the older the ePrivacy Directive (ePD), informally called the “cookie law”, and the newer and quite massive General Data Protection Regulation (GDPR). These two both relate to data privacy and are often confused, so here’s a quick breakdown:

ePrivacy Directive [Directive 2002/58/EC]

Directive from 2002, later amended in 2009. One of the early attempts at legislating online privacy. Puts rather strict limits on accessing or processing any data from end-user devices without requiring informed consent from the user. This is regardless of whether the data is personal or not.

Note that this is a directive, not a regulation, meaning it is up to the individual EU countries to implement the directive into law. We’ll arbitrarily ignore this distinction, and I will only be considering the wording of the directive itself in this article.

GDPR [Regulation (EU) 2016/679]

Regulation adopted in 2016, came into force in 2018. Huge regulation primarily addressing the right of an individual to control their personal data. If there is any theoretical way that data can be traced back to a person, that data is probably covered by GDPR.

Although GDPR is what everybody is talking about, it’s actually the ePD that’s the biggest problem for cookie-free analytics (since they effectively sidestep the GDPR by using strong anonymization).

That point is so important that I’ll repeat it in bold: it’s not the GDPR that’s the issue, it’s the ePD. Anonymizing the data does not absolve us from this.

To see why, we’ll need to dive a bit deeper.

The ePD Article 5(3)

Article 5(3) of the ePrivacy Directive, which is the article that requires consent for cookies, says:

Article 5(3). Member States shall ensure that 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 […] This shall not prevent any technical storage or access […] as strictly necessary in order for [a web service provider] explicitly requested by the subscriber or user to provide the service.

We’re only interested in the part that talks about “gaining of access to information already stored”, since privacy-aware analytics don’t store anything on end-user devices. The article is basically saying that we can’t access any data that’s “already stored” stored on “terminal equipment”, unless a) we have consent, or b) it’s strictly necessary for fulfilling what the user asked for (e.g. serving the website).

There are a few details that aren’t immediately clear though:

What information is considered “stored”?

This actually isn’t well-defined in the ePD itself; instead, the EU Data Working Party (later the EDPB) have tackled the problem in various opinions. Their 2023 guidelines summarizes it in section 2.6:

‘Stored information’ refers to information already existing on the terminal equipment, regardless of the source or nature of this information. This includes […] processes and programs executed on the terminal equipment, which may or may not produce information that is dependent on or derived from stored information.

This includes obvious things like files (stored by the user) and cookies (stored by the website), but also less obviously “stored” data like the User-Agent (stored by the browser manufacturer) and even screen size and MAC addresses (stored by hardware manufacturers) - the latter is given as an explicit example in the guideline section.

What does “gaining of access” mean?

Again this is not well-defined in the directive, but has been covered at length by the EDPB in various opinions. They summarize it in paragraph 32-34 of the 2023 guidelines:

Whenever an entity takes steps towards gaining access to information stored in the terminal equipment, Article 5(3) ePD would apply. Usually this entails the accessing entity to proactively send specific instructions to the terminal equipment in order to receive back the targeted information. […]

[…] Additional examples would include JavaScript code, where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted information. Such access clearly falls within the scope of Article 5(3) ePD, as the accessing entity explicitly instructs the terminal equipment to send the information.

[…] As noted in WP29 Opinion 09/2014, this can be the case when a website instructs the terminal equipment to send information to third-party advertising services through the inclusion of a tracking pixel. […]

They’re even nice enough to explicitly give tracking pixels as an example. Tracking pixels instruct the browser to send an HTTP request that contains on-device information, and therefore counts as gaining access to that data - exactly what our privacy-aware analytics are doing with JavaScript.

What exactly is “terminal equipment”?

The ePD piggybacks on prior and rather extensive legislation for defining this. For our purposes it’s enough to know that both the user’s computer and each individual component of it is terminal equipment. There are some less well-defined details for when in the networking path things stop being terminal equipment (is the customer’s residential router? the ISP’s NAT? the routing infrastructure of the internet at large?), but for those details you’ll have to look at section 2.3 of the EDPB 2023 guidelines.

What does “strictly necessary” mean?

According to a 2012 opinion on exemptions from the EU Data Protection Working Party, this means

[The access/storage] is strictly needed to enable the information society service: if [the access/storage] is disabled, the service will not work.

Some site owners argue that analytics are “strictly necessary” to deliver their website, so Art. 5(3) shouldn’t apply. This exact argument is addressed by the 2012 opinion:

While [cookie-based analytics] are often considered as a ‘strictly necessary’ tool for website operators, they are not strictly necessary to provide a functionality explicitly requested by the user […]. As a consequence, these cookies do not fall under the [exemption].

So in short: if you have a technical need to access the data to serve the user’s request, then you’re good without explicit consent. If it’s just because you want to, then that’s no good.

All in all the most important part to remember is that Art. 5(3) blocks us from storing or accessing pretty much any data from the terminal equipment, unless it’s strictly required to fulfill the user’s request, or we have gathered informed consent.

To see what all this means for cookie-free analytics, let’s have a look at the algorithm used by Fathom. It is essentially identical to that of Plausible, and presumably all the rest of the privacy-aware analytics out there:

To [fingerprint the user], we combine the following data to create a unique hash for the user:

  • A salt based on IP address & Site ID
  • IP Address
  • User-Agent
  • Hostname (The domain of the website, e.g. https://usefathom.com)
  • Site ID

We then take this data and perform a SHA256 hash on it.

If we boil it down to just the parts that are relevant for us, cookie-free analytics work by generating a hash based on the IP address of the incoming request and the User-Agent HTTP header. They do this by including a bit of JavaScript on the page that sends a request to their backend.

User Hey server, show me "/home" Server Alright! It contains <script ... /> for analytics Analytics Hey analytics, I've been instructed to talk to you. I'm at "/home" Oh, a new hash( )!

Unfortunately it is pretty obvious that this requires informed consent under the ePD Art. 5(3):

The EDPB (unfortunately) seems to agree with that analysis. In their 2023 guidelines paragraph 51 they say:

The addition of tracking information to URLs or images (pixels) sent to the user constitutes an instruction to the terminal equipment to send back the targeted information (the specified identifier). In the case of dynamically constructed tracking pixels, it is the distribution of the applicative logic (usually a JavaScript code) that constitutes the instruction. As a consequence, it can be considered that the collection of identifiers provided through such tracking mechanisms constitutes a ‘gaining of access’ in the meaning of Article 5(3) ePD, thus it applies to that step as well.

Even worse, and luckily a bit less definitive, accessing the IP address might even be in violation:

In [the context of IP-only tracking] Article 5(3) ePD could apply even though the instruction to make the IP available has been made by a different entity than the receiving one. However, gaining access to IP addresses would only trigger the application of Article 5(3) ePD in cases where this information originates from the terminal equipment of a subscriber or user […]. Unless the entity can ensure that the IP address does not originate from the terminal equipment of a user or subscriber, it has to take all the steps pursuant to the Article 5(3) ePD

The case is a little less clear if the analytics solution fingerprinted the original request, instead of asking the browser to send a new one. There wouldn’t be an “instruction to make the data available”, since the browser would be unpromptedly attaching it to the HTTP request it sends. The discussion is whether it still constitutes “accessing”, given that it’s happening because of an agreed upon protocol. EDPB 2023 paragraph 41 argues that it might (with no final decision one way or the other):

Network communication usually relies on a layered model that necessitates the use of identifiers to allow for a proper establishment and carrying out of the communication. The communication of those identifiers to remote actors is instructed through software following agreed upon communication protocols. As outlined above, the fact that the receiving entity might not be the entity instructing the sending of information does not preclude the application of Article 5(3) ePD. This might concern routing identifiers such as the MAC or IP address of the terminal equipment, but also session identifiers (SSRC, Websocket identifier), or authentication tokens.

So what now?

I originally started exploring this topic because I wanted to create a privacy-aware analytics solution of my own (this was back in 2020, when the available options looked a little different). This was partly for fun, partly to see if I could design something that didn’t require cookie banners.

Unfortunately I came to the rather demotivating conclusion that there simply isn’t any way to implement web analytics without running afoul of the ePrivacy Directive.

This was a surprising conclusion at the time. Morally we can go very far: we can put a lot of smart stuff together and create a system that can’t be used to track individual users. But legally, that doesn’t particularly matter. The ePrivacy Directive is written as it is.

Even the EU Data Protection Working Party decries this. In their 2012 opinion they write:

the Working Party considers that first party analytics cookies are not likely to create a privacy risk when they are strictly limited to first party aggregated statistical purposes and when they are used by websites that already provide clear information about these cookies in their privacy policy as well as adequate privacy safeguards. […] In this regard, should article 5.3 of the Directive 2002/58/EC be re-visited in the future, the European legislator might appropriately add a third exemption criterion to consent for cookies that are strictly limited to first party anonymized and aggregated statistical purposes.

This “re-visiting” of the ePrivacy Directive is supposed to come eventually in the form of the ePrivacy Regulation. At the time of writing it has been delayed for 6 years and counting. Update: as of February 2025, the ePrivacy Regulation has been officially withdrawn.

Until then we’re stuck with cookie banners. Or just ignoring the issue and doing it anyway, I guess.

Addendum 1 - Plausible

Plausible has been one of the more forthcoming companies on this topic. They do explicitly claim that you don’t need cookie banners if you use their product, but have been quite friendly when I’ve reached out to them.

Back in 2022, when I wrote the original version of this article, I asked them their opinion on it. Their response was (paraphrased) “thanks, but our claim has been approved by our legal team, and we stand by it”. Quite reasonable. I wouldn’t trust some random guy on the internet over my legal team either.

Later, in 2024, they released a quite in-depth blog post with a lawyer’s legal assessment of how the GDPR and the ePD applies to Plausible! It felt like exactly what I had been missing when I wrote the original post: a public, in-depth analysis of how the consent requirement applies to this kind of tool. Unfortunately, while the article spends a lot of time dealing with how GDPR applies, this is the extend of the ePD analysis:

Plausible Analytics does not use cookies or similar technologies that require information to be stored on the user’s device. Instead, the tool focuses on analyzing aggregated data without the need to access the end device or store information there.

Since Plausible Analytics does not store any information on the user’s device, Article 5(3) of the ePrivacy Directive does not require explicit consent.

As we’ve seen, the EDPB considers “take this information and send it to me” to be “accessing” the data, so that analysis doesn’t entirely hold.

This fits a trend I’ve seen in general when researching this topic: lawyers focus heavily on the GDPR, and seem to ignore (or forget) that the ePD still applies.

There is of course also the aspect of interpretation. The EDPB seems to have taken a hardliner approach, considering Article 5(3) of the ePD to apply in many edge cases. Plausible has an incentive to lean the other direction. The various Data Protection Agencies across the EU are likely to have their own interpretations. Until a court has taken a stance on the issue I don’t think we can get much closer to a definitive answer on who is right.

Further reading