Ask ten website owners whether their analytics is GDPR-compliant and you will get ten confident answers, most of them wrong in the same direction: "we added a cookie banner, so we're fine." A banner is one small piece of a much larger picture, and it doesn't touch the questions that actually decide whether your analytics is lawful — what data you collect, why, where it goes, and how long you keep it.
The good news is that GDPR compliance for analytics is not mysterious. It is a finite checklist, every item of which traces back to a specific article or ruling you can read yourself. The more useful news is that there is one architectural decision that makes most of the checklist evaporate — and it is worth understanding before you spend a quarter arguing with a consent-management platform.
Updated 18 October 2026: we corrected how Pulse's two hashes work, where its location data comes from, what the tracker stores and how requests reach our servers.
When does GDPR even apply to your analytics?
GDPR applies to the processing of personal data — Article 4(1) defines that as "any information relating to an identified or identifiable natural person," including someone identifiable indirectly "by reference to an identifier such as a name, an identification number, location data, an online identifier." The whole question of whether GDPR governs your analytics turns on whether what you collect counts as personal data.
For most analytics, it does — because of the IP address. Recital 30 of the GDPR names IP addresses and cookie identifiers explicitly as "online identifiers" that can be used to profile and identify people. The Court of Justice reinforced this in Breyer (Case C-582/14): a dynamic IP address is personal data for a website operator wherever that operator has a legal means of obtaining, from a third party like an internet provider, the extra information needed to identify the visitor. The ruling is conditional rather than absolute — but in practice, regulators now treat that condition as met in essentially every EU online context, which is why IP addresses are treated as personal data by default. A 2025 CJEU decision (EDPS v SRB, C-413/23 P) refined the edges — whether pseudonymised data is "personal" depends on who holds it and what they can reasonably do — but did not change the baseline for an analytics operator sitting on raw request data.
Here is the trap that catches a lot of "privacy-friendly" tools: not retaining data is not the same as not processing it. Article 4(2) defines processing to include mere collection, not just storage. If a tool reads your IP address for a fraction of a second to derive a country or a counting hash and then throws it away, that fraction of a second is still processing of personal data, and it still needs a lawful basis. "We don't store IPs" is a good and important property — but on its own it does not put you outside GDPR. It changes how much is at stake, not whether the rules apply.
The checklist
Once GDPR applies, these are the obligations that decide whether your analytics deployment is lawful. None of them is exotic; all of them are checkable against your actual setup.
| What GDPR requires | Article | How to check your setup |
|---|---|---|
| A lawful basis — consent or legitimate interest | Art 6 | Can you name your basis? If legitimate interest, is the balancing test documented? (Separate from cookie consent, below.) |
| Purpose limitation | Art 5(1)(b) | Is every field tied to a stated purpose, or collected "just in case"? |
| Data minimisation | Art 5(1)(c) | Full IPs, precise geolocation, or per-user journeys you never use? |
| Storage limitation | Art 5(1)(e) | Is there a real retention period — and does data actually get deleted? |
| Protection by design & default | Art 25 | Built in from the start, or bolted on after? |
| Transparency | Arts 12–14 | Does your privacy notice describe the analytics accurately? |
| A DPIA where the risk is high | Art 35 | Does the tool profile or track at scale? If so, is it assessed? |
| Records of processing | Art 30 | The "under 250 staff" exemption is narrow — most tracking still needs a record. |
| A lawful transfer if data leaves the EEA | Chapter V | See the next section — where most tools fail. |
| Consent for device storage (ePrivacy, separate) | Art 5(3) ePD | Sets a cookie or reads storage? You generally need prior consent — see the cookie-banner post. |
Two of these deserve emphasis because they are the most commonly botched. The lawful basis and the cookie consent are different questions — you can have a valid legitimate-interest basis for processing analytics data and still be required to get consent before setting the cookie, because those obligations come from two different laws. And the records exemption is a trap: "we're a small company" is not the shield people assume, because the exemption falls away for processing that is regular or that risks people's rights, which is most analytics.
The transfer trap — where most tools actually fail
If there is one line on the checklist that has done the most legal damage, it is international transfers. And the story is best told through the tool most sites reach for.
In 2020, the Court of Justice's Schrems II ruling (Case C-311/18) struck down the EU-US Privacy Shield, holding that US surveillance law did not offer EU-equivalent protection or redress. Then, across 2022, a coordinated wave of complaints turned that principle on Google Analytics specifically. The Austrian authority ruled first (decision published January 2022) that a website's use of Google Analytics was an unlawful transfer of personal data to the US; France's CNIL issued formal notices weeks later; and Italy's Garante followed in June, in a decision against Caffeina Media that made a point worth remembering — it held that Google's "IP anonymisation" feature is pseudonymisation, not anonymisation, because Google retains the capacity to re-identify. These three were the most visible of roughly a hundred near-identical complaints filed across the EEA. The pattern was uniform: US-hosted analytics, EU visitors, no adequate safeguard.
The 2023 EU-US Data Privacy Framework restored a lawful transfer route for US organisations that self-certify under it — and it is formally in force in 2026. But it should be treated as live and contested, not settled: its first court challenge was dismissed by the EU General Court in September 2025, and that dismissal was appealed to the Court of Justice (Case C-703/25 P), which was still pending as of mid-2026 — while separate concerns about the independence of the US oversight board that the framework relies on have added political fragility. Building your compliance on a transfer mechanism that a pending case could unwind is a risk you should at least take with your eyes open.
There is a way to make the entire transfer question disappear: don't transfer. If analytics data never leaves the EU — or sits in Switzerland, whose adequacy the European Commission reaffirmed in its January 2024 periodic review of that country's long-standing adequate status — then Chapter V simply isn't engaged. No standard contractual clauses, no supplementary-measures analysis, no framework-under-appeal to worry about. Residency is not a compliance silver bullet on its own, but it removes the single hardest line on the checklist.
The shortcut: process no personal data
Look back at the checklist and notice something. Almost every obligation is triggered by processing personal data. Lawful basis, minimisation, retention, records, transfers, most DPIA triggers — they all attach to personal data. Remove the personal data, and most of the list has nothing to attach to.
That is the architectural move privacy-first analytics is built around: collect no cookie or cross-site identifier, retain no IP address, and produce output that is genuinely aggregate. If the data you keep cannot be tied back to a person, Recital 26 takes it outside GDPR's scope entirely, because the data-protection principles "do not apply to anonymous information."
But this is exactly where honesty has to be louder than marketing, because two shortcuts here are false:
- "Aggregated" is not automatically "anonymous." Aggregation can still leak identity through small cells and singling-out; whether an aggregate output is truly anonymous is a substantive, fact-specific question, not a label you get to apply because you ran a
GROUP BY. - Hashed or truncated IPs are pseudonymisation, not anonymisation. The EDPB's 2025 guidelines on pseudonymisation are explicit: data that could be attributed to a person using additional information remains personal data, even if the person holding it has erased that additional information — it becomes anonymous only if the full conditions for anonymity are met. So a tool that same-day-hashes your IP and calls the result "anonymous" is usually overstating it. The data is minimised and pseudonymised — which is genuinely better — but it is not magically outside GDPR.
The honest version of the shortcut, then, is not "we process no personal data, so GDPR doesn't apply to us." It is: we minimise processing to the point where there is almost nothing left to govern, and we build toward genuine anonymity in the output. That is a defensible, checkable claim. "We're exempt" is not.
How Pulse checks each box
Pulse is our own analytics product, and it was designed around exactly this shortcut — not to manage GDPR obligations after the fact, but to remove what triggers them. Here is how it maps to the checklist. (For the full architectural accounting, including the exact session-hash mechanics, see what we see about you, and what we don't.)
Personal data — minimised to a transient moment. Pulse does process your IP address, and we should say so plainly: to count a visit it needs the IP for the instant it takes to compute the session and visitor hashes and, unless the site owner has switched it off, a location lookup. Under GDPR, that momentary use is processing. What Pulse does not do is keep it. A dedicated middleware wipes the raw IP from the request the moment the derived values are computed; the events table has no column for an IP address or a raw user-agent to live in. So the processing exists, but it leaves much less behind for the rest of the checklist to grip.
Data minimisation and by-design (Art 5(1)(c), Art 25). There is no cookie, no fingerprint, and no identifier that outlasts the site's identity window (a calendar month by default) or reaches another website. Visits and visitors are counted with two server-side salted hashes of the IP, user-agent, and domain. A session hash rotates every day and ties pageviews into one visit. A visitor hash rotates every calendar month by default (a site owner can shorten this identity window) and removes duplicate visitors within it. Nothing links a reader across windows or across sites. The dashboard shows aggregates by default; a site owner can switch on a Visitors view (off by default) that lists pseudonymous readers and their visits inside the window, never beyond it. Minimisation isn't a setting here; it's the shape of the data model.
Geolocation without storing the IP. The CDN edge (Bunny) supplies the country. Region and city are derived from the IP in process, on our own infrastructure, and the IP is then discarded and never stored. A new Pulse site collects country, region and city by default; the site owner can cap it at country or switch it off.
International transfers (Chapter V): only in limited cases. Pulse's data lives in Switzerland (Exoscale's Zurich datacentre), and there is no US sub-processor in the path. The tracker and the API are served through the edge network of Bunny, an EU (Slovenian) company, where the encrypted connection ends. Our privacy policy lists Bunny as a sub-processor that handles IP addresses transiently on a global edge network, and says that in limited cases data may be processed in other jurisdictions, with standard contractual clauses where needed. So the single hardest line on the checklist, the one that sank Google Analytics, arises only in those limited cases. We wrote about why Swiss infrastructure matters for exactly this reason.
Device storage / cookie consent — nothing to consent to. The tracker sets no cookie. It keeps two short-lived values in the open tab (a reference to the tab's latest pageview, and a refresh guard) and one flag that is written only when a site owner opens a ?pulse-ignore link. We treat this storage as strictly necessary, so the separate ePrivacy consent question that a cookie triggers doesn't arise for it; whether that holds for your own site is for you and your counsel to decide. (The honest footnotes, including the fact that logging into the Pulse dashboard uses ordinary session cookies, are covered in the cookie-banner companion post.)
The net effect is not that Pulse waves a wand and exits GDPR. It is that the obligations which normally pile up around retained personal data — subject-access requests for visitor data, retention schedules, breach exposure, transfer paperwork — have little to attach to, because the only visitor identifiers Pulse retains are hashes: a session hash that rotates daily and a visitor hash that rotates monthly by default. That is a quieter claim than "100% compliant, guaranteed," and a much more honest one.
Compliant by design, not by disclaimer
If you take one thing from the checklist, let it be this: GDPR compliance for analytics is decided by architecture far more than by paperwork. You can paper over a data-hungry tool with a legitimate-interest assessment, a consent banner, standard contractual clauses, and a retention policy — and you will still be carrying every one of those obligations, plus the risk that a pending court case or a regulator's next decision moves the ground under you. Or you can choose a tool that keeps far less of what triggers the obligations in the first place, and spend that quarter on your product instead.
There is no configuration that makes a US-hosted, cookie-setting, IP-retaining analytics tool disappear from GDPR's scope. There is an architecture that gets most of the way there — cookieless, built on short-lived hashed identifiers, with the data held in Switzerland — and the difference between the two is not marketing. It is what your data model actually does when a visitor loads your page. Ours is partly open: the dashboard and the tracking script are open source; the server that stores the data is a managed service.
This post is an engineering and legal-landscape explainer, not legal advice. Whether a specific analytics deployment is GDPR-compliant depends on your configuration, jurisdiction, and processing purposes; consult a qualified adviser or your supervisory authority for a determination about your own site.