DSGVO-konforme Web-Analytics im Jahr 2026: Ein praktischer Leitfaden für europäische Website-Betreiber

DSGVO-konforme Web-Analytics ist ein Problem von 2026, nicht von 2018

Die DSGVO ist diesen Monat acht Jahre alt geworden. Der Wortlaut der Artikel 5, 6 und 7 hat sich nicht geändert — aber die Rechtsprechung, die Durchsetzungsschwerpunkte und die praktische Messlatte für „konforme” Web-Analytics haben sich in den letzten 18 Monaten dramatisch verschoben. Wenn Sie Ihren Analytics-Stack zwischen 2018 und 2024 aufgesetzt und seitdem nicht mehr überprüft haben, ist dies ein Leitfaden dazu, was die Aufsichtsbehörden heute tatsächlich erwarten — und wie Sie sich aus den riskantesten Mustern herausdesignen, statt sie nur zu übertünchen.

Dies ist der zweite Beitrag einer kurzen Serie, die Statnive Live vorstellt — die eigenständige Analytics-Plattform, die wir parallel zu unserem WordPress-Plugin starten. Der erste Beitrag führte durch den Entscheidungsbaum WP-Plugin vs. Live. Statnive Live verarbeitet Daten in Nürnberg, Deutschland; liefert auf jedem Tarif eine Auftragsverarbeitungsvereinbarung nach Art. 28 Abs. 3 DSGVO mit; und wurde gegen die unten zitierte Rechtsprechung entworfen. Wo wir eine regulatorische Behauptung aufstellen, finden Sie eine Fußnote mit Aktenzeichen, Datum und Behörde — überprüfen Sie alles, woran Sie zweifeln.

Die EU-Regulierungslandschaft 2026

Fünf Dinge sind im April 2026 wahr, die vor zwei Jahren noch nicht wahr waren.

1. GA4 ist der am häufigsten beanstandete Tracker in der aktiven deutschen Durchsetzung

In ihrem 2025 veröffentlichten Tätigkeitsbericht (Tätigkeitsbericht Datenschutz 2025) prüfte die Hamburger Datenschutzbehörde (HmbBfDI) 1.000 in Hamburg ansässige Websites. 185 davon hatten Drittanbieter-Tracking, das bereits beim ersten Seitenaufruf vor jeder Einwilligung feuerte. Von diesen 185 Sites liefen 110 — also rund 60 % — mit Google Analytics, gefolgt von Google Maps (51), Google Ads (42), YouTube (20) und Facebook (15). Die Betreiber bekamen sechs Monate Zeit zur Behebung.

Die Entscheidungen der österreichischen DSB von Dezember 2021 / Mai 2022 zu GA (D155.027 / 2021-0.586.257) und die Entscheidung der italienischen Garante zu Caffeina Media vom Juni 2022 (Maßnahme 9782890) — die alle GA-Datentransfers von der EU in die USA auf Schrems-II-Grundlage für rechtswidrig erklärten — wurden durch keine Entscheidung aus dem Zeitraum 2024–2026 aufgehoben. Die GA-Präzedenzfälle aus 2022 sind die maßgebliche Rechtsprechung im Jahr 2026.

2. Das EU-US Data Privacy Framework ist umstritten, nicht gesichert

Das DPF überstand seine erste gerichtliche Anfechtung — Latombe gegen Kommission, T-553/23, vom EuG am 3. September 2025 entschieden (IAPP-Bericht). Der Angemessenheitsbeschluss der Kommission vom 10. Juli 2023 hat Bestand. Allerdings legte Latombe am 31. Oktober 2025 Rechtsmittel beim EuGH ein, und noyb hat eine parallele Anfechtung angekündigt (WilmerHale-Analyse). Der Verfahrensstand beim EuGH ist zum Redaktionsschluss anhängig.

Die architektonisch belastbare Antwort für jeden neuen EU-Launch im Jahr 2026 ist daher dieselbe, die Schrems II bereits 2020 nahelegte: EU-personenbezogene Daten gar nicht erst in ein Drittland übertragen. Eine ausschließlich europäische Datenresidenz nimmt die Artikel 44–49 vollständig aus dem Anwendungsbereich.

3. Die CNIL hat klargestellt, dass „wir setzen ein Banner ein” keine Verteidigung mehr ist

Am 1. September 2025 verhängte die CNIL zwei gleichzeitige Rekord-Sanktionen wegen Cookie-Consent-UX — nicht gegen das Ad-Tech-Downstream, sondern gegen das Banner selbst:

• Google: 325 Mio. €, Beschluss SAN-2025-006 — 200 Mio. € gegen Google LLC plus 125 Mio. € gegen Google Ireland — wegen Werbeanzeigen in Gmail „zwischen E-Mails” ohne Einwilligung und mangelhafter Gestaltung der Cookie-Einwilligung.
• Shein: 150 Mio. €, Beschluss SAN-2025-005 — wegen Setzens von Werbe- und Reichweiten-Cookies beim ersten Seitenaufruf, fehlender Erläuterung der Werbezwecke, Auslösen von 10 zusätzlichen Cookies bei Widerruf der Einwilligung und eines 10-Jahre-Reichweiten-Cookies, das ohne Einwilligung gesetzt wurde.

Dies sind die höchsten Cookie-Consent-Bußgelder, die jemals in der EU verhängt wurden. Zusammen mit der 226+500-Beschwerdekampagne von noyb — bei der 81 % der geprüften Seiten kein „Ablehnen” auf der ersten Ebene boten und 73 % Dark-Pattern-Farbkontraste nutzten — machen sie das Banner selbst zum regulatorischen Risiko, nicht nur die dahinterliegenden Cookies.

4. Das deutsche Cookie-Recht wurde umbenannt (aber nicht geändert)

§ 25 TTDSG wurde am 14. Mai 2024 zu § 25 TDDDG, als Artikel 4 des deutschen Digital-Services-Act-Umsetzungsgesetzes in Kraft trat (Robin-Data-Zusammenfassung). Inhaltlich hat sich nichts geändert — eine vorherige Einwilligung ist weiterhin für jeden nicht zwingend erforderlichen Speicher- oder Zugriffsvorgang auf Endeinrichtungen vorgeschrieben. Wenn Ihre Datenschutzerklärung noch „TTDSG” zitiert, aktualisieren Sie sie. Die freiwillige Einwilligungsverwaltungsverordnung (EinwV) trat am 1. April 2025 in Kraft, hebt § 25 TDDDG aber nicht auf; nicht-teilnehmende Sites benötigen weiterhin eine Banner-Einwilligung.

5. Gehashte IPs sind weiterhin personenbezogene Daten

Der EDSA verabschiedete auf seiner 101. Plenarsitzung am 16. Januar 2025 die Leitlinien 01/2025 zur Pseudonymisierung. Die Leitlinien bekräftigen, dass pseudonymisierte Daten — einschließlich gehashter IPs, Cookie-IDs, BLAKE3-/HMAC-Besucher-Hashes und TC-Strings — personenbezogene Daten bleiben, sobald eine Re-Identifizierung „nach vernünftigem Ermessen wahrscheinlich” über Mittel ist, die dem Verantwortlichen oder einem Dritten zur Verfügung stehen. Das IAB-Europe-Urteil des EuGH (C-604/22, 7. März 2024) und das Folgeurteil des Brüsseler Berufungsgerichts vom 14. Mai 2025 erweitern dies über TC-Strings hinaus auf jede mit einer IP gepaarte Kennung.

Pseudonymisierung ist ein Risiko-Reduzierer, keine DSGVO-Ausnahme. Wir kommen auf diesen Punkt zurück, wenn wir die Tagessalt-Konstruktion von Statnive Live unten beschreiben — wir behandeln unsere Hashes lieber als personenbezogene Daten mit niedrigem Risiko, als „anonymes Tracking” überzubehaupten.

Die vier rechtlichen Brennpunkte für Analytics

Jeder Analytics-Stack im Jahr 2026 muss vier Fragen beantworten. Die Artikel sind kurz — die Analysen unten sind die praxisnahe Version.

Brennpunkt 1 — Drittlandtransfers (DSGVO Art. 44–49)

Kapitel V der DSGVO regelt die Übermittlung personenbezogener Daten in Drittländer. Das DPF ist der aktuelle Angemessenheitsbeschluss für die USA; es ist gültig, aber umstritten (siehe oben). Die sauberste architektonische Antwort, und diejenige, die Statnive Live mitliefert, besteht darin, sämtliche Verarbeitung innerhalb des EWR zu halten — dadurch fällt Kapitel V vollständig aus dem Anwendungsbereich. Die Artikeltexte finden Sie auf gdpr-info.eu/chapter-5/.

Brennpunkt 2 — Rechtsgrundlage (DSGVO Art. 6)

Es gibt sechs Rechtsgrundlagen; für Analytics sind nur Einwilligung (a), Vertrag (b) und berechtigte Interessen (f) realistisch. (f) erfordert eine dokumentierte Interessenabwägung — die DSK-Leitlinie vom November 2024, v1.2 erkennt eine enge Ausnahme für berechtigte Interessen bei Erstanbieter-Nutzungs-Analytics nach Art. 6 Abs. 1 lit. f an, aber nur dann, wenn die Anforderung an den Endgeräte-Zugriff aus § 25 TDDDG unabhängig erfüllt ist (d. h. die Ausnahme „unbedingt erforderlich” greift, oder Sie haben eine separate Einwilligung für den Speicher-/Zugriffsvorgang).

Brennpunkt 3 — Einwilligung (DSGVO Art. 7 + ePrivacy Art. 5(3) + § 25 TDDDG)

Hier stapeln sich drei Schichten. Artikel 5 Absatz 3 der ePrivacy-Richtlinie regelt alles, was aus dem Endgerät des Besuchers liest oder darauf schreibt — und die EDSA-Leitlinien 2/2023 v2.0 (verabschiedet am 7. Oktober 2024) erweiterten diesen Anwendungsbereich ausdrücklich über Cookies hinaus auf URL-/Pixel-Tracking, reines IP-Tracking und das Lesen eindeutiger Kennungen. Deutschland setzt das in § 25 TDDDG um. DSGVO Art. 7 regelt anschließend die Einwilligung selbst — sie muss freiwillig, spezifisch, informiert, unmissverständlich, nachweisbar dokumentiert und widerrufbar sein.

Der saubere Ausweg besteht darin, den Speicher-/Zugriffs-Trigger aus dem System herauszudesignen. Keine Cookies, kein localStorage, keine Fingerprinting-Probes — und Artikel 5(3) wird gar nicht erst ausgelöst.

Brennpunkt 4 — Speicherdauer (DSGVO Art. 5 Abs. 1 lit. e)

"Kept in a form which permits identification of data subjects for no longer than is necessary." Das Schrems gegen Meta-Urteil des EuGH (C-446/21, 4. Oktober 2024) hat dies bekräftigt — eine zeitlich unbegrenzte Speicherung von Verhaltensprofilen „ohne zeitliche Beschränkung und ohne Differenzierung nach Datenart” ist ein unverhältnismäßiger Verstoß gegen Art. 5 Abs. 1 lit. c.

Für Analytics heißt das: Benennen Sie eine Speicherdauer, dokumentieren Sie, warum sie erforderlich ist, und löschen Sie tatsächlich planmäßig.

Was Banner an verlorener Messung kosten

Plausibles Cookie-Banner-Studie — die den Unterschied zwischen Traffic vor und nach dem Hinzufügen eines Banners misst — ergab, dass Einwilligungs-Banner rund 55,6 % der Besucher in der gemessenen Analytics kosten. Genauer gesagt: Die Besucher landen nach wie vor auf der Site, aber sie lehnen das Banner ab oder schließen es und werden im Analytics-Tool nicht mehr gezählt. Sie verlieren keine 55,6 % des Umsatzes; Sie verlieren 55,6 % an Sichtbarkeit auf den eigenen Traffic.

Das ist das praktische Argument dafür, das Banner aus der Analytics herauszudesignen — nicht als Compliance-Trick, sondern weil ein Banner-gegateter Analytics-Stack Ihnen mit jedem Jahr weniger über Ihre Website verrät, je stärker die Banner-Müdigkeit wächst.

Wie „compliant by architecture” konkret aussieht

Statnive Live wurde gegen die oben zitierte Rechtsprechung entworfen. Konkret heißt das:

Cookielos by construction. Keine Cookies, kein localStorage, kein sessionStorage — überprüfbar in den DevTools → Application; die Storage-Quoten bleiben bei null. Artikel 5(3) ePrivacy wird nicht ausgelöst, weil kein Speicher- oder Zugriffsvorgang am Endgerät stattfindet. Auch keine Canvas-, WebGL-, Font-Enumeration- oder navigator.plugins-Probes; die gdpr-code-review-Regel in der CI verbietet sie im Tracker.

Täglich rotierende BLAKE3-HMAC-Salts. Besucher-Hashes werden abgeleitet als HMAC(master_secret, site_id || YYYY-MM-DD). Der Salt wird im Prozess berechnet, nie gespeichert. Derselbe Besucher am Montag und am Dienstag → zwei unterschiedliche Hashes; Cross-Day-Re-Identifizierung ist by construction unmöglich. Gemäß den EDSA-Leitlinien 01/2025 sind diese Hashes weiterhin personenbezogene Daten (wir behandeln sie auch so), aber die tägliche Rotation positioniert sie am unteren Risikoende des Spektrums.

Rohe IP wird vor der Speicherung verworfen. Die IP gelangt nur für den GeoIP-Lookup in die Pipeline und wird verworfen, bevor der Batch-Writer die Zeile sieht. Dies wird durch einen Integrationstest in internal/enrich/geoip.go abgesichert; die Kunden-AVV dokumentiert dies wortgleich.

DNT und Sec-GPC kappen vor dem Hash. Wenn Sec-GPC: 1 oder DNT: 1 gesetzt ist, wird der Request verworfen, bevor der Besucher-Identifikator berechnet wird. Für einen ablehnenden Besucher entsteht kein pseudonymer Identifikator — es gibt nichts zu löschen, weil nichts erzeugt wurde.

Reiner EU-Datenpfad mit First-Party-Tracker. Statnive Live SaaS verarbeitet Daten in Nürnberg, Deutschland, auf einem Netcup VPS 2000 G12 NUE — kein Kapitel-V-Transfer, keine Drittland-Angemessenheitsfrage. Der Tracker-JS wird über Gos go:embed aus demselben Nürnberger Origin ausgeliefert: kein Drittanbieter-CDN, kein Drittanbieter-Tag-Manager und kein TC-String, sodass das IAB-Europe-Muster „TC-String + IP = personenbezogene Daten” by construction entfällt.

Nichts davon macht Statnive Live „DSGVO-befreit”. Es macht Statnive Live zu einem Stack, der so entworfen ist, dass die Compliance-Arbeit zum großen Teil bereits erledigt ist — Ihre Datenschutzerklärung wird kürzer, Ihre DSFA einfacher, und die obigen Punkte beseitigen die meisten der riskantesten Durchsetzungs-Trigger.

Self-Hosted vs. private EU-SaaS — die vertragliche Seite

Dasselbe Statnive-Live-Binary läuft in zwei Ausprägungen, mit sehr unterschiedlichen Verantwortlichen-/Auftragsverarbeiter-Konstellationen.

Self-Hosted Statnive Live: Sie betreiben das Binary auf Ihrem eigenen Server. Wir sehen, speichern oder übertragen die Daten Ihrer Besucher nicht. Sie sind der Verantwortliche, und es gibt keinen AVV zwischen Statnive und Ihnen zu unterzeichnen — es gibt schlicht nichts, dessen Auftragsverarbeiter wir sein könnten. Das Binary ist durch einen Integrationstest verifiziert, unter iptables -P OUTPUT DROP (null erforderlicher Outbound-Traffic) zu laufen, sodass die No-Egress-Aussage reproduzierbar ist.

Statnive Live SaaS: Sie zeigen mit Ihrem Tracker auf unseren managed Nürnberg-Endpunkt. Sie sind der Verantwortliche; wir sind der Auftragsverarbeiter. Bei der Anmeldung wird auf jedem Tarif inklusive Free ein AVV nach Art. 28 Abs. 3 DSGVO unterzeichnet. Der aktuelle AVV-Entwurf deckt alle acht Unterabsätze des Art. 28 Abs. 3 ab — Weisungsbindung (a), Vertraulichkeit (b), Sicherheit nach Art. 32 (c), Subunternehmer-Genehmigung (d), Unterstützung bei Betroffenenrechten (e), Unterstützung des Verantwortlichen bei Art. 32–36 (f), Löschung oder Rückgabe bei Vertragsende (g) und Auditrechte (h).

Das ist der zentrale Trade-off, den der WP-Plugin-vs.-Statnive-Live-Vergleich im Detail durchgeht. Wenn Ihre Compliance-Position einen unterzeichneten Auftragsverarbeitungsvertrag verlangt — regulierte Branche, ISO-27001-Kundenfragebogen, große Beschaffung — liefert der SaaS-Pfad genau das. Wenn Ihre Position lautet „kein Dritter berührt die Daten, Punkt”, liefert der Self-Hosted-Pfad genau das.

Was mit statnive.live kommt

Wenn Statnive Live SaaS 2026 live geht, kommt die vertragliche Grundlage von Anfang an mit:

• AVV nach Art. 28 Abs. 3 auf jedem Tarif, inklusive Free, datiert auf 2026-04-24.
• Subunternehmer-Liste innerhalb von 7 Tagen nach jeder Upstream-Änderung aktualisiert, mit 14 Tagen Vorlaufzeit vor dem Inkrafttreten eines neuen Subunternehmers — sodass Sie vor der Änderung widersprechen können (gemäß § 5.4 des AVV).
• Meldefrist bei Datenpannen: 48 Stunden ab Kenntnisnahme, in Anlehnung an Art. 33 DSGVO.
• 30-Tage-Kunden-Export-Fenster bei Vertragsende, danach vollständige Löschung der Rohdaten-, Rollup- und Backup-Tabellen (nächster Backup-Zyklus ≤ 24 h) sowie der Audit-Logs — außer dort, wo Unionsrecht oder mitgliedstaatliches Recht eine Aufbewahrung vorschreibt.
• Kein Kapitel-V-Transfer. Die gesamte Verarbeitung von EU-personenbezogenen Daten findet in Nürnberg, Deutschland, statt.

Der AVV, das Subunternehmer-Register und die Datenschutzerklärung werden bei Live-Gang des SaaS unter https://statnive.live/dpa (und entsprechenden Adressen) veröffentlicht. Bis dahin lebt der Entwurfstext im statnive-live-Repository unter docs/dpa-draft.md, versionsgeführt und einsehbar.

Häufige Fragen

Brauche ich weiterhin ein Cookie-Banner?

Das hängt von zwei Fragen ab: (a) Liest Ihr Stack vom Endgerät des Besuchers oder schreibt darauf (ePrivacy Art. 5(3) / § 25 TDDDG)? Und (b) was ist Ihre Rechtsgrundlage nach DSGVO Art. 6?

Ein cookieloser First-Party-Nutzungs-Analytics-Stack, der keinerlei Speicher- oder Zugriffsvorgang am Gerät des Besuchers durchführt — wie Statnive Live —, kann unter der DSK-Ausnahme November 2024 v1.2 häufig auf Grundlage von Art. 6 Abs. 1 lit. f (berechtigtes Interesse) ohne Banner betrieben werden. Aber die Bewertung ist jurisdiktionsspezifisch, und ein datenschutzorientierter Betreiber kann dennoch einen Datenschutzhinweis anzeigen — nur eben kein Einwilligungs-Gate. Wir sind nicht Ihr Datenschutzbeauftragter; sprechen Sie mit einem, bevor Sie Ihr Banner ändern.

Reicht DSGVO Art. 6 Abs. 1 lit. f („berechtigtes Interesse”) aus?

Im Einzelfall. Sie müssen eine Interessenabwägung durchführen — Zweck, Erforderlichkeit, Abwägung gegen die Rechte und vernünftigen Erwartungen der betroffenen Person — und sie dokumentieren. Die DSK-Leitlinie vom November 2024, v1.2 erkennt diesen Pfad für Erstanbieter-, nicht-geteilte Nutzungs-Analytics an. Drittanbieter-Analytics, die Daten mit Google oder Meta für deren eigene Zwecke teilen, ist nicht derselbe Pfad.

Was ist mit britischen und Schweizer Daten?

Das Vereinigte Königreich setzt die UK GDPR plus DPA 2018 und PECR durch. Der Angemessenheitsbeschluss der Europäischen Kommission für das Vereinigte Königreich wurde Mitte 2025 verlängert, sodass EU→UK-Transfers derzeit keine SCCs benötigen — überprüfen Sie das genaue Enddatum mit Ihrem Datenschutzbeauftragten. Die Schweiz setzt das revDSG (in Kraft seit dem 1. September 2023) durch und verfügt über einen langjährigen Angemessenheitsbeschluss der Kommission; Swiss-US DPF wurde mit Wirkung zum 15. September 2024 bestätigt. Praktisch ist das in diesem Beitrag verwendete Nürnberg-only-EU-Framing für beide dieselbe defensive Antwort — kein Transfer, keine Frage.

Ist GA4 in der EU jetzt unbedenklich?

Nein. Die Entscheidungen aus 2022 von österreichischer DSB / französischer CNIL / italienischer Garante / dänischer Datenschutzbehörde, die Google Analytics auf Schrems-II-Grundlage untersagten, wurden durch keine Entscheidung aus 2024–2026 aufgehoben. Der Hamburger Sweep (60 % der Pre-Consent-Tracking-Verstöße) ist das stärkste Signal aus 2025. Was auch immer die EuGH-Berufung zum DPF mit dem rechtlichen Bild macht — das Durchsetzungs-Bild im Jahr 2026 behandelt GA4 weiterhin als Hochrisiko-Standard.

Ist eine gehashte IP nicht anonym?

Nein, und der EDSA hat das in den Leitlinien 01/2025 (16. Januar 2025) ausdrücklich festgestellt. Pseudonymisierte Daten sind personenbezogene Daten, sobald eine Re-Identifizierung nach vernünftigem Ermessen wahrscheinlich ist. Eine tägliche Salt-Rotation reduziert die Re-Identifizierung über Tage hinweg, weshalb wir sie einsetzen — aber die resultierenden Hashes sind innerhalb eines Tages weiterhin personenbezogene Daten, und wir behandeln sie auch so.

Fazit

Im Jahr 2026 ist DSGVO-konforme Web-Analytics ein Design-Problem, kein Copy-Deck-Problem. Die vier Brennpunkte — Drittlandtransfers, Rechtsgrundlage, Einwilligung, Speicherdauer — haben jeweils eine architektonische Antwort, die strikt einfacher zu verteidigen ist als die vertragliche. Die Doppelsanktion der CNIL im September 2025 hat „wir setzen ein Banner ein” als Verteidigung erledigt; die Pseudonymisierungs-Leitlinien des EDSA haben „wir hashen die IP” als Verteidigung erledigt; der Hamburger Sweep hat den Pre-Consent-GA-Tag zum kanonischen Verstoß gemacht. Der sauberste Stack 2026 ist einer, in dem die riskantesten Trigger nicht feuern, weil sie gar nicht erst im Code stehen.

Genau dafür ist Statnive Live da. Cookielos. EU-only. AVV nach Art. 28 Abs. 3 auf jedem Tarif. Kein Fingerprinting, kein Drittanbieter-CDN, kein per Konstruktion erforderliches Banner. Bald verfügbar unter statnive.de/live. Bis dahin steht das WordPress-Plugin auf WordPress.org kostenlos bereit, der Vergleichsbeitrag erklärt, welches Produkt zu welcher Website passt, und die ursprüngliche Privacy-First-Übersicht ist die Einseiter-Variante dieses Beitrags.

Wenn sich etwas hier als falsch herausstellt, schreiben Sie mir — jede regulatorische Quelle hat eine URL, und wir korrigieren lieber eine Fußnote, als eine geschliffene Halbwahrheit auszuliefern.