Ask a publisher what "personal data" means and you'll usually hear "names, emails, maybe phone numbers." Under GDPR that's a fraction of it — and the gap is exactly where web analytics lives. Understanding the real line explains why cookie banners exist, why GA4 needs consent, and why cookieless analytics is built the way it is. Here's the plain-English version, though as always it's not legal advice.
The definition is broader than you think
GDPR (Article 4(1)) defines personal data as any information relating to an identified or identifiable person. "Identifiable" is the load-bearing word: someone is identifiable if they can be singled out directly or indirectly by an identifier — and Recital 30 spells out that online identifiers count. The EDPB's guidance is blunt: any identifier capable of recognizing a user, even without a name, is personal data. In practice that means web analytics tools, ad platforms, and even plain server logs all generate personal data.
Where the line actually sits
The test isn't "does it have a name?" It's "can it single out one person?" (the standard from Recital 26). By that test, the everyday ingredients of analytics are personal data:
- IP addresses — personal data by default under GDPR. Static IPs unambiguously so; dynamic ones too, because they can be re-identified. "Anonymize IP" doesn't save you: truncation is pseudonymization, not anonymization, and GA4 collects the full IP before masking it anyway.
- Cookie IDs, device IDs, advertising IDs (Google's GAID, Apple's IDFA) — online identifiers that recognize the same visitor across pages.
- Browser fingerprints — combinations of browser and device attributes that single out a device.
- Pseudonymous / hashed IDs — and this is the one that trips people up.
Pseudonymous is not anonymous
Here's the mistake regulators see constantly: a team hashes user IDs, calls the dataset "anonymous," and treats it as outside GDPR. It isn't. Pseudonymization reduces risk but keeps data fully in scope, because re-identification stays possible — via a key you hold, or by combining the data with something else. A SHA-256 hash of an IP, especially without a rotating salt, still singles out a visitor. And if you share pseudonymized data with a party who can re-identify it (an ad network with an identity graph), it's personal data for them regardless.
True anonymization is a much higher bar. The WP29/EDPB standard requires that anonymized data makes it impossible to (1) single out an individual, (2) link two records to the same individual, or (3) infer anything about an individual — and it has to survive ongoing re-identification testing. Only then does data fall outside GDPR. Most "anonymized" analytics is really pseudonymized.
There's also the mosaic effect: fields that look harmless alone — a partial location, a user-agent string, a cluster of timestamps — can together single someone out. So "we don't store names" is not the same as "we don't process personal data."
Why this is the whole point of cookieless analytics
Now the privacy cluster ties together. Every obligation from the GDPR and cookie-banner pieces is triggered by processing personal data. So the cleanest way to shrink those obligations is to design your analytics to sit as close to the anonymous line as possible: don't store IPs, don't assign a persistent cross-session identifier, don't fingerprint. Count what happened without being able to re-identify who.
That's precisely what cookieless, privacy-first analytics aims for — and why it can skip the consent banner and shrink your GDPR surface. A well-designed cookieless tool rotates any salt frequently (so today's visitor count can't be linked to yesterday's) and never retains the raw IP, deliberately breaking the links that would make the data re-identifiable over time.
Honest caveat, because this piece is about not fooling yourself: even a salted, cookieless approach that counts a unique visitor within a single day is arguably pseudonymous for that day — genuinely "anonymous" is a high, fact-specific bar, and no vendor should wave it around loosely. The right claim isn't "zero personal data, guaranteed anonymous"; it's "designed to collect the minimum and avoid persistent, re-identifiable identifiers." That's a meaningful, defensible difference from an IP-storing, cross-session-tracking setup — just not a magic exemption.
Analytics designed to collect the minimum: Clickolytics is cookieless, rotates its visitor salt, and doesn't store raw IPs — built to sit as close to the anonymous line as first-party analytics can. See how it works →
The bottom line
In web analytics, "personal data" isn't about names — it's about whether the data can single out a person. IPs, cookie and device IDs, fingerprints, and hashed identifiers all clear that bar, which is why standard analytics is personal-data processing with the full set of obligations. Only genuinely aggregate, non-re-identifiable data escapes. You can't make GDPR vanish, but you can design your measurement to hug the anonymous line — and that design choice is what the whole cookieless approach is really about. Not legal advice; confirm the specifics for your setup.
Frequently asked questions
Is an IP address personal data? Under GDPR, yes by default (Recital 30, EDPB) — analytics and server logs handling IPs process personal data. "Anonymize IP" is pseudonymization, not anonymization. CCPA is narrower (IP is personal info when linkable to a person/household).
Does personal data need a name? No — the test is "can it single out one person?" A cookie or device ID that recognizes a returning visitor is personal data with no name attached.
Is hashed data still personal data? Yes — pseudonymization keeps data in GDPR scope; re-identification stays possible. Only true, tested anonymization is out of scope.
What analytics data isn't personal? Genuinely aggregate, anonymous stats with no way to single out, link, or re-identify an individual. Persistent per-visitor IDs, stored IPs, or fingerprints cross the line.
Related reading
- GDPR for Affiliate Marketers — the obligations that follow once data is personal.
- Do Affiliate Sites Need a Cookie Banner? — consent, triggered by personal-data processing.
- Cookieless Analytics for Affiliates — designing measurement to hug the anonymous line.
- Privacy-First Analytics vs Google Analytics — why the switch is often a data upgrade.
- How to Track Affiliate Links — first-party tracking basics.