A Practical Path to Cookieless GDPR Compliant Analytics

Getting cookieless GDPR compliant analytics right takes deliberate design, because dropping cookies alone is not a compliance guarantee.

Cookieless analytics is not automatically GDPR compliant. It is a design direction, not a magic label.

A tool can avoid cookies and still collect personal data. It can hash IP addresses in a way that remains linkable. It can fingerprint devices. It can store detailed event trails that single people out. To build analytics that is genuinely privacy-first, you need to reduce both browser storage and identifiability.

Start With the Two Legal Layers

European analytics touches two related but distinct regimes.

The ePrivacy Directive, implemented through national laws, regulates storing information on or accessing information from a user's terminal equipment. The EDPB's final Guidelines 2/2023 on Article 5(3) make clear that the scope is broader than classic cookies.

The GDPR regulates processing personal data. A setup can avoid cookies but still process personal data if it collects IP addresses, unique IDs, granular location, device fingerprints, or detailed behavior that can identify or single out a person.

So the architecture goal is twofold:

• avoid non-essential browser storage and device access
• minimize or anonymize personal data in the analytics pipeline

What Not to Do

Do not simply replace cookies with fingerprinting. Combining IP address, user agent, timezone, screen size, fonts, language, and device properties to create a stable identifier is still tracking. Fingerprinting is worse than a cookie because users cannot easily see or delete it.

Do not assume hashing equals anonymization. A hash of an IP address and user agent can still be personal data if the same input produces the same output and the controller can link activity over time. The EDPB's GDPR guidance treats pseudonymized data as still personal data when re-identification remains reasonably possible.

Do not send full URLs without sanitization. Query strings often contain personal data, tokens, email addresses, search terms, or ad click IDs.

Do not reuse analytics data for advertising. CNIL's audience measurement guidance treats exempt analytics narrowly: limited purpose, no cross-site tracking, no combining with other data, and no disclosure for unrelated purposes.

A Better Cookieless Architecture

A privacy-first analytics event should be small:

{
  "type": "pageview",
  "path": "/pricing",
  "referrer_host": "example.com",
  "utm_source": "newsletter",
  "utm_medium": "email",
  "country": "DE",
  "device": "desktop"
}

Avoid sending:

• raw IP addresses to long-term storage
• full user agents if a coarse browser/device category is enough
• full query strings
• emails, names, account IDs, wallet addresses, or customer IDs
• free-form form fields
• precise geolocation

Use the IP address only transiently, if needed, to derive coarse country or region. Discard it before persistent storage. If you need bot detection or rate limiting, keep that pipeline separate from analytics reports and apply short retention.

Counting Visits Without Cookies

Counting pageviews is easy without identifiers. Counting visits is harder.

A common privacy-preserving pattern is to create a short-lived derived visit key from request attributes plus a rotating secret salt. For example, a server might derive a key from IP prefix, coarse user agent, site ID, and a salt that rotates daily or more often. The raw inputs are not stored, and the key cannot be used across long periods.

This is still a caveat-heavy approach. It may be pseudonymous rather than anonymous, depending on implementation, retention, and the controller's ability to recompute or link records. Treat it as a minimization technique, not as proof that GDPR no longer applies.

If you can answer the business question with less, do less. Many teams only need pageviews, top pages, referrers, campaigns, and conversions. Unique visitor counts are useful, but not worth invasive tracking.

Consent-Free Analytics: When It Is Plausible

Consent-free analytics is most plausible when:

• no cookies, localStorage, or similar identifiers are used
• no device fingerprint is created
• personal data is not stored, or is anonymized quickly and irreversibly
• data is only used for aggregate audience measurement
• data is not shared with ad networks or reused across customers
• retention is short
• users are informed transparently
• sensitive pages and parameters are excluded

This is why many privacy-first tools are simpler than Google Analytics. Simplicity is not a missing feature. It is the compliance strategy.

Implementation Checklist

Before launch, test the site in a clean browser profile:

1. Open DevTools and confirm no analytics cookies are set.
2. Check localStorage, sessionStorage, IndexedDB, and cache usage.
3. Inspect network requests and confirm analytics payloads are minimal.
4. Confirm query parameters are allowlisted or stripped.
5. Verify that GPC or consent choices disable any advertising tags.
6. Confirm retention settings match your privacy notice.
7. Document the lawful basis and ePrivacy analysis with counsel if you operate in regulated markets.

Compliance Reality Check

Do not treat "cookieless" as a legal conclusion. Before launch, document every event, the decision it supports, whether any device storage or identifier is involved, which vendors receive the data, and when raw records expire.

Then test the site in a clean browser profile and compare the result with the privacy notice. If the browser still shows third-party calls, persistent identifiers, or unplanned query-string data, the compliance story needs more work before the marketing claim goes live.

The Bottom Line

GDPR-aligned cookieless analytics is possible, but only when the system is designed around data minimization. Avoid device storage, avoid cross-site identifiers, avoid ad reuse, and keep reports aggregate.

The lowest-risk analytics setup is the one that answers the business question without needing to know who the visitor is.

Current Regulatory Reality

Do not limit the review to cookies. The EDPB's final Article 5(3) guidance covers access to or storage of information on terminal equipment and discusses techniques such as URL and pixel tracking, local processing, IP-only tracking, and unique identifiers (EDPB Guidelines 2/2023). The UK's ICO also frames cookies, tracking pixels, fingerprinting, and similar methods under storage and access technologies guidance (ICO SAT guidance update).

That means the engineering test is broader than "no cookie appears." Verify no persistent browser storage, no stable device-derived identifier, no third-party pixel before consent, no full URL leakage, and no advertising reuse. If a cookieless setup still singles out visitors over time, the compliance claim is weak.

Frequently Asked Questions

Does removing cookies satisfy GDPR requirements?

Removing cookies addresses the ePrivacy Directive's rules on storing or accessing information on a device, but it says nothing about the GDPR. A tool without cookies can still process personal data by collecting IP addresses, unique IDs, granular location, or device fingerprints, so the architecture has to minimize identifiability as well as browser storage.

Can hashing an IP address make it anonymous under GDPR?

Not on its own. A hash of an IP address and user agent produces the same output for the same input, so a controller who can link that output over time is still processing personal data. The EDPB treats pseudonymized data this way, as personal data whenever re-identification stays reasonably possible.

What counts as personal data in cookieless analytics?

IP addresses, unique IDs, granular location, device fingerprints, and detailed behavior trails all count if they can identify or single out a person. A setup can drop cookies entirely and still process this kind of data, which is why the GDPR layer needs its own analysis separate from the cookie question.

Why is device fingerprinting a bigger privacy risk than cookies?

Fingerprinting combines IP address, user agent, timezone, screen size, fonts, language, and device properties into a stable identifier, which is still tracking. It can be worse than a cookie because users cannot easily see or delete it, so there is no visible control to opt out of.

Can analytics data be reused for advertising?

Reusing analytics data for advertising breaks the narrow exemption that CNIL's audience measurement guidance describes. That exemption requires a limited purpose, no cross-site tracking, no combining with other data, and no disclosure for unrelated purposes, and ad reuse violates several of those conditions at once.

How can visits be counted without setting a cookie?

A common pattern derives a short-lived visit key from request attributes, such as IP prefix, coarse user agent, and site ID, combined with a rotating secret salt. The raw inputs are never stored, and because the salt rotates daily or more often, the key cannot be used to link records across long periods.

Is a derived visit key considered anonymous data?

Not automatically. Depending on the implementation, retention, and whether the controller could recompute or link records, a derived visit key may be pseudonymous rather than anonymous. Treat it as a minimization technique, not as proof that the GDPR no longer applies.

What should an analytics event payload avoid sending?

A privacy-first event should skip raw IP addresses headed for long-term storage, full user agents, full query strings, and fields like emails, names, account IDs, or precise geolocation. Coarse fields such as path, referrer host, UTM parameters, country, and device category usually answer the same business questions without the risk.

When is consent-free analytics legally plausible?

Consent-free analytics is most plausible when no cookies, localStorage, or fingerprints are used and personal data is not stored or is anonymized quickly. Data also stays aggregate, unshared with ad networks, and short in retention. Users still need to be informed transparently, and sensitive pages and parameters should be excluded from collection.

Does the ePrivacy Directive only cover cookies?

The EDPB's Guidelines 2/2023 on Article 5(3) make clear the scope reaches beyond classic cookies, covering things like URL and pixel tracking, local processing, IP-only tracking, and unique identifiers. The UK's ICO frames the same idea under storage and access technologies guidance, covering tracking pixels and fingerprinting alongside cookies.