Is GDPR consent required for analytics?

Analytics is the single most common place EU privacy law trips up SaaS founders. The rule is simpler than it looks: if your analytics involves reading or writing to the user's device (cookies, localStorage, fingerprinting) or processing personal data, you need consent before it fires. Here's the actual law, the narrow exceptions, and what regulators have done about it.

Two laws, two requirements

EU privacy is governed by two overlapping regimes, and both apply to most analytics setups. You need to satisfy both — satisfying one doesn't excuse the other.

• GDPR Art. 6 — requires a lawful basis to process personal data. The options are: consent, contract, legal obligation, vital interests, public task, or legitimate interest.
• ePrivacy Art. 5(3) — requires consent before reading or writing data from the user's device, with narrow exceptions for "strictly necessary" uses.

The trap: ePrivacy applies even if the data being stored isn't personal data. A cookie that holds a session ID still triggers Art. 5(3). So even "anonymized" analytics often needs consent for the cookie itself, separate from any GDPR question about whether the data inside is personal.

What counts as "analytics needing consent"

If your analytics tool does any of the following, treat it as consent-required by default:

1. Sets a cookie, localStorage, or sessionStorage item that identifies a user or session.
2. Sends a hashed user ID, email, or any identifying parameter to a third-party server.
3. Combines IP address with user-agent or other request data to fingerprint the visitor.
4. Tracks across multiple sites — that is, the analytics vendor processes the data for purposes other than just your analytics (this rules out most ad-platform pixels).
5. Loads from a third-party domain on a page where the user hasn't yet given consent.

The narrow exceptions

Two exceptions to the "consent required" default that are worth knowing:

1. Strictly necessary cookies (ePrivacy Art. 5(3)) — cookies that are essential for delivering the service the user explicitly requested. Examples: a shopping-cart cookie, a CSRF token, a logged-in session cookie. Pure analytics is not strictly necessary, by regulator consensus.
2. Aggregated, server-side, first-party analytics — if you collect only aggregate stats (page views, country, no per-user dimension), process them yourself with no third-party transfer, and never read/write to the user's device, you can argue legitimate interest under Art. 6(1)(f) and avoid the Art. 5(3) trigger entirely.

Tools that genuinely fit the second exception: Plausible (no cookies, server-side), Fathom (similar), Simple Analytics (similar), self-hosted Umami. These are deliberately designed to avoid the consent requirement and are widely accepted as low-risk by DPAs.

What regulators have actually fined

Enforcement against SMBs is typically advisory letters and remediation orders — not headline-grabbing fines. But the patterns are clear:

• CNIL (France) — multiple rulings 2022–2024 declaring GA4 transfers unlawful by default. Remediation required.
• Garante (Italy) — similar GA4 ruling 2022, followed by guidance on first-party-server-side workarounds.
• Cerebral (US, HHS OCR 2023) — $7M settlement when Meta Pixel fired on pages mentioning protected health information. This is HIPAA, not GDPR, but the exact same code pattern.
• CNIL Cookie sweep (ongoing) — €100M cumulative fines across Google, Facebook, Amazon, others for cookies set before consent.

Practical implementation

Three patterns work, ranked by simplicity:

1. Use cookie-less first-party analytics (Plausible, Fathom). Skip consent banners entirely for analytics. Easiest path, but you give up some functionality.
2. Wire a consent banner with a working backend. Default all non-essential tags to off. Persist the consent state in localStorage with a 12-month expiry. Use Google Consent Mode v2 / Microsoft UET Consent Mode wherever supported. Free libraries: Cookiebot, Termly, Cookieyes; or roll your own with a `useConsent()` hook.
3. Move analytics fully server-side. Use server-side GTM, Snowplow, or a self-hosted event collector. This still triggers GDPR Art. 6 (you need a basis) but eliminates the Art. 5(3) cookie trigger.

If you've been ignoring this

Most apps in production have been quietly non-compliant on this for years. The risk hasn't been zero, but it hasn't been catastrophic for most operators either. What's changed in 2025–2026:

1. DPAs have moved past warning-letter mode and are starting to issue penalties to non-cooperating SMBs.
2. Privacy class-action firms in Germany and Italy specifically target consent-violating pixels in the consumer sector.
3. The European Accessibility Act (June 2025) brought a parallel layer of compliance review for consumer apps, and many DPAs are using EAA-compliance reviews to also flag privacy issues.

If you have EU users and you've been deferring this, the right next step is to: (1) check whether any tracker fires before consent on your homepage, (2) if so, gate it; (3) if you can't gate easily, switch to a cookie-less first-party analytics tool. None of this is legal advice — for your specific configuration, talk to a privacy attorney.