Der EU-Leitfaden für einwilligungsfreie Webanalyse 2026

Dies ist Datenschutz-Forschung, keine Rechtsberatung. Den vollständigen Haftungsausschluss finden Sie in der Fußnote.

TL;DR

Webanalyse ohne Banner ist 2026 machbar — unter Frankreichs CNIL Sheet 16, Italiens Garante-Leitlinien von 2021, Spaniens AEPD-Leitfaden und der niederländischen AP-Position, plus dem strengsten aktuellen Standard (Deutschlands § 25 TDDDG).
Konfigurieren Sie für Deutschland; der Rest der EU baut darauf auf. Die cookielose Server-Side-Architektur, die § 25 TDDDG erfüllt, erfüllt jede andere Mitgliedstaat-Reichweitenmessungs-Ausnahme durch Konstruktion.
GA4 scheitert an der Ausnahme in jedem Mitgliedstaat, der eine hat. Drittland-Transfer + kunden-übergreifendes Pooling + persistenter Identifier + nicht-alleiniger-Herausgeber disqualifizieren es.
Artikel 88a Abs. 3 lit. c des Digital Omnibus würde die Ausnahme EU-weit harmonisieren — aber das ist ein Kommissionsvorschlag, kein Gesetz; die gemeinsame Stellungnahme 2/2026 des EDPB-EDPS vom 11. Februar 2026 hat Bedenken zum Gesamtpaket geäußert.
Architektur für beide Szenarien. Ein cookieloses First-Party-Deployment erfüllt den heutigen Flickenteppich und ist positioniert, um am ersten Tag zu qualifizieren, falls Artikel 88a unverändert verabschiedet wird.

Warum ein Leitfaden, und warum jetzt

Ein wachsender Anteil der EU-Betreiber kommt zur gleichen Zeit zum gleichen Schluss: Das Cookie-Banner ist eine Messsteuer, und die Messung, die durchkommt, wird zunehmend unzuverlässig. Plausibles Cookie-Banner-Studie beziffert die Sichtbarkeitsverlust-Steuer auf etwa 55,6 % — Besucher, die auf der Website ankamen, das Banner ablehnten und aus der Webanalyse herausfielen. Die zwei Sanktionen der CNIL über €325 Mio. gegen Google und €150 Mio. gegen Shein vom 1. September 2025 — beide gegen Cookie-Banner-UX statt der Ad-Tech-Strecke dahinter — machten das Banner selbst zur regulatorischen Haftung, nicht nur die Cookies hinter ihm.

Es gibt einen rechtlichen Weg, Webanalyse ohne Banner über den Großteil der EU zu betreiben. Er existiert, seit die ePrivacy-Richtlinie 2009 geändert wurde. Frankreichs CNIL hat das letzte Jahrzehnt damit verbracht, ihn zu verfeinern; Italiens Garante und Spaniens AEPD haben eigene Versionen entwickelt; der Digital-Omnibus-Vorschlag der Kommission vom 19. November 2025 würde ihn, sofern verabschiedet, über alle 27 Mitgliedstaaten harmonisieren. Deutschland bleibt der strenge Ausreißer und formt, was erreichbar ist.

Dies ist ein praktischer Leitfaden. Was „einwilligungsfrei” 2026 tatsächlich bedeutet, wo jede Behörde landet, was fast jede Google-Analytics-4-Konfiguration disqualifiziert, was einen Betreiber doch ausgenommen hält, warum „anonymes” Tracking nicht das ist, wonach es klingt, und die Konfiguration, in die wir Statnive Live gebaut haben, sodass die Arbeit größtenteils bereits im Binary erledigt ist.

Was „einwilligungsfrei” tatsächlich bedeutet

Zwei Schichten EU-Recht regeln Webanalyse, und beide gelten gleichzeitig. Wenn eine versagt, ist die Folge eine Einwilligungspflicht.

Schicht 1 — ePrivacy-Richtlinie 2002/58/EG, Artikel 5 Absatz 3. Einwilligung ist erforderlich, bevor auf einem Endgerät des Nutzers gespeichert oder auf bereits gespeicherte Informationen zugegriffen wird — außer wenn unbedingt erforderlich, um eine Kommunikation zu übertragen oder einen ausdrücklich vom Nutzer angeforderten Dienst zu erbringen. Die Leitlinien 2/2023 Version 2.0 des EDPB, angenommen am 7. Oktober 2024, dehnten dies ausdrücklich über Cookies hinaus aus — Pixel-Tracking, URL-Tracking, On-Device-Fingerprinting, lokal generierte Daten via API, im Client gehashte Kennungen, IoT-Reporting und IP-only-Tracking, wenn der Betreiber das Gerät anweist, Informationen zu senden, fallen alle in den Anwendungsbereich. Alles, was vom Gerät des Besuchers liest oder darauf schreibt, löst Artikel 5 Abs. 3 aus.

Schicht 2 — DSGVO. Jede nachfolgende Verarbeitung personenbezogener Daten benötigt eine Rechtsgrundlage gemäß Artikel 6. Für Webanalyse bedeutet das Artikel 6 Abs. 1 lit. a (Einwilligung), Artikel 6 Abs. 1 lit. b (Vertrag) oder Artikel 6 Abs. 1 lit. f (berechtigte Interessen). (f) erfordert eine dokumentierte Interessenabwägung gemäß den EDPB-Leitlinien 1/2024 vom 8. Oktober 2024 — Interessenidentifikation → Erforderlichkeit → Abwägung gegenüber den Rechten und vernünftigen Erwartungen der betroffenen Person.

Diese zwei Schichten ergänzen sich, sie ersetzen sich nicht. Per EDPB-Stellungnahme 5/2019, bekräftigt durch die im April 2026 finalisierte Storage and Access Technologies Guidance des UK-ICO, ist ePrivacy Artikel 5 Abs. 3 lex specialis gegenüber der DSGVO für jegliche Speicherung/jeden Zugriff auf Endgeräten. Das berechtigte Interesse gemäß DSGVO Artikel 6 Abs. 1 lit. f kann die Einwilligung gemäß ePrivacy Artikel 5 Abs. 3 nicht ersetzen. Italiens Garante geht weiter und verbietet ausdrücklich berechtigtes Interesse als Grundlage für Cookies und Tracking-Mechanismen.

Es gibt genau zwei Wege zu einwilligungsfreier Webanalyse, die beide Schichten erfüllen:

Weg 1: Artikel 5 Abs. 3 gar nicht erst auslösen. Keine Cookies, kein localStorage, keine Fingerprinting-Proben, keine Client-seitigen Identifier-Reads. Der Browser sendet nur das, was er standardmäßig sendet (IP, User-Agent, Referer); der Server liest diese beim Eingang, berechnet seine Webanalyse und schreibt nichts an das Gerät zurück. Dies ist der einzige einwilligungsfreie Weg, der in Deutschland gemäß § 25 TDDDG zur Verfügung steht, und es ist die strenge Basis, von der dieser Leitfaden ausgeht.
Weg 2: In eine nationale Reichweitenmessungs-Ausnahme passen. Frankreichs CNIL Sheet 16, Italiens Garante Cookie-Leitlinien vom 10. Juni 2021, Spaniens AEPD-Leitfaden zu Reichweitenmessungs-Cookies und die niederländische AP-Analytische-Cookies-Position erlauben alle streng konfigurierte First-Party-Cookies für Reichweitenmessung ohne Einwilligung gemäß ihren jeweiligen ePrivacy-Umsetzungen. Jede Ausnahme hat eigene Bedingungen. Keine davon wird in Deutschland anerkannt.

Das robuste Design ist standardmäßig Weg 1 und Weg 2 nur, wenn ein Betreiber dokumentiert hat, dass er eine spezifische nationale Ausnahme erfüllt. Statnive Live liefert Weg 1 in seinem consent-free-Modus aus und stellt einen Jurisdiktions-Enum zur Verfügung, sodass Betreiber in Sheet-16-Ländern Weg 2 darüberlegen können.

Die Karte 2026 auf einen Blick

Wo jede wichtige EU-/EWR-Behörde Stand Mai 2026 zur einwilligungsfreien Webanalyse steht.

Jurisdiktion	Reichweitenmessungs-Ausnahme	Hinweise
Frankreich (CNIL)	Ja — Sheet n°16 + Selbstbewertung vom 4. Juli 2025	Am permissivsten in der EU. Compliance-Deadline 1. Januar 2026. Strenge Bedingungen: Einzelseite, ≤3 Ereignistypen, IPv4 letztes Oktett gekürzt, 13-Monats-Tracker-Laufzeit, 25-Monats-Datenaufbewahrung. Siehe CNIL-Tiefenanalyse.
Deutschland (DSK)	Nein	§ 25 TDDDG schließt berechtigtes Interesse als Grundlage für Speicherung/Zugriff aus. Einwilligungsfreie Architektur muss reine Server-seitige Verarbeitung sein. Siehe TDDDG-Tiefenanalyse.
Italien (Garante)	Ja — Cookie-Leitlinien vom 10. Juni 2021 (in Kraft seit 10. Januar 2022)	Bedingungen: keine direkte Identifikation, IP-maskierte Cookies, Einzelseiten-Statistiken, keine Drittübermittlung. Berechtigtes Interesse ausdrücklich verboten für Cookies.
Spanien (AEPD)	Ja — Reichweitenmessungs-Leitfaden (2024)	Bedingungen entsprechen CNIL. LSSI Artikel 22.2 + LOPD-GDD.
Niederlande (AP)	Ja — „Analytische Cookies … erfordern keine Einwilligung, wenn sie ausschließlich zur Zählung von Besuchern verwendet werden”	Artikel 11.7a Telecommunicatiewet. AP überwacht 500 Websites pro Jahr auf Compliance.
Belgien (APD)	Nein	„Reichweitenmessungs-Cookies sind im aktuellen Rechtsrahmen nicht vom Einwilligungserfordernis ausgenommen.”
Irland (DPC)	Keine veröffentlichte Ausnahme	Stimmt mit EDPB-Leitlinien 5/2020 überein.
UK (ICO)	Nein — aber niedrige Vollzugspriorität	ICO Storage and Access Technologies Guidance vom April 2026: „Analytische Cookies fallen nicht unter die Ausnahme ‚unbedingt erforderlich’.” Niedrige Priorität für First-Party-, geringe-Intrusivitäts-Webanalyse anerkannt aber nicht kodifiziert.
Österreich (DSB)	Keine eigenständige Ausnahme	NetDoktor-Entscheidung vom 22. Dezember 2021 fand GA EU→US-Transfer aus Schrems-II-Gründen rechtswidrig.

Die Land-für-Land-Referenzkarte deckt die verbleibenden EU-/EWR-Jurisdiktionen und die Fragen zum „OTHER-EU”- und „OTHER-NON-EU”-Bucket des Betreibers ab.

Der praktische Effekt dieser Karte: Ein Betreiber, der für Deutschland konfiguriert — die strengste Zelle —, ist auch für alle anderen EU-Standorte konfiguriert. Ein Betreiber, der für Frankreichs Sheet 16 konfiguriert, erfasst Frankreich, Italien, Spanien und die Niederlande sauber, benötigt aber dennoch die Deutschland-Architektur, falls Traffic aus Deutschland kommt. Konfigurieren Sie für Deutschland; es baut nach oben hin auf.

Die sieben Don’ts, die fast jede GA4-Konfiguration disqualifizieren

Dies ist die Negativ-Checkliste des Betreibers. Jeder dieser Punkte, in jeder Jurisdiktion in der obigen Karte, drängt ein Webanalyse-Deployment aus dem einwilligungsfreien Bereich zurück zu „benötigt ein Banner mit einer Reject-Schaltfläche, die genauso einfach wie Accept ist”.

1. Setzen Sie kein Tracking-Cookie und schreiben Sie ohne Einwilligung nicht in localStorage. Cookies zur Reichweitenmessung sind unter Frankreichs Sheet 16, Spaniens AEPD-Leitfaden und den Garante-Leitlinien von 2021 zugelassen — aber nur unter den strengen nationalen Ausnahmebedingungen, nicht standardmäßig. localStorage und sessionStorage tragen denselben Artikel-5(3)-Auslöser wie Cookies und haben nirgends eine Reichweitenmessungs-Ausnahme.

2. Verwenden Sie keinen statischen oder einzelnen Salt. Ein Statisch-Salt-Hash einer IPv4 ist Pseudonymisierung, keine Anonymisierung — Italiens Garante hat dies in seiner Caffeina-Media-Entscheidung vom 9. Juni 2022 gegen Googles IP-Anonymisierungsfunktion genau so festgestellt. Der IPv4-Raum umfasst etwa 4,3 Milliarden Adressen; eine Rainbow-Table von SHA-256(static_salt + IPv4) ist auf einer einzigen GPU trivial. Ein Salt, der nicht rotiert, ist ein Salt, der nicht schützt.

3. Speichern Sie keine rohen IPs oder rohen User-Agent-Strings. Beide sind in der Praxis personenbezogene Daten — das EuGH-Urteil Breyer (C-582/14, 19. Oktober 2016) hat es für dynamische IPs geklärt. Per CNIL-Selbstbewertung vom Juli 2025 wird IPv4 auf /24 gekürzt (und IPv6 auf /48 oder /64) und User-Agents werden vor jeder Speicherung auf Hauptversionen reduziert („Chrome 126”, nicht „Chrome/126.0.6478.127 Mobile Safari/537.36”).

4. Verwenden Sie keine Drittanbieter-Fingerprinting-Bibliotheken. Canvas, Audio-Kontext, WebGL-Parameter, Font-Aufzählung, Hardware-Parallelität — diese fallen alle gemäß EDPB-Leitlinien 2/2023 unter Artikel 5 Abs. 3. FingerprintJS, ClientJS und die verschiedenen kommerziellen Fingerprinting-SDKs lösen in jeder EU-Jurisdiktion eine Einwilligungspflicht aus. Statnives GDPR-Code-Review-Skill verbietet sie im Tracker.

5. Verknüpfen Sie nicht mit Kunden-CRMs oder anderen Site-Daten. Die CNIL-Sheet-16-Bedingung ist explizit: „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.” Keine Datenpoolung über die Kunden des Anbieters; keine Joins mit anderen internen Datensätzen, die Cross-Kontext-Profile aufbauen würden.

6. Verwenden Sie keine Identifier über Kunden-Sites hinweg. Derselbe Besucher auf zwei verschiedenen Sites muss zwei unabhängige Signaturen erzeugen. CNIL Sheet 16: „Aucun identifiant permettant un suivi à travers plusieurs domaines n’est utilisé.” Deshalb verwenden Fathom und Statnive beide eine site-bezogene Salt-Komponente — dieselbe Person, die zwei verschiedene Sites besucht, erzeugt durch Konstruktion zwei nicht verknüpfbare Hashes.

7. Übertragen Sie keine personenbezogenen Daten in die USA oder andere Drittländer ohne nachgewiesene Kapitel-V-Abdeckung. Die Entscheidungen aus 2022 — österreichischer DSB NetDoktor, französische CNIL, italienischer Garante und dänische DPA, die Google Analytics aus Schrems-II-Gründen verbieten — wurden durch kein Urteil von 2024-2026 aufgehoben. Der aktuelle EU-US Data Privacy Framework (in Kraft seit Juli 2023) bietet vorläufige Deckung, ist aber Gegenstand laufender Latombe- und paralleler noyb-Klagen. Die architektonisch dauerhafte Antwort ist EU-only.

GA4 scheitert mindestens an den Punkten 1 (persistenter Identifier), 5 (Googles kunden-übergreifendes Ökosystem), 6 (Cross-Site-Identifier) und 7 (US-Datentransfer). Die wörtliche Schlussfolgerung der CNIL in Sheet 16: „Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration.”

Die fünf Do’s, die Sie ausgenommen halten

Dies sind die Bedingungen, die — gemeinsam angewendet — einer First-Party-Webanalyse-Stack erlauben, gleichzeitig für das strengste aktuelle Regime (§ 25 TDDDG) und die permissivste nationale Ausnahme (CNIL Sheet 16) zu qualifizieren. Sie sind auch die Architektur, die der Vorschlag Digital Omnibus Artikel 88a Abs. 3 lit. c EU-weit standardisieren würde, falls unverändert verabschiedet.

1. Täglich rotierender, site-bezogener Salt mit Vernichtung. Besucher-Signaturen werden abgeleitet als BLAKE3-HMAC(master_secret, site_id || YYYY-MM-DD). Der Salt wird im Prozess berechnet, nie gespeichert, und der Salt des Vortags wird bei der Rotation vernichtet. Derselbe Besucher am Montag und Dienstag → zwei verschiedene Signaturen; tagesübergreifende Re-Identifikation ist durch Konstruktion unmöglich. Derselbe Besucher auf zwei verschiedenen Sites → zwei nicht verknüpfbare Signaturen; site-übergreifende Re-Identifikation ist durch Konstruktion unmöglich. Dies ist die Plausible-Konstruktion (hash(daily_salt + website_domain + ip_address + user_agent)) plus eine Salt-Vernichtungs-Garantie.

2. IP-Kürzung vor jeder Speicherung. Entfernen Sie mindestens das letzte Oktett von IPv4 (203.0.113.42 → 203.0.113.0/24). Für IPv6 behalten Sie nur das Netzwerk-Präfix — typischerweise /48 oder /64. Die rohe IP darf für den GeoIP-Lookup kurz im Request-Pfad existieren; sie muss verworfen werden, bevor der Batch-Writer die Zeile sieht. Die Geolokalisierung degradiert auf Stadt/Region — die CNIL-Obergrenze.

3. User-Agent-Minimierung und Host-only-Referrer. UAs reduziert auf Gerät + Hauptbrowser-Version + Haupt-OS-Version, serverseitig geparst, Rohstring verworfen. Referrer nur auf Host reduziert (example.com, nicht example.com/search?q=secret) vor der Speicherung — eliminiert versehentliche PII in Query-Strings. Beides sind CNIL-Sheet-16-Bedingungen und beides geschieht beim Eingang im Server von Statnive Live.

4. Keine Cookies, kein localStorage, kein Fingerprinting. Artikel 5 Abs. 3 ePrivacy wird nicht ausgelöst, weil keine Endgeräte-Speicherung oder kein Zugriff stattfindet. Verifizieren Sie in Ihren Browser-DevTools → Application → Storage; Quoten bleiben bei null. Auch keine Canvas-, WebGL-, Font-Aufzählungs-, Audio-Kontext- oder navigator.plugins-Proben — das sind alles Client-seitige Reads, die EDPB-Leitlinien 2/2023 in den Anwendungsbereich von Artikel 5 Abs. 3 stellen.

5. Begrenzte Aufbewahrung mit dokumentierter Interessenabwägung. CNILs 13-Monats-Tracker-Laufzeit und 25-Monats-Datenaufbewahrungs-Obergrenzen sind die strengsten aktuellen europäischen Hürden. Aggregieren Sie Dashboard-Ausgaben auf die nächste 10 (oder dokumentieren Sie eine Anonymisierungsanalyse, die die WP29/EDPB-Anonymisierungs-Stellungnahme zitiert). Pflegen Sie eine Interessenabwägung gemäß EDPB-Leitlinien 1/2024 — DSB-Beteiligung, dreistufiger Test, jährlich oder bei materieller Änderung aktualisiert. Eine DSFA gemäß Artikel 35 DSGVO für volumenstarke, sensitiv-vertikale oder funktionsreiche Deployments.

Diese fünf Punkte sind die Architektur. Sie sind nicht von der Verabschiedung des Digital Omnibus abhängig. Sie überstehen das strengste aktuelle Mitgliedstaat-Regime. Und sie verbinden sich zu einer einzigen Konfiguration, die der Betreiber nicht austauschen muss, wenn sich die Rechtsprechung verschiebt.

Warum „anonym” nicht ausreicht — die Pseudonymisierungs-Unterscheidung

Betreiber, die irgendwann auf den Marketing-Seiten ihrer Webanalyse-Anbieter gelesen haben, kennen das Wort „anonym” auf gehashte IPs und Cookie-freies Tracking angewendet. Das Wort leistet juristische Arbeit, die die DSGVO nicht zulässt.

Die EDPB-Leitlinien 01/2025 zur Pseudonymisierung im Entwurf — angenommen als Entwurf in der 101. Plenarsitzung am 16. Januar 2025, in öffentlicher Konsultation bis 28. Februar 2025 und Stand Mai 2026 noch in Bearbeitung — stellen klar, dass pseudonymisierte Daten, einschließlich gehashter IPs, Cookie-IDs, BLAKE3/HMAC-Besucher-Signaturen und TC-Strings, personenbezogene Daten bleiben, wenn eine Re-Identifikation vernünftigerweise wahrscheinlich über Mittel ist, die dem Verantwortlichen oder einem Dritten zur Verfügung stehen. Das EuGH-Urteil IAB Europe (C-604/22, 7. März 2024) erweiterte dies über TC-Strings hinaus auf jeden Identifier in Kombination mit einer IP.

Praktisch:

Ein Cookie-freies Tracking-System mit täglich rotierendem Salt ist pseudonym innerhalb des Tages und wird nur über Tage hinweg anonym — und nur, weil der Salt des Vortags vernichtet wird.
Ein Statisch-Salt-IP-Hash ist unbegrenzt pseudonym und für jeden mit einer GPU und einer Liste von Kandidat-IPs reversibel.
Eine „stadtgenaue” Geolokalisierung aus einer /24-IP-Kürzung ist gemäß Breyer pseudonym — aber die Kürzung entfernt den am besten reversiblen Identifier aus der Speicherschicht, was sowohl das DSGVO-Artikel-5(1)(c)-Prinzip der Datenminimierung als auch die CNIL-Sheet-16-Bedingung verlangen.

Die robuste Haltung: Behandeln Sie gehashte Besucher-Identifier als risikoarme personenbezogene Daten. Wenden Sie die Artikel-6(1)(f)-Grundlage des berechtigten Interesses auf ihre Verarbeitung an. Dokumentieren Sie die Interessenabwägung. Erfüllen Sie Auskunfts- (Art. 15) und Löschungsanfragen (Art. 17) gegen sie über einen DSAR-Endpunkt. Vermarkten Sie sie nicht als „anonym”. Dieses Wort ist für Daten reserviert, bei denen eine Re-Identifikation vernünftigerweise nicht möglich ist, durch niemanden, jemals — und ein gehashter IP, der durch rechtliche Zugriffsmittel eines Staates erschlossen werden kann, erfüllt diese Hürde nicht.

Aus genau diesem Grund hielt Italiens Garante Googles IP-Anonymisierungsfunktion in seiner Caffeina-Media-Entscheidung für unzureichend: „Die Funktion stellt eine Pseudonymisierung der IP-Adresse dar, keine Anonymisierung. … Die Funktion verhindert nicht, dass Google LLC den Nutzer re-identifiziert, angesichts der Fähigkeiten von Google, solche Daten durch zusätzliche, ihm vorliegende Informationen anzureichern.” Die Funktion tat genau das, was ihr Marketing sagte. Sie war nur nicht Anonymisierung im DSGVO-Sinne.

Wie Statnive Live dafür gebaut ist

Statnive Live wurde gegen die obigen Do’s und Don’ts entworfen. Die Architektur ist das, was der Hetzner-gehostete Server in Nürnberg standardmäßig ausführt; das gleiche Binary ist auch selbst hostbar auf Kunden-Infrastruktur, in welchem Fall nichts von Statnive verarbeitet wird.

Cookielos durch Konstruktion. Keine Cookies, kein localStorage, kein sessionStorage. Artikel 5 Abs. 3 ePrivacy wird nicht ausgelöst, weil keine Endgeräte-Speicherung oder kein Zugriff stattfindet. Der Tracker ist ein ~2,0 KB minified / ~0,9 KB gzipped First-Party-Skript, das von derselben Domain wie die Site des Betreibers ausgeliefert wird — kein Drittanbieter-CDN, kein Drittanbieter-Tag-Manager.

Tägliche rotierende BLAKE3-HMAC-Besucher-Signaturen. Hashes werden abgeleitet als HMAC(master_secret, site_id || YYYY-MM-DD). Der Salt ist im Prozess; der Salt des Vortags wird bei der Rotation vernichtet. Die Konstruktion entspricht dem Plausible-/Fathom-Ansatz und fügt eine Site-Level-Komponente hinzu, sodass ein Besucher auf zwei Statnive-getrackten Sites zwei nicht verknüpfbare Signaturen erzeugt.

Gehashter Cookie-ID im Ruhezustand. Wenn ein Betreiber Statnive Live im consent-required- oder hybrid-Modus mit erteilter Einwilligung betreibt, ist die an den Browser emittierte Cookie-ID eine rohe UUID; der serverseitig gespeicherte Wert ist SHA-256(master_secret || site_id || cookieID) mit einem h:-Präfix. Der Browser sieht die rohe UUID; die Datenbank nie. Tagesübergreifende Besucher-Kontinuität wird ohne Speicherung des rohen Identifiers gewahrt.

Server-seitiger Host-only-Referrer. Der Tracker speichert den vollen document.referrer; beim Eingang reduziert der Server ihn vor dem Schreiben auf den Host-Anteil. Query-Strings (die Suchbegriffe oder PII enthalten können) gelangen nie in den dauerhaften Speicher.

Rohe IP vor der Speicherung verworfen. Die IP existiert im Request-Pfad für den GeoIP-Lookup und die Hash-Ableitung; sie wird verworfen, bevor der Batch-Writer die Zeile sieht. Verifiziert durch einen Integrationstest in internal/enrich/geoip.go des Statnive-Live-Repositorys.

25-Monats-Rollup-Aufbewahrung. Eine 750-Tage-TTL wird auf die v1-AggregatingMergeTree-Rollups (hourly_visitors, daily_pages, daily_sources) durchgesetzt — 24,6 Monate, der CNIL-Obergrenze mit Spielraum entsprechend. Darüber hinaus laufen die Rollups automatisch ohne Eingreifen des Betreibers ab.

Vier Einwilligungsmodi, elf Jurisdiktionen, Hard-Rule-Validierung. Die Site-Policy trägt einen Consent-Mode-Enum (permissive / consent-free / consent-required / hybrid) und einen Jurisdictions-Enum (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU). Ein Hard-Rule-Validator verhindert, dass deutsche Betreiber permissive auswählen (§ 25 TDDDG verbietet es) und dass consent-required ohne aktive Einwilligungs-Integration gewählt wird. Der Validator läuft beim Speichern im Admin und erneut beim Policy-Load bei jedem Ingest-Request. Die TDDDG-Tiefenanalyse deckt die Deutschland-Zelle im Detail ab.

GPC und DNT kurzschließen vor dem Hash. Wenn Sec-GPC: 1 oder DNT: 1 gesetzt ist und die Site-Policy diese Signale berücksichtigt, wird die Anfrage verworfen, bevor der Besucher-Identifier berechnet wird. Es wird kein pseudonymer Identifier für einen ablehnenden Besucher generiert — es gibt nichts zu löschen, weil nichts erstellt wurde. Der GPC- und Hybrid-Modus-Beitrag geht den End-to-End-Testplan durch.

DSAR-Endpunkte von Haus aus. POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase — CSRF-geschützt, ratenbegrenzt, audit-geloggt. Acht Datenschutz-Audit-Ereignisse (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) emittieren strukturierte Logs, bereit für ein Artikel-28(3)(h)-Accountability-Audit. Der DSAR-Beitrag deckt die Integrationsfläche ab.

Öffentliche Legal-Disclosure-Routen im Binary eingebettet. /privacy, /legal/privacy-policy/en, /legal/privacy-policy/de, /legal/lia und /legal/dpa werden vom selben Go-Binary wie der Tracker ausgeliefert — keine CDN-Abhängigkeit, air-gap-sicher, zugänglich für Betreiber, die Statnive Live in restriktiven Egress-Umgebungen ausführen.

Das Ergebnis ist eine Konfiguration, die Deutschlands strenge Hürde heute erfüllt, sich gemäß Frankreichs Sheet 16 mit einer dokumentierten Selbstbewertung qualifiziert und positioniert ist, sich gemäß dem vorgeschlagenen Artikel 88a Abs. 3 lit. c am ersten Tag zu qualifizieren, falls der Digital Omnibus unverändert verabschiedet wird. Betreiber müssen sich nicht entscheiden; die gleiche Site-Policy trägt sie alle.

Was kommt — Artikel 88a Abs. 3 lit. c

Der Digital-Omnibus-Vorschlag der Europäischen Kommission vom 19. November 2025 — COM(2025) 837 final — würde einen neuen Artikel 88a DSGVO mit einer abschließenden Liste von Zwecken ohne Einwilligung einführen. Der relevante Unterabsatz für Webanalyse ist 88a Abs. 3 lit. 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.”

Stand Mitte Mai 2026: Die Akte hat die ITRE-Berichterstatterin Aura Salla (EPP/FI — Ernennung von sieben Zivilgesellschaftsorganisationen wegen eines Meta-Lobbying-Konflikts angefochten) und die LIBE-Berichterstatterin Marina Kaljurand (S&D/EE); der EWSA nahm seine Stellungnahme am 18. März 2026 an; die Ratsarbeitsgruppe diskutiert aktiv (Akte WK 3736/2026 INIT). Es gibt noch keine Plenarabstimmung des Europäischen Parlaments zu COM(2025) 837 — eine Plenarabstimmung am 26. März 2026 betraf die separate Datei Digital Omnibus zu KI. Die gemeinsame Stellungnahme 2/2026 des EDPB-EDPS vom 11. Februar 2026 äußerte ernsthafte Bedenken über die Wirkung des breiteren Pakets auf den individuellen Schutz und die Rechtssicherheit. Realistische Verabschiedung Ende 2026 bis 2027; Inkrafttreten wahrscheinlich 2027 bis 2028; Artikel 88a sechs Monate nach Inkrafttreten geltend.

Drei Implikationen für Betreiber:

Die Konfiguration in diesem Leitfaden ist vorwärtskompatibel. First-Party, aggregierte, ausschließlich-Verantwortlicher-Nutzung Reichweitenmessung ist genau der Anwendungsfall, den Artikel 88a Abs. 3 lit. c beschreibt. Betreiber, die die obigen Do’s deployen, qualifizieren heute unter nationalen Ausnahmen, wo sie existieren, und morgen unter EU-weitem Artikel 88a, falls unverändert verabschiedet.
Der Vorschlag ist eine Schichtverlagerung, keine parallele Ergänzung. Für den Endgeräte-Zugriff auf personenbezogene Daten würde Artikel 88a DSGVO regieren und ePrivacy 5(3) auf diese Operationen aufhören anzuwenden. Für den Endgeräte-Zugriff auf nicht-personenbezogene Daten (ein engerer Rest) gilt ePrivacy 5(3) weiterhin. Die beiden Rahmen würden sequenziell laufen, nicht parallel. Die sauberste Position bleibt „keine Endgeräte-Speicherung oder kein Zugriff im ersten Schritt” — das umgeht beide Schichten.
Der Text ist eine Roadmap, keine gegenwärtige Rechtsgrundlage. Betreiber, die nur für den Digital Omnibus und nicht für das gegenwärtige Mitgliedstaat-Recht entwerfen, werden die nächsten 12-18 Monate in einer regulatorischen Lücke verbringen.

Wie Sie diesen Leitfaden einsetzen

Eine praktische Deployment-Sequenz für einen Betreiber, der Statnive Live übernimmt (oder die Architektur in einem selbst gehosteten Stack repliziert):

Wählen Sie Ihre strengste Jurisdiktion. Falls Traffic deutsch ist, konfigurieren Sie für DE / consent-free. Der Hard-Rule-Validator erledigt dies für Sie und verweigert permissive Konfigurationen.
Veröffentlichen Sie eine Interessenabwägung. Die Vorlage der EDPB-Leitlinien 1/2024 ist die kanonische Struktur: Interessenidentifikation → Erforderlichkeit → Abwägung. Laden Sie die LIA-Vorlage für die empfohlene Sprache von Statnive Live herunter; passen Sie sie mit Rechtsbeistand an Ihren Verarbeitungskontext an.
Veröffentlichen Sie eine Datenschutzerklärung. EN- und DE-Klauseln sind in Statnive Live unter /legal/privacy-policy/en und /legal/privacy-policy/de eingebettet. Die deutsche Klausel trägt die wörtliche Sprache von § 25 Abs. 1 TDDDG über keine Endgeräte-Speicherung oder keinen Zugriff; die englische Klausel deckt die Artikel-6(1)(f)-Grundlage und das CNIL-Sheet-16-Attestierungs-Muster ab.
Verkabeln Sie die DSAR-Endpunkte. Drei Routen (/api/privacy/opt-out, /api/privacy/access, /api/privacy/erase) werden vom Binary bereitgestellt. Der DSAR-Beitrag deckt die Integration ab; die Audit-Log-Fläche ist standardmäßig verkabelt.
Berücksichtigen Sie GPC standardmäßig im EU-Modus. Setzen Sie consent.respect_gpc = true auf jeder deutschen, französischen, italienischen und niederländischen Site. Der GPC-Beitrag erklärt die client-seitige Kurzschluss- + server-seitige Durchsetzungs-Schicht.
Führen Sie den Event-Audit-Endpunkt monatlich aus. GET /api/admin/event-audit?site_id=N gibt die Anzahl der eindeutigen Ereignisnamen pro Site gegenüber der CNIL-Drei-Ereignis-Obergrenze zurück. Streben Sie ok-Status an; untersuchen Sie jedes over sofort.
Überprüfen Sie die Interessenabwägung jährlich. Der EDPB empfiehlt jährliche Aktualisierung und bei materieller Änderung — z. B. bei Verabschiedung des Digital Omnibus, bei einer EuGH-Vorlage, die den DPF-Status betrifft, oder wenn eine nationale Behörde neue Leitlinien veröffentlicht.

Die Land-für-Land-Referenzkarte ist die Nachschlagetabelle für die Details pro Jurisdiktion. Die drei bestehenden Datenschutz-Beiträge — Warum datenschutzfreundliche Webanalyse 2026 zählt, DSGVO-konforme Webanalyse 2026 und Eigene Webanalyse-Daten: Selbst gehostet vs. private EU-SaaS 2026 — decken die breitere Landschaft und den Verantwortlicher-vs.-Auftragsverarbeiter-Aspekt ab.

Was zu tun ist — und was zu lassen — die komprimierte Karte

Die obigen Body-Abschnitte enthalten die vollständigen „Sieben Don’ts”- und „Fünf Do’s”-Listen. Die komprimierte Version für Betreiber, die zuerst scannen:

Tun	Nicht tun
Für das strengste Mitgliedstaat-Regime konfigurieren (Deutschlands § 25 TDDDG) — der Rest der EU baut darauf auf.	Separat für jeden Mitgliedstaat konfigurieren, in dem Sie Traffic haben — das ist der Weg zu 27 verschiedenen Interessenabwägungen, die Sie nie aktualisieren werden.
Einen täglich rotierenden, site-bezogenen Salt verwenden; den Salt von gestern am Tagesende vernichten.	Einen statischen Salt verwenden — eine einzige GPU und eine IPv4-Rainbow-Table kehren ihn um; der Garante hat das in Caffeina Media gesagt.
IPv4 vor jeder Speicherung auf /24 und IPv6 auf /48 kürzen; User-Agent auf Hauptversionen reduzieren; Referer auf Host reduzieren.	Rohe IPs, rohe User-Agents oder volle Referrer-URLs speichern — alle sind personenbezogene Daten; rohe Query-Strings lecken PII.
Eine dokumentierte Interessenabwägung gemäß EDPB-Leitlinien 1/2024 und länderspezifische Selbstbewertung veröffentlichen.	„CNIL-zertifiziert” behaupten oder das CNIL-Logo verwenden. Die CNIL hat ihr Evaluierungsprogramm am 1. Januar 2026 eingestellt — Betreiber bewerten sich selbst.
GPC und DNT standardmäßig im EU-Modus berücksichtigen; das Widerspruchsrecht gemäß Art. 21 mit einem persistenten Opt-out-Link erfüllen.	Gehashte Besucher-IDs als „anonyme” Daten behandeln — sie sind pseudonym gemäß dem Entwurf der EDPB-01/2025-Leitlinien, vollständig personenbezogene Daten gemäß Breyer.

Das Fazit

Einwilligungsfreie Webanalyse in der EU ist 2026 machbar. Sie ist nicht zufällig machbar, und sie ist nicht durch Konfigurieren eines US-basierten Webanalyse-Tools auf „anonymisierte” IPs machbar. Sie ist machbar, indem der Speicher-/Zugriffs-Auslöser aus dem System herausentworfen wird, indem Signaturen abgeleitet werden, die sich selbst vernichten, indem identifizierende Daten beim Eingang gekürzt werden, und indem die Berechtigtes-Interesse-Grundlage gemäß dem dreistufigen EDPB-Test dokumentiert wird. Die Architektur ist die Compliance; der Vertrag ist die Audit-Spur.

Konfigurieren Sie für Deutschland; Sie sind für alles andere konfiguriert. Führen Sie eine Interessenabwägung durch; Sie haben eine Grundlage, auf die Sie verweisen können. Berücksichtigen Sie GPC; Sie haben eine Compliance-Vermutung gemäß dem vorgeschlagenen Artikel 88b. Begrenzen Sie Ihre Aufbewahrung auf 25 Monate; Sie sitzen mühelos innerhalb der CNIL-Obergrenze. Überspringen Sie Cookies ganz; Sie überspringen die Cookie-Banner-UX-Haftung, die im September 2025 €475 Mio. an CNIL-Sanktionen produziert hat.

Dafür ist Statnive Live da. Cookielos. EU-only. Täglich rotierende Salts. Gehashter Cookie-ID im Ruhezustand. Host-only-Referrer. 25-Monats-Aufbewahrung. Vier Einwilligungsmodi, elf Jurisdiktionen, Hard-Rule-Validierung. DSAR-Endpunkte, LIA-Vorlage, Datenschutzerklärung- und DPA-Vorlagen im Binary, herunterladbar ohne Verkaufsgespräch.

Wenn dieser Leitfaden Ihnen hilft, einen Teil Ihres aktuellen Webanalyse-Stacks zu festigen, ist er dafür da. Wenn er Sie überzeugt zu wechseln — dafür ist statnive.com/live da. So oder so: Die obigen Do’s und Don’ts sind die dauerhafte Architektur; die Rechtsprechung und die Vorschläge werden sich weiter um sie herum verschieben, und der Leitfaden ist so gebaut, dass der Betreiber nicht jedes Mal neu architektieren muss.

Dies ist Datenschutz-Forschung, keine Rechtsberatung. Die beschriebenen Konfigurationen qualifizieren sich gemäß behördlicher Leitlinien, wenn sie gemäß einer dokumentierten Interessenabwägung und der entsprechenden länderspezifischen Selbstbewertung eingesetzt werden. Jeder Statnive-Kunde bleibt Verantwortlicher und ist für seine eigene Konfiguration und DSFA verantwortlich. Konsultieren Sie qualifizierten Rechtsbeistand in Ihrer Rechtsordnung vor der Veröffentlichung.

Stand der regulatorischen Verweise zum 13. Mai 2026: CNIL Sheet 16 + Aktualisierung vom 4. Juli 2025 (Compliance-Deadline 1. Januar 2026 ist nun verstrichen; Evaluierungsprogramm eingestellt; Selbstbewertungs-Regime in Kraft); TDDDG § 25 (in Kraft seit 1. Dezember 2021, im Mai 2024 umbenannt); italienische Garante Cookie-Leitlinien vom 10. Juni 2021 (in Kraft seit 10. Januar 2022); AEPD-Leitfaden zu Cookies (Juli 2023, durchgesetzt 11. Januar 2024); niederländische AP Analytische-Cookies-Position (Artikel 11.7a Telecommunicatiewet); UK ICO Storage and Access Technologies Guidance (29. April 2026); EDPB-Leitlinien 2/2023 v2.0 (7. Oktober 2024); EDPB-Leitlinien 1/2024 (8. Oktober 2024); Entwurf der EDPB-Leitlinien 01/2025 zur Pseudonymisierung (als Entwurf am 16. Januar 2025 angenommen; öffentliche Konsultation bis 28. Februar 2025; finale Version Stand Mai 2026 noch nicht veröffentlicht); gemeinsame Stellungnahme 2/2026 des EDPB-EDPS vom 11. Februar 2026 zum Digital Omnibus; Digital Omnibus COM(2025) 837 final (Kommissionsvorschlag vom 19. November 2025, keine Plenarabstimmung des Europäischen Parlaments zu COM(2025) 837 Stand 13. Mai 2026); EuGH C-582/14 Breyer (ECLI:EU:C:2016:779); EuGH C-604/22 IAB Europe (7. März 2024); EuGH C-621/22 KNLTB (ECLI:EU:C:2024:857); EuGH C-446/21 Schrems v Meta (4. Oktober 2024).