GDPR Compliant Tracking: What You Can Measure Legally

GDPR compliant tracking is often described as a tooling decision — swap one script for another and you’re done. It isn’t. Compliance comes from what you collect and why, and a privacy-friendly tool configured carelessly can still put you back in scope. The good news is that the design principle behind it is genuinely simple: if you never hold personal data, most of the obligations never attach.

This is the part I wish someone had explained to me a decade ago, when I was dutifully anonymising IP addresses and assuming that settled it. It didn’t. Here’s what actually determines whether your tracking is compliant, what you can still measure once you strip the personal data out, and — honestly — what you give up.

Two Rules Apply, Not One

Most confusion about GDPR compliant tracking comes from collapsing two separate laws into one. They have different triggers and different tests.

The ePrivacy Directive governs access to a visitor’s device. Its Article 5(3) requires consent before you store information on someone’s terminal equipment or read what’s already there — cookies, localStorage, fingerprinting signals, all of it. Critically, this applies whether or not the stored data is personal. A purely technical identifier still counts.

The GDPR governs what you do with personal data once you have it: you need a lawful basis, a purpose, a retention period, and you owe people rights over it.

So a tracking setup can fail one test and pass the other. Storing a random ID in localStorage triggers ePrivacy even if that ID never identifies anyone. Meanwhile, recording IP addresses server-side with no device storage sidesteps ePrivacy but lands squarely in GDPR, because an IP address is personal data.

Therefore, tracking is comfortably compliant when it clears both: nothing written to or read from the device, and nothing personal retained on the server. That combination is what privacy-first tools are engineered to achieve.

Anonymous and Pseudonymous Are Not the Same Word

This distinction decides more compliance questions than any other, and it’s routinely fudged in vendor marketing.

Recital 26 states that data protection principles don’t apply to anonymous information — data that doesn’t relate to an identifiable person, or has been anonymised so the person is no longer identifiable. Reach that bar and you’re outside GDPR entirely.

Pseudonymised data is different. It’s data where identifiers are replaced by a token, but re-identification remains possible with additional information. Pseudonymised data stays fully in scope. A hashed IP is pseudonymous, not anonymous — the input space of IPv4 is small enough that a plain hash can be reversed by brute force in minutes.

The working test comes from the Article 29 Working Party’s opinion on anonymisation techniques, which asks three questions:

1. Singling out — can you isolate one person’s records within the dataset?
2. Linkability — can two records about the same person be connected, here or in another dataset?
3. Inference — can you deduce an attribute about a person with significant probability?

If all three answers are no, the data is anonymous. Aggregate counts pass easily. A table of individual sessions with timestamps and page paths usually fails on singling out, even with no name attached.

This is why “we anonymise IP addresses” was never a complete answer. Truncating the last octet reduces precision; it doesn’t stop you from singling out a session when you’re also storing a session identifier, a user agent, and a sequence of timestamps.

Design for Minimisation, Not for Cleanup

Article 5(1)(c) requires data to be adequate, relevant and limited to what’s necessary. Article 25 goes further and asks for data protection by design and by default.

Read together, they point somewhere specific: the compliant path is to not collect, rather than to collect and then scrub. Deleting personal data later is a process that can fail. Never receiving it is a property that can’t.

In practice, that means asking one question of every field and identifier in your setup: which decision does this change? If you can’t name a decision, don’t collect it. I have never once used the screen resolution of an individual visitor to decide anything. Aggregate device-class share, on the other hand, tells me whether to prioritise a mobile fix — and that’s an aggregate, not a record about a person.

What You Can Still Measure

Here’s the practical question underneath all of this. Strip out the personal data and what’s left?

The first seven cover what most website owners actually act on. That’s not a rhetorical claim — it’s the observation that pushed me to build this site in the first place. Traffic volume, sources, popular content, and where the funnel leaks are the inputs to nearly every decision a small or mid-sized site makes.

What You Genuinely Give Up

I’d rather name the losses than pretend they don’t exist, because the trade-off is real for some businesses.

Multi-session attribution. You won’t know that today’s customer first arrived from a podcast mention six weeks ago. For long consideration cycles, that’s a meaningful blind spot — though it’s one a CRM handles better than web analytics ever did.

Cohort retention over time. Tracking whether January’s visitors still came back in March requires recognising them in March. Cookieless tools can’t. Product analytics behind a login can, because there you have an account relationship and a lawful basis.

Individual session replay. Watching one person struggle with a form is genuinely useful for UX work. It’s also about as personal as web data gets. If you need it, run it as a consented, time-boxed research exercise rather than always-on collection.

Granular remarketing audiences. Ad platforms want identifiers. If your business depends on precise retargeting, that dependency requires consent, and no amount of tooling avoids it.

My rule of thumb: if you sell something considered over weeks and your marketing is paid-heavy, budget for a consented setup on top. If you publish content, run a service business, or sell things people buy in one sitting, the losses above are mostly theoretical.

Making an Existing Setup Compliant

If you already have tracking running, the work is sequential and none of it requires a rebuild.

1. Inventory what fires. Open the network tab on a fresh visit and list every external domain contacted. Compare that against what you believe is installed — the gap is usually theme and plugin embeds nobody chose.
2. Check device storage. In the application tab, look at cookies and localStorage before you interact with anything. Anything non-essential appearing there pre-consent is your most urgent fix.
3. Kill what you don’t use. Every site I audit has at least one script from a tool abandoned a year ago. Removing it is free compliance.
4. Reduce what remains. Turn off individual-level exports, user-ID features, and demographic enrichment unless something depends on them.
5. Set retention deliberately. Storage limitation under Article 5(1)(e) means picking a number and enforcing it in the tool, not describing one in a policy.
6. Re-test. Repeat step 2 and confirm a first-time visitor now leaves no trace on their own device.

Step 6 is the one people skip, and it’s the one that catches misconfigured consent tools — where the banner is present, blocking is switched on, and a script still fires because it was hard-coded into the theme header rather than loaded through the consent manager.

A Note on National Differences

Supervisory authorities don’t apply identical standards to audience measurement. France’s CNIL publishes conditions under which certain analytics configurations can be exempt from consent — narrow purpose, no cross-site tracking, aggregated reporting only. Other regulators have reached comparable but not identical conclusions, and guidance continues to move.

What this means practically: a setup that never touches the device and never retains personal data is defensible in every EU market, which is why it’s the version I recommend. Anything relying on a specific national exemption needs checking against your own authority’s current position before you lean on it.

For the full operational sweep — records, lawful bases, processor agreements, transfers, and data rights — work through the website GDPR compliance checklist. It covers the obligations that remain even when your tracking itself is clean.

Bottom Line

GDPR compliant tracking is a design decision, not a plugin. Clear both tests — nothing written to the visitor’s device, nothing personal kept on your server — and the heavy obligations simply don’t attach, because there’s no personal data to govern.

Be precise about the vocabulary: hashed and pseudonymised data stays in scope, and only genuinely anonymous aggregates fall outside it. Be honest about the trade-off: you lose multi-session attribution and long-range cohorts, and you keep everything most sites actually use.

If you’re weighing which tool delivers this in practice rather than in marketing copy, I’ve tested the main options in this comparison of privacy-first alternatives. And if the underlying philosophy is new to you, the introduction to privacy-first analytics explains why starting from privacy produces a simpler system, not just a legally safer one.