GDPR-Compliant Analytics: What You Actually Need to Do

Getting analytics GDPR-compliant is not just about adding a cookie banner. It starts earlier: with what data your analytics tool collects and whether that data constitutes personal data under GDPR.

Note: the information below is for orientation. GDPR compliance depends on your specific setup, country, and legal analysis. For binding advice, consult a qualified data protection lawyer.

Step 1: Identify what your analytics tool collects

Before anything else, know what your tool sends. Most analytics tools collect some combination of:

• IP address (or a hash of it)
• User agent (browser, OS)
• Referrer (previous page URL)
• Page URL (current page)
• Timestamp
• Session ID or cookie (persistent identifier)

Under GDPR, IP addresses are personal data. Even a hashed or truncated IP may be personal data if re-identification is possible in context. A persistent cookie identifier that can track a person over time is clearly personal data.

Questions to ask your vendor:

• Is the full IP address sent to your servers?
• Is an IP stored in logs, even temporarily?
• Is a persistent identifier used (cookie, localStorage, fingerprint)?
• Where are the servers? (EU / US / other)

Step 2: Determine if consent is required

Under the EU's ePrivacy Directive (Article 5(3)), storing or accessing information on a user's device requires consent — unless it's "strictly necessary" for the service the user explicitly requested.

This is the rule that drives cookie consent banners. Analytics cookies are not strictly necessary, so they require consent.

For cookieless analytics that doesn't store anything on the device, ePrivacy Article 5(3) doesn't apply directly. But you still need a legal basis under GDPR Article 6 for processing personal data (like an IP address).

The most common bases for cookieless analytics:

• Legitimate interests (Article 6(1)(f)): you have a legitimate interest in understanding your website's traffic, and it doesn't override visitor rights — especially if you don't store IPs, use daily hashing, and don't profile individuals. This requires a Legitimate Interests Assessment (LIA).
• Consent (Article 6(1)(a)): always valid, simplest legally, but requires a functioning consent mechanism.

Note on "no consent needed" claims: be cautious of blanket statements that cookieless analytics never needs consent. This depends on your specific implementation, which country visitors are from, and how your national DPA interprets the rules. Some DPAs take a stricter view than others. According to EDPB Guidelines 2/2023, even cookieless tracking that processes personal data requires a valid legal basis.

Step 3: Write it into your Privacy Policy

Whatever your legal basis, it must be documented in your Privacy Policy under GDPR Article 13. Your privacy policy should state:

• What categories of data are collected via analytics
• Who the data controller is
• What legal basis you rely on
• How long data is retained
• Whether data is transferred outside the EU (and what safeguards apply)
• Who the analytics provider is (as a data processor or sub-processor)

If your analytics provider is US-based (like GA4, with data processed by Google's US infrastructure), you need to address international transfers — either Standard Contractual Clauses (SCCs) or another valid mechanism.

Step 4: Sign a Data Processing Agreement with your analytics vendor

Under GDPR Article 28, if your analytics provider processes personal data on your behalf, they're a data processor. You need a signed DPA with them.

Most major analytics tools provide a standard DPA. Google Analytics offers one; you have to accept it. Privacy-first tools typically make this easier (some are structured as data controllers themselves, removing the DPA requirement for their customers).

Step 5: Data retention

GDPR's storage limitation principle (Article 5(1)(e)) requires you to keep data no longer than necessary. For analytics, consider:

• Raw event logs: typically 30–90 days is defensible; some DPAs expect shorter periods.
• Aggregated data (no individual-level data): can be retained indefinitely, as it no longer constitutes personal data.
• Session and visitor data: depends on whether the data contains IP addresses or identifiers.

Document your retention policy and ensure your vendor enforces it technically, not just contractually.

Step 6: Respond to data subject requests

GDPR gives individuals rights: access, erasure, portability, restriction. For analytics data, this is complex:

• If you can't identify a specific individual in your analytics data (no name, no email), you can't fulfill an access or erasure request for a specific person.
• If your analytics stores persistent identifiers tied to people, you may be able to delete by user ID.

Cookie-free analytics with daily hashed IPs is typically not linkable to individuals without additional data. This limits your ability to respond to specific requests — but it also limits your privacy risk.

What cookie-free analytics changes

Cookie-free analytics reduces (but doesn't eliminate) GDPR obligations:

• ePrivacy Article 5(3) doesn't apply if nothing is stored on the device.
• IP processing still requires a legal basis.
• DPA with your vendor is still needed if they process data on your behalf.
• Privacy policy disclosure is still required.

The main benefit: no consent banner required if you can rely on legitimate interests and your implementation is genuinely minimal (daily hashed IP, no cross-site tracking, EU-hosted servers, short retention).

Practical checklist

• Know exactly what data your analytics tool collects and sends
• Identify your legal basis (consent or LIA for legitimate interests)
• Sign a DPA with your analytics vendor
• Update your privacy policy to disclose analytics data collection
• Set data retention limits and verify your vendor enforces them
• Address international transfers if servers are outside the EU
• If using cookies: implement a compliant consent mechanism (no pre-ticked boxes, no dark patterns, genuine consent before firing tracking)
• If using legitimate interests: document your LIA

Compliance is a process, not a checkbox. Revisit when you change tools, add new features, or when your national DPA publishes new guidance.