Almost every article on this subject makes the same mistake in its first paragraph: it treats "GDPR-compliant analytics" as one question. It is two, they come from two different laws, and they are asked in a fixed order. Getting the order right is most of the work, because the first question is the one that decides whether you need a consent banner, and it is not the one about personal data.
What follows is what each law asks, what regulators have actually decided, and where the line between "needs consent" and "does not" genuinely falls. The last section says what this product does about it. Everything before that is true whichever analytics you end up using.
This is not legal advice. It is a careful reading of published rules and decisions by the people who built an analytics tool against them. Your regulator, your sector and your own configuration can all change the answer. Where it matters, the sources are named so you can check them rather than take our word.
Two laws, asked in order
The GDPR governs the processing of personal data. The ePrivacy Directive — 2002/58/EC as amended, implemented separately in each member state, and in the UK as the Privacy and Electronic Communications Regulations — governs access to a visitor's device. They overlap, but neither subsumes the other, and the ePrivacy question comes first.
Article 5(3) of the ePrivacy Directive is the one that produced every cookie banner you have ever dismissed. In substance it says that storing information on a user's terminal equipment, or gaining access to information already stored there, requires the user's consent — with two narrow exemptions: where it is done solely to carry out a transmission, or where it is strictly necessary to provide a service the user has explicitly requested.
Three things about that sentence are routinely missed:
- It does not say "cookies". It says information stored on or read
from terminal equipment.
localStorage,sessionStorage, IndexedDB, a cache-based identifier and a device fingerprint are all covered. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) went through this at length precisely because "cookieless" had started to be used as a synonym for "exempt", which it is not. - The exemption is about the visitor's request, not your business need. A shopping basket that survives a page navigation is strictly necessary to a service the visitor asked for. Knowing which of your blog posts performs best is necessary to you. Analytics has never qualified under the strictly-necessary limb in any regulator's guidance we are aware of.
- It applies regardless of whether the stored value is personal data. This is the part that catches people out. Writing a purely random, meaningless string to a visitor's device still engages Article 5(3), because the trigger is the act of writing, not the sensitivity of what was written.
So the first question is not "do we collect personal data". It is: does this script store anything on, or read anything from, the visitor's device? If the answer is yes and it is not strictly necessary, you need consent, and a refusal has to be as easy as an acceptance. No amount of anonymising afterwards changes that.
When the GDPR applies on top
The second question is whether what you collect is personal data. Article 4(1) defines it as any information relating to an identified or identifiable natural person, and Recital 26 sets the test: account must be taken of all the means reasonably likely to be used to identify the person, by the controller or by another person. Recital 30 names online identifiers — IP addresses, cookie identifiers — as things that may leave traces which, combined with unique identifiers, can be used to create profiles and identify people.
On IP addresses specifically, the Court of Justice settled the question in Breyer (C-582/14, 2016): a dynamic IP address is personal data in the hands of a website operator where that operator has legal means reasonably likely to be used to identify the person behind it, with help from a third party such as the access provider. The practical upshot for anyone operating a website in the EU is to treat an IP address as personal data and work from there.
And a persistent visitor identifier — the thing an analytics cookie exists to hold — is personal data almost by construction. Its entire purpose is to single out one device consistently over time. Article 4(1) says "identifiable"; singling out is what that means in practice.
What "anonymised" has to mean
This claim is on nearly every analytics vendor's site, and it is doing much less work than it appears to.
Anonymisation, in the GDPR's sense, is a one-way door. Recital 26 excludes anonymous information from the Regulation entirely — but only where the person is not or no longer identifiable, taking into account all means reasonably likely to be used by anyone. Article 4(5) defines the lesser thing, pseudonymisation: processing personal data so it can no longer be attributed to a person without additional information kept separately. Pseudonymised data remains personal data and remains fully in scope.
Truncating the last octet of an IP address, then storing the result next to a device identifier that persists for two years, is pseudonymisation at best. The identifier is the additional information, and you are holding it. The AEPD and EDPS joint paper on hashing (2019) makes the general point sharply: a hash of an identifier is a pseudonym, not an anonymous value, because the input space is usually small enough to search exhaustively.
| What the setup does | ePrivacy Art. 5(3) | GDPR |
|---|---|---|
| Analytics cookie, or any persistent ID written to the device | Consent required | Applies — persistent identifier is personal data |
| No storage, but IP address logged and retained | Not engaged | Applies — needs a lawful basis under Art. 6 |
| Device fingerprint, no cookie | Consent required — reading from the device | Applies |
| No storage, no retained identifier, aggregate counts only | Not engaged | Out of scope once genuinely anonymous |
What regulators have actually decided
Between December 2021 and mid-2022, four authorities reached the same conclusion about particular Google Analytics deployments: the Austrian DSB, France's CNIL, Italy's Garante, and the European Data Protection Supervisor in respect of a European Parliament website. Each concerned Universal Analytics, each turned substantially on the transfer of personal data to the United States in the wake of Schrems II (C-311/18, July 2020), and each found the implementation before it unlawful.
That picture is meaningfully different now. The European Commission adopted an adequacy decision for the EU–US Data Privacy Framework in July 2023, which restores a lawful transfer route to certified US organisations. It is under legal challenge and subject to periodic review, so it would be unwise to treat it as settled forever — but it is the law today, and articles still citing the 2022 decisions as though nothing has changed are out of date.
What has not changed is the Article 5(3) analysis, and it never depended on transfers at all. A product that writes an identifier to the visitor's device needs consent whether the servers are in Iowa or Ireland. If you are choosing analytics to avoid a consent banner, the transfer question is not the one to be reading about. The practical differences when moving off Google Analytics are mostly about what the numbers mean afterwards, not about the law.
The narrow path: analytics with no consent
Some regulators have set out explicit conditions under which audience measurement can run without consent. The CNIL's published criteria are the most concrete, and they are strict: the measurement must be strictly limited to producing anonymous statistics for the site operator alone; the data must not be cross-referenced with other processing or shared with third parties; it must not be used to track the person across different sites or applications; and the scope of what is collected has to be tightly limited.
Read that list closely and it describes a tool built differently from the ground up, not a tool with a setting turned off. The conditions are about architecture: can this system join a visitor across sites, not does it. A promise not to do something you remain perfectly capable of doing is a policy, and policies change with ownership.
That is the distinction worth holding on to when you compare tools. Ask what the system is incapable of, not what it has switched off.
Your side of it
Choosing analytics that needs no banner removes one obligation. It does not remove the rest, and these are the ones that show up in an audit:
- Say what you do in your privacy notice. Articles 13 and 14 require it whether or not consent is your lawful basis. Name the tool, say what it measures, say how long you keep it.
- Have a lawful basis for anything that is personal data. If your analytics processes any, Article 6 applies. For genuinely privacy-preserving measurement, legitimate interests under Article 6(1)(f) is the usual basis, and it requires a balancing assessment you have written down — not merely asserted.
- Keep your Article 30 records. Analytics is a processing activity like any other and belongs in the register.
- Get the Article 28 processor terms in writing, along with the list of sub-processors. Ask us for ours.
- Set a retention period and mean it. Storage limitation is Article 5(1)(e). "Forever, in case" is not a retention policy. Ours is fifteen months, and it is enforced by deletion rather than by intention.
- Consider whether you need a DPIA. Article 35 is triggered by systematic monitoring on a large scale, among other things. Aggregate audience measurement usually will not reach it; session recording on a high-traffic site deserves the assessment.
- Remember the other scripts. The commonest failure we see is a site that switches to cookieless analytics, removes the banner, and leaves an ad pixel and an embedded video player in the page — both of which write to the device. Article 5(3) does not care that the thing writing is not your analytics.
How we built for it
Everything above is why the product works the way it does. The design constraints came from the rules, in this order.
Nothing is written to the visitor's device, so Article 5(3) is not engaged and no consent banner is required for our script. There are exactly two exceptions and both belong to the visitor rather than to us: the flag recording that someone has opted out, and the flag by which you exclude your own visits. Storing a record of a refusal is the one case where writing to the device is genuinely in the user's interest, and it is the standard exemption every regulator recognises for consent-refusal records.
No IP address is ever stored. Not in a database, not in a log, not in a sampled sidecar. The address exists as a local variable inside one request and is gone before the response is sent. This is an architectural rule in the codebase, not a configuration flag, and it is the reason the Breyer analysis largely stops before it starts.
Returning visitors are counted with a token that expires. It is derived from the request and a salt that rotates daily, and it is scoped to a single site. Yesterday's token cannot be recomputed, so yesterday's visitors cannot be joined to today's; the same person on another site running this product produces a different token. Cross-site and cross-month profiling are not switched off by policy — they are arithmetically unavailable. The mechanism is drawn out in full, and you can verify the whole of it from your own browser's network tab.
EU data residency is a jurisdiction, not a hint. The control plane and the event store are pinned to EU jurisdiction, which constrains where data may be replicated. A location hint, which is what the phrase usually means elsewhere, expresses a preference and constrains nothing.
The behavioural features follow the same rules. Heatmaps are aggregates — a coordinate, a selector and a viewport bucket, never attached to a person, and not filterable down to one. Session replay is the feature in this category most capable of capturing personal data, so it is the one with the strictest defaults: inputs masked, text suppressible, and the whole feature off until you turn it on. If you enable it, do the DPIA.
The longer, more technical version of all of this — what is collected field by field, how erasure requests are handled, what we are and are not a processor for — is in the compliance documentation, and our own privacy policy is written to the same standard we are asking you to hold us to. The plans are the same either way; none of this is a paid tier.
The short version
- Ask first whether the script writes to or reads from the device. If it does and it is not strictly necessary, you need consent — in every member state, regardless of where the data goes afterwards.
- Then ask whether what is collected is personal data. Persistent identifiers and IP addresses generally are.
- Treat "anonymised" as a claim to be tested. If an identifier is retained anywhere, the data is pseudonymous and still in scope.
- Prefer a tool that is structurally incapable of cross-site tracking over one that promises not to do it.
- Do the rest anyway: privacy notice, lawful basis, Article 30 records, processor terms, a retention period, and a DPIA where the monitoring is serious.