The 2026 EU Consent-Free Analytics Playbook

This is privacy research, not legal advice. See the footer for the full disclaimer.

TL;DR

Running analytics without a banner is achievable in 2026 — under France’s CNIL Sheet 16, Italy’s Garante 2021 guidelines, Spain’s AEPD guide and the Netherlands AP position, plus the strictest current baseline (Germany’s § 25 TDDDG).
Configure for Germany; the rest of the EU composes upward. The cookieless server-side architecture that satisfies § 25 TDDDG satisfies every other Member State’s audience-measurement carve-out by construction.
GA4 fails the exemption in every Member State that has one. Cross-border transfer + cross-customer pooling + persistent identifier + not-single-publisher disqualify it.
The Digital Omnibus Article 88a(3)(c) would harmonise the carve-out EU-wide — but it’s a Commission proposal, not law, and the EDPB-EDPS Joint Opinion 2/2026 of 11 February 2026 raised concerns about the broader package.
Architect for both outcomes. A cookieless first-party deployment satisfies today’s patchwork and is positioned to qualify on day one if Article 88a passes intact.

Why a playbook, and why now

A growing share of EU operators reach the same conclusion at the same time: the cookie banner is a tax on measurement, and the measurement that gets through is increasingly unreliable. Plausible’s cookie-banner study puts the lost-visibility tax at around 55.6% — visitors who arrived on the site, declined the banner, and dropped out of analytics. The CNIL’s twin €325 M Google and €150 M Shein sanctions of 1 September 2025 — both on cookie-consent UX rather than the ad-tech downstream — made the banner itself the regulatory liability, not just the cookies behind it.

There is a legal path to running analytics without a banner across most of the EU. It has been there since the ePrivacy Directive was amended in 2009. France’s CNIL has spent the last decade refining it; Italy’s Garante and Spain’s AEPD have built their own versions; the Commission’s 19 November 2025 Digital Omnibus proposal would, if adopted, harmonise it across all 27 Member States. Germany remains the strict outlier and shapes what is achievable.

This is a working playbook. What “consent-free” actually means in 2026, where each regulator lands, what disqualifies almost every Google Analytics 4 setup, what does keep an operator exempt, why “anonymous” tracking is not what it sounds like, and the configuration we built Statnive Live to be so the work is mostly done in the binary.

Two layers of EU law govern analytics, and both apply at the same time. Failing either is enough to require consent.

Layer 1 — ePrivacy Directive 2002/58/EC, Article 5(3). Consent is required before storing on, or accessing information already stored on, a user’s terminal equipment — except where strictly necessary to transmit a communication, or to provide a service the user expressly requested. The EDPB’s Guidelines 2/2023 version 2.0, adopted 7 October 2024, extended this expressly beyond cookies — pixel tracking, URL tracking, on-device fingerprinting, locally-generated data accessed via API, identifiers hashed on the client, IoT reporting, and IP-only tracking where the operator instructs the device to send information are all in scope. Anything that reads from or writes to the visitor’s device triggers Article 5(3).

Layer 2 — GDPR. Any subsequent personal-data processing needs an Article 6 lawful basis. For analytics that means Article 6(1)(a) consent, Article 6(1)(b) contract, or Article 6(1)(f) legitimate interests. (f) requires a documented Legitimate Interest Assessment under the EDPB Guidelines 1/2024 of 8 October 2024 — interest identification → necessity → balancing test against the data subject’s rights and reasonable expectations.

These two layers compose, they do not substitute. Per EDPB Opinion 5/2019 and reaffirmed by the UK ICO’s finalised April-2026 Storage and Access Technologies guidance, ePrivacy Article 5(3) is lex specialis over GDPR for any storage/access on terminal equipment. Legitimate interest under GDPR Article 6(1)(f) cannot substitute for ePrivacy Article 5(3) consent. Italy’s Garante goes further and expressly prohibits legitimate interest as a basis for cookies and tracking mechanisms.

There are exactly two routes to consent-free analytics that satisfy both layers:

Route 1: Don’t trigger Article 5(3) at all. No cookies, no localStorage, no fingerprinting probes, no client-side identifier reads. The browser sends only what it sends by default (IP, User-Agent, Referer); the server reads those at ingest, computes its analytics, and writes nothing back to the device. This is the only consent-free route available in Germany under § 25 TDDDG, and it is the strict baseline this playbook assumes.
Route 2: Fit a national audience-measurement exemption. France’s CNIL Sheet 16, Italy’s Garante 10 June 2021 Cookie Guidelines, Spain’s AEPD Guide on audience-measurement cookies, and the Netherlands AP’s analytical-cookies position all permit strictly-configured first-party cookies for audience measurement without consent under their respective ePrivacy transpositions. Each exemption has its own conditions. None of them are recognised in Germany.

The robust design is Route 1 by default and Route 2 only when an operator has documented they meet a specific national exemption. Statnive Live ships Route 1 in its consent-free mode and exposes a jurisdiction enum so operators in Sheet-16 countries can layer Route 2 on top.

The 2026 map, at a glance

Where each major EU/EEA regulator lands on consent-free analytics, as of May 2026.

Jurisdiction	Audience-measurement exemption	Notes
France (CNIL)	Yes — Sheet n°16 + 4 July 2025 self-assessment	Most permissive in the EU. Compliance deadline 1 January 2026. Strict conditions: single-site, ≤3 event types, IP last-octet truncation, 13-month tracker lifespan, 25-month data retention. See CNIL deep-dive.
Germany (DSK)	No	§ 25 TDDDG forecloses legitimate interest as a basis for storage/access. Consent-free architecture must be pure server-side processing. See TDDDG deep-dive.
Italy (Garante)	Yes — Cookie Guidelines of 10 June 2021 (in force 10 January 2022)	Conditions: no direct identification, masked-IP cookies, single-site stats, no third-party transmission. Legitimate interest expressly prohibited for cookies.
Spain (AEPD)	Yes — Audience-measurement guide (2024)	Conditions align with CNIL. LSSI Article 22.2 + LOPD-GDD.
Netherlands (AP)	Yes — “Analytical cookies … do not require consent if they are used solely for counting visitors”	Article 11.7a Telecommunicatiewet. AP monitoring 500 sites/year for compliance.
Belgium (APD)	No	”Audience measuring cookies are not exempt from the consent requirement under the current legal framework.”
Ireland (DPC)	No published exemption	Aligns with EDPB Guidelines 5/2020.
UK (ICO)	No — but low enforcement priority	April 2026 ICO Storage and Access Technologies guidance: “Analytics cookies do not fall within the ‘strictly necessary’ exemption.” Low priority for first-party, low-intrusiveness analytics is acknowledged but not codified.
Austria (DSB)	No standalone exemption	NetDoktor decision 22 December 2021 found GA EU→US transfer unlawful on Schrems-II grounds.

The country-by-country reference map covers the remaining EU/EEA jurisdictions and the operator’s “OTHER-EU” and “OTHER-NON-EU” bucket questions.

The practical effect of this map: an operator who configures for Germany — the strictest cell — is configured for everywhere else in the EU. An operator who configures for France’s Sheet 16 captures France, Italy, Spain and the Netherlands cleanly, but still needs the Germany-grade architecture if any traffic is German. Configure for Germany; it composes upward.

The seven do-not-do’s that disqualify almost every GA4 setup

This is the operator’s negative checklist. Any one of these, in any jurisdiction in the map above, knocks an analytics deployment out of consent-free territory and back into “needs a banner with a Reject button that is as easy as Accept.”

1. Don’t set a tracking cookie or write to localStorage without consent. Cookies for audience measurement are permitted under France’s Sheet 16, Spain’s AEPD guide and the Garante’s 2021 guidelines — but only under the strict national-exemption conditions, not by default. localStorage and sessionStorage carry the same Article 5(3) trigger as cookies and have no audience-measurement carve-out anywhere.

2. Don’t use a static or single salt. A static-salt hash of an IPv4 is pseudonymisation, not anonymisation — Italy’s Garante held precisely this in its 9 June 2022 Caffeina Media decision against Google’s IP-anonymisation feature. The IPv4 space is roughly 4.3 billion addresses; a rainbow table of SHA-256(static_salt + IPv4) is trivial on a single GPU. A salt that does not rotate is a salt that does not protect.

3. Don’t store raw IPs or raw User-Agent strings. Both are personal data in practice — the CJEU’s Breyer judgment (C-582/14, 19 October 2016) settled it for dynamic IP. Per CNIL’s July-2025 self-assessment, IPv4 is truncated to /24 (and IPv6 to /48 or /64) and User-Agents are reduced to major versions only (“Chrome 126”, not “Chrome/126.0.6478.127 Mobile Safari/537.36”) before any storage.

4. Don’t use third-party fingerprinting libraries. Canvas, audio context, WebGL parameters, font enumeration, hardware concurrency — these are all in scope of Article 5(3) per EDPB Guidelines 2/2023. FingerprintJS, ClientJS and the various commercial fingerprinting SDKs trigger consent in every EU jurisdiction. Statnive’s GDPR code-review skill bans them in the tracker.

5. Don’t cross-reference with customer CRMs or other site data. The CNIL Sheet 16 condition is explicit: “aucune mise en commun par le prestataire de données brutes de mesure d’audience provenant de plusieurs de ses clients n’est mise en œuvre.” No data pooling across the provider’s customers; no joins with other internal datasets that would build cross-context profiles.

6. Don’t reuse identifiers across customer sites. The same visitor on two different sites must produce two unrelated signatures. CNIL Sheet 16: “Aucun identifiant permettant un suivi à travers plusieurs domaines n’est utilisé.” This is why Fathom and Statnive both use a site-scoped salt component — the same person visiting two different sites generates two unlinkable hashes by construction.

7. Don’t transfer personal data to the US or other third countries without verified Chapter V cover. The 2022 Austrian DSB NetDoktor, French CNIL, Italian Garante and Danish DPA decisions banning Google Analytics on Schrems-II grounds have not been reversed by any 2024–2026 ruling. The current EU-US Data Privacy Framework (effective July 2023) provides interim cover but is the subject of pending Latombe and parallel noyb challenges. The architecturally durable answer is EU-only.

GA4 fails at minimum points 1 (persistent identifier), 5 (Google’s cross-customer ecosystem), 6 (cross-site identifier), and 7 (US data transfer). The CNIL’s verbatim conclusion in Sheet 16: “Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration.”

The five do’s that keep you exempt

These are the conditions that — applied together — let a first-party analytics stack qualify for the strictest current regime (§ 25 TDDDG) and the most permissive national exemption (CNIL Sheet 16) simultaneously. They are also the architecture the Digital Omnibus Article 88a(3)(c) proposal would standardise across the EU if adopted intact.

1. Daily rotating, site-scoped salt with destruction. Visitor signatures are derived as BLAKE3-HMAC(master_secret, site_id || YYYY-MM-DD). The salt is computed in-process, never stored, and the previous day’s salt is destroyed at rotation. Same visitor on Monday and Tuesday → two different signatures; cross-day re-identification is impossible by construction. Same visitor on two different sites → two unlinkable signatures; cross-site re-identification is impossible by construction. This is the Plausible construction (hash(daily_salt + website_domain + ip_address + user_agent)) plus a salt-deletion guarantee.

2. IP truncation before any storage. Remove at least the last octet of IPv4 (203.0.113.42 → 203.0.113.0/24). For IPv6, keep only the network prefix — typically /48 or /64. The raw IP is allowed to exist briefly in the request path for the GeoIP lookup; it must be discarded before the batch writer sees the row. Geolocation degrades to city/region — the CNIL ceiling.

3. User-Agent minimisation and host-only referrer. UAs reduced to device + major-browser-version + major-OS-version, parsed server-side, raw string discarded. Referrer reduced to host only (example.com, not example.com/search?q=secret) before storage — eliminates accidental PII in query strings. Both are CNIL Sheet 16 conditions and both happen at ingest in Statnive Live’s server.

4. No cookies, no localStorage, no fingerprinting. Article 5(3) ePrivacy doesn’t fire because no terminal-equipment storage or access happens. Verify in your browser DevTools → Application → Storage; quotas remain at zero. No canvas, WebGL, font-enumeration, audio-context, or navigator.plugins probes either — those are all client-side reads that EDPB Guidelines 2/2023 puts in scope of Article 5(3).

5. Bounded retention with a documented LIA. CNIL’s 13-month tracker-lifespan and 25-month data-retention ceilings are the strictest current European bars. Aggregate dashboard outputs to nearest 10 (or document an anonymity analysis citing the WP29/EDPB anonymisation Opinion). Maintain a Legitimate Interest Assessment per EDPB Guidelines 1/2024 — DPO involvement, three-step test, refreshed annually or on material change. A DPIA under Article 35 GDPR for high-volume, sensitive-vertical, or feature-rich deployments.

These five points are the architecture. They do not depend on the Digital Omnibus passing. They survive the strictest current Member-State regime. And they compose into a single configuration that the operator does not have to swap out as case law shifts.

Why “anonymous” is not enough — the pseudonymisation distinction

Operators who have spent any time reading their analytics vendors’ marketing pages will have read the word “anonymous” applied to hashed IPs and cookie-free tracking. The word is doing legal work the GDPR does not permit.

The draft EDPB Guidelines 01/2025 on Pseudonymisation — adopted as a draft at the 101st plenary on 16 January 2025, open for public consultation through 28 February 2025, and still in development as of May 2026 — clarify that pseudonymised data, including hashed IPs, cookie IDs, BLAKE3/HMAC visitor signatures, and TC strings, remains personal data when re-identification is reasonably likely via means available to the controller or to any third party. The CJEU’s IAB Europe judgment (C-604/22, 7 March 2024) extended this beyond TC strings to any identifier paired with an IP.

Practically:

A cookie-free tracking system with a daily-rotating salt is pseudonymous within the day and only becomes anonymous across days — and only because the previous day’s salt is destroyed.
A static-salt IP hash is pseudonymous indefinitely and is reversible by anyone with a GPU and a list of candidate IPs.
A “city-level” geolocation derived from a /24 IP truncation is pseudonymous per Breyer — but the truncation removes the most-reversible identifier from the storage layer, which is what the GDPR Article 5(1)(c) data-minimisation principle and the CNIL Sheet 16 condition both require.

The robust posture: treat hashed visitor identifiers as low-risk personal data. Apply the Article 6(1)(f) legitimate-interest basis to their processing. Document the LIA. Honour Article 15 access and Article 17 erasure requests against them via a DSAR endpoint. Do not market them as “anonymous.” That word is for data where re-identification is not reasonably likely by anyone, ever — and a hashed IP cleared by a state’s lawful-access powers does not meet that bar.

This is also why Italy’s Garante found Google’s IP-anonymisation feature insufficient in its Caffeina Media decision: “the feature constitutes a pseudonymisation of the IP address, and not anonymisation. … the feature does not prevent Google LLC from re-identifying the user, given Google’s capabilities to enrich such data through additional information it holds.” The feature did exactly what its marketing said. It just was not anonymisation in the GDPR sense.

How Statnive Live is built for this

Statnive Live was designed against the do’s and don’ts above. The architecture is what the Hetzner-hosted Nuremberg server runs by default; the same binary is also self-hostable on customer infrastructure, in which case nothing is processed by Statnive at all.

Cookieless by construction. No cookies, no localStorage, no sessionStorage. Article 5(3) ePrivacy does not fire because no terminal-equipment storage or access happens. The tracker is a ~2.0 KB minified / ~0.9 KB gzipped first-party script served from the same domain as the operator’s site — no third-party CDN, no third-party tag manager.

Daily-rotating BLAKE3-HMAC visitor signatures. Hashes derive as HMAC(master_secret, site_id || YYYY-MM-DD). The salt is in-process; the previous day’s salt is destroyed at rotation. The construction matches the Plausible / Fathom approach and adds a site-level component so a visitor on two Statnive-tracked sites generates two unlinkable signatures.

Hashed cookie ID at rest. When an operator runs Statnive Live in consent-required or hybrid mode with consent given, the cookie ID emitted to the browser is a raw UUID; the value stored server-side is SHA-256(master_secret || site_id || cookieID) with a h: prefix. The browser sees the raw UUID; the database never does. Cross-day visitor continuity is preserved without storing the raw identifier.

Server-side host-only referrer. The tracker stores the full document.referrer; at ingest, the server reduces it to the host portion before write. Query strings (which may carry search terms or PII) never enter persistent storage.

Raw IP discarded before storage. The IP exists in the request path for the GeoIP lookup and the hash derivation; it is discarded before the batch writer sees the row. Verified by an integration test in internal/enrich/geoip.go of the Statnive Live repository.

25-month rollup retention. A 750-day TTL is enforced on the v1 AggregatingMergeTree rollups (hourly_visitors, daily_pages, daily_sources) — 24.6 months, matching the CNIL ceiling with margin. Beyond that, the rollups expire automatically without operator intervention.

Four consent modes, eleven jurisdictions, hard-rule validation. The site policy carries a consent-mode enum (permissive / consent-free / consent-required / hybrid) and a jurisdiction enum (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU). A hard-rule validator prevents German operators from selecting permissive (§ 25 TDDDG forbids it) and from selecting consent-required without an active consent integration. The validator runs on save in the admin and again at policy load on every ingest request. The TDDDG deep-dive covers the Germany cell in detail.

GPC and DNT short-circuit before the hash. When Sec-GPC: 1 or DNT: 1 is set and the site policy honours those signals, the request is dropped before the visitor identifier is computed. No pseudonymous identifier is generated for a declining visitor — there is nothing to delete because nothing was created. The GPC and hybrid-mode post walks through the end-to-end test plan.

DSAR endpoints out of the box. POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase — CSRF-protected, rate-limited, audit-logged. Eight privacy audit events (privacy.opt_out_received, privacy.dsar_access_requested, privacy.dsar_erase_requested, privacy.consent_given, privacy.consent_withdrawn, legal.lia_viewed, legal.dpa_viewed, legal.privacy_policy_viewed) emit structured logs ready for an Article 28(3)(h) accountability audit. The DSAR post covers the integration surface.

Public legal disclosure routes embedded in the binary. /privacy, /legal/privacy-policy/en, /legal/privacy-policy/de, /legal/lia and /legal/dpa are served by the same Go binary as the tracker — no CDN dependency, air-gap-safe, accessible to operators running Statnive Live in restricted-egress environments.

The result is a configuration that satisfies Germany’s strict bar today, qualifies under France’s Sheet 16 with a documented self-assessment, and is positioned to qualify under the proposed Article 88a(3)(c) on day one if the Digital Omnibus passes intact. Operators do not have to choose; the same site policy carries forward.

What’s coming — Article 88a(3)(c)

The European Commission’s Digital Omnibus proposal of 19 November 2025 — COM(2025) 837 final — would introduce a new Article 88a GDPR with a closed list of no-consent purposes. The relevant subparagraph for analytics is 88a(3)(c): “creating aggregated information about the usage of an online service to measure the audience of such a service, where it is carried out by the controller of that online service solely for its own use.”

Status as of mid-May 2026: the file has ITRE rapporteur Aura Salla (EPP/FI — appointment contested by seven civil-society organisations over a Meta lobbying conflict) and LIBE rapporteur Marina Kaljurand (S&D/EE); the EESC adopted its opinion on 18 March 2026; the Council Working Party is in active discussion (file WK 3736/2026 INIT). There is no European Parliament plenary vote on COM(2025) 837 yet — a 26 March 2026 plenary vote on the separate Digital Omnibus on AI file is a different proposal. The EDPB-EDPS Joint Opinion 2/2026 of 11 February 2026 raised serious concerns about the broader package’s effect on individual protection and legal certainty. Realistic adoption is late 2026 to 2027; entry into force probably 2027 to 2028; Article 88a applying six months after entry into force.

Three implications for operators:

The configuration in this playbook is forward-compatible. First-party, aggregated, controller-only-use audience measurement is exactly the use case Article 88a(3)(c) describes. Operators who deploy the do’s above qualify today under national exemptions where they exist, and qualify tomorrow under EU-wide Article 88a if it passes intact.
The proposal is a layer shift, not a parallel addition. For personal-data terminal-equipment access, Article 88a GDPR would govern and ePrivacy 5(3) would stop applying to those operations. For non-personal-data terminal-equipment access (a narrower residual), ePrivacy 5(3) continues to govern. The two frameworks would operate sequentially, not in parallel. The cleanest position remains “no terminal-equipment storage or access in the first place” — that sidesteps both layers.
The text is a roadmap, not a present legal basis. Operators who design only for the Digital Omnibus and not for current Member-State law will spend the next 12-18 months in a regulatory gap.

How to deploy this playbook

A practical deployment sequence for an operator picking up Statnive Live (or replicating the architecture on a self-hosted stack):

Pick your strictest jurisdiction. If any traffic is German, configure for DE / consent-free. The hard-rule validator does this for you and refuses permissive configurations.
Publish a Legitimate Interest Assessment. The EDPB Guidelines 1/2024 template is the canonical structure: interest identification → necessity → balancing. Download the LIA template for Statnive Live’s recommended language; adapt to your processing context with counsel.
Publish a privacy notice. EN and DE clauses are embedded in Statnive Live at /legal/privacy-policy/en and /legal/privacy-policy/de. The German clause carries the verbatim § 25 Abs. 1 TDDDG language about no terminal-equipment storage or access; the English clause covers the Article 6(1)(f) basis and the CNIL Sheet 16 attestation pattern.
Wire the DSAR endpoints. Three routes (/api/privacy/opt-out, /api/privacy/access, /api/privacy/erase) are exposed by the binary. The DSAR post covers the integration; the audit-log surface is wired by default.
Honour GPC by default in EU mode. Set consent.respect_gpc = true on every German, French, Italian and Dutch site. The GPC post explains the client-side short-circuit + server-side enforcement layers.
Run the event-audit endpoint monthly. GET /api/admin/event-audit?site_id=N returns the per-site unique-event-name count vs the CNIL three-event ceiling. Aim for ok status; investigate any over immediately.
Review the LIA annually. The EDPB recommends annual refresh and on material change — for example, on Digital Omnibus adoption, on a CJEU referral that affects DPF status, or on a national regulator publishing fresh guidance.

The country-by-country reference map is the lookup table for the per-jurisdiction details. The three existing privacy posts — Why Privacy-First Analytics Matter in 2026, GDPR-Compliant Web Analytics in 2026, and Own Your Analytics Data: Self-Hosted vs Private EU SaaS in 2026 — cover the broader landscape and the controller-vs-processor angle.

What to do, and what to skip — the compressed map

The body sections above carry the full “Seven do-not-do’s” and “Five do’s” lists. The compressed version, for operators who scan first:

Do	Don’t
Configure for the strictest Member-State regime (Germany’s § 25 TDDDG) — the rest of the EU composes upward.	Configure separately for each Member State you have traffic in — that’s the path to 27 different LIAs you’ll never refresh.
Use a daily-rotating, site-scoped salt; destroy yesterday’s salt at end of day.	Use a static salt — a single GPU and an IPv4 rainbow table reverse it; the Garante said so in Caffeina Media.
Truncate IPv4 to /24 and IPv6 to /48 before any storage; reduce User-Agent to major versions; reduce Referer to host.	Store raw IPs, raw User-Agents, or full referrer URLs — all are personal data; raw query strings leak PII.
Publish a documented Legitimate Interest Assessment per EDPB Guidelines 1/2024 and the country-specific self-assessment.	Claim “CNIL-certified” or use the CNIL logo. The CNIL retired its evaluation programme on 1 January 2026 — operators self-assess.
Honour GPC and DNT by default in EU mode; honour Article 21 right-of-object with a persistent opt-out link.	Treat hashed visitor IDs as “anonymous” data — they’re pseudonymous under the draft EDPB 01/2025 guidelines, full personal data under Breyer.

The bottom line

Consent-free analytics in the EU is achievable in 2026. It is not achievable by accident, and it is not achievable by configuring a US-based analytics tool to “anonymise” IPs. It is achievable by designing the storage/access trigger out of the system, deriving signatures that destroy themselves, truncating identifying data at ingest, and documenting the legitimate-interest basis under the EDPB three-step test. The architecture is the compliance; the contract is the audit trail.

Configure for Germany; you are configured for everywhere else. Run an LIA; you have a basis to point at. Honour GPC; you have a presumption of compliance under the proposed Article 88b. Bound your retention to 25 months; you sit inside the CNIL ceiling without effort. Skip cookies entirely; you skip the cookie-banner-UX regulatory liability that produced €475M of CNIL sanctions in September 2025.

That is what Statnive Live is for. Cookieless. EU-only. Daily-rotating salts. Hashed cookie ID at rest. Host-only referrer. 25-month retention. Four consent modes, eleven jurisdictions, hard-rule validation. DSAR endpoints, LIA template, privacy-policy and DPA templates in the binary, downloadable without a sales call.

If this playbook helps you tighten one piece of your current analytics stack, that is what it is for. If it convinces you to switch — that is what statnive.com/live is for. Either way, the do’s and don’ts above are the durable architecture; the case law and the proposals will continue to shift around them, and the playbook is built so the operator does not have to re-architect every time.

This is privacy research, not legal advice. The configurations described qualify under regulator guidance when deployed per a documented Legitimate Interest Assessment and the relevant per-country self-assessment. Every Statnive customer remains the data controller and bears responsibility for its own configuration and DPIA. Cross-reference with qualified counsel in your jurisdiction before publication.

Status of regulatory references as of 13 May 2026: CNIL Sheet 16 + 4 July 2025 update (compliance deadline 1 January 2026 has now passed; legacy evaluation programme retired; self-assessment regime operative); TDDDG § 25 (in force 1 December 2021, renamed May 2024); Italian Garante Cookie Guidelines of 10 June 2021 (in force 10 January 2022); AEPD Guide on cookies (July 2023, enforced 11 January 2024); Dutch AP analytical-cookies position (Article 11.7a Telecommunicatiewet); UK ICO Storage and Access Technologies guidance (29 April 2026); EDPB Guidelines 2/2023 v2.0 (7 October 2024); EDPB Guidelines 1/2024 (8 October 2024); draft EDPB Guidelines 01/2025 on Pseudonymisation (adopted as draft 16 January 2025; public consultation through 28 February 2025; final not yet published as of May 2026); EDPB-EDPS Joint Opinion 2/2026 of 11 February 2026 on the Digital Omnibus; Digital Omnibus COM(2025) 837 final (Commission proposal of 19 November 2025, no European Parliament plenary vote on COM(2025) 837 as of 13 May 2026); CJEU C-582/14 Breyer (ECLI:EU:C:2016:779); CJEU C-604/22 IAB Europe (7 March 2024); CJEU C-621/22 KNLTB (ECLI:EU:C:2024:857); CJEU C-446/21 Schrems v Meta (4 October 2024).