What GDPR and ePrivacy actually require of web analytics
· 4 min read
Two European rules matter for analytics. They are usually mixed together, which is where most of the confusion comes from.
ePrivacy: the cookie rule
The ePrivacy Directive, written into each country's law, says you need consent before storing information on a visitor's device or reading information already stored there. That is the rule behind cookie banners. It applies to cookies, local storage, and anything else that puts a value on the device and reads it back later.
It has an exemption for things that are "strictly necessary" to provide a service the visitor asked for. A shopping cart cookie qualifies. Analytics does not, in the view of every regulator that has looked at it. Some countries, notably France, allow a narrow exemption for very limited first-party audience measurement, but the conditions are strict and most tools do not meet them.
The key point: this rule is about the device, not about personal data. A cookie containing a random number still needs consent, because it is stored on the device. Conversely, a tool that stores nothing on the device is outside this rule entirely, no matter what it does on the server.
Coldreader sets no cookies and writes nothing to storage. The ePrivacy consent requirement does not apply.
GDPR: the personal data rule
GDPR governs personal data: any information relating to an identified or identifiable person. It does not care where the data lives. It cares whether the data can be tied to someone.
Three things in typical analytics are personal data:
- IP addresses. The Court of Justice decided this in 2016. Even if you personally cannot identify someone from an IP, the fact that a court could order the ISP to makes it personal data.
- Persistent identifiers. A cookie ID or a fingerprint that stays the same across visits is personal data, because it singles a person out over time, even without a name.
- Precise combinations. Exact screen size, plus browser version, plus OS version, plus timezone, plus language is unique enough to be a fingerprint, and therefore an identifier.
If you process personal data you need a legal basis. For analytics the plausible one is legitimate interest: you have a real reason to understand your site's traffic, the processing is minimal, and a visitor would reasonably expect it. Legitimate interest is a real basis, not a loophole, but it comes with obligations: a documented balancing test, mention in your privacy policy, and honouring objections. It also does not override ePrivacy. A cookie still needs consent even if the processing behind it rests on legitimate interest.
What minimisation looks like in practice
GDPR's data minimisation principle says collect only what you need. For analytics that means asking, for each field, whether it can be made coarser or dropped.
- IP address: use it in memory, never store it. Derive a country if you want geography, then discard it.
- Identifier: if you need to count uniques, use a hash that cannot be reversed and that changes daily so it never becomes persistent.
- User agent: reduce it to a browser family and an OS family. Nobody needs the build number.
- Screen size: bucket it. "Between 1024 and 1439 pixels wide" is useful for design decisions and useless for identification.
- Referrer: keep the hostname, drop the path and query string.
- Page URL: drop the query string. It is where tokens and email addresses hide.
Done consistently, this leaves data that no longer relates to an identifiable person. Regulators have not issued a blanket blessing for this design, and a cautious site owner still lists analytics in their privacy policy and keeps a short legitimate-interest note on file. But there is no personal data to hand over on an access request, nothing to delete on an erasure request, and nothing to leak in a breach.
The Google Analytics decisions
Between 2022 and 2023 the Austrian, French, Italian, Danish, Finnish and Norwegian regulators each found that Google Analytics, as commonly deployed, violated GDPR. The core problem was transferring personal data, including IP addresses and identifiers, to the United States without adequate protection. The EU-US Data Privacy Framework adopted in 2023 changed the transfer analysis, but the decisions still illustrate the point: an analytics tool that collects identifiers is processing personal data, and everything that follows applies.
Where the data lives matters too
Even without transfers being the headline issue, hosting inside the EU removes a whole chapter of paperwork. Coldreader runs on servers in Frankfurt and nothing leaves the EU.
What you still have to do
Using a minimal tool does not make your website exempt from GDPR. It makes the analytics part easy. You should still:
- Mention in your privacy policy that you use privacy-friendly analytics and what it collects.
- Have a data processing agreement with your analytics provider. Ours is part of the terms.
- Not put personal data in your own URLs. A path like /welcome/jane.doe defeats everyone's minimisation.
The short version
Cookies need consent. Personal data needs a legal basis and minimisation. A tool that uses neither cookies nor personal data sidesteps the first and reduces the second to a paragraph in your policy. That is the design goal, and it is achievable without giving up the numbers you look at.