Analytics 2027: Was die EU-Cookie-Reform technisch für Web-Tracking bedeutet

Warum 2027 zum Umbaujahr für Web-Analytics wird

Die EU steht kurz davor, Reichweitenmessung ohne Einwilligung wieder zu erlauben – aber nur für ein eng definiertes, technisch sauberes Messdesign. Wer 2027 noch mit einem einzigen Tracking-Setup arbeitet, das komplett am Cookie-Banner hängt, verschenkt Daten und riskiert gleichzeitig Verstöße.

Seit Jahren gilt in der EU: Jeder Zugriff auf das Endgerät, der nicht unbedingt nötig ist, braucht eine Einwilligung. In Deutschland regelt das § 25 TDDDG, europäisch Art. 5 Abs. 3 der ePrivacy-Richtlinie. Das Ergebnis kennt jedes Analytics-Team: Lücken in den Daten, Modellierung statt Messung, Diskussionen über jeden Prozentpunkt Consent-Rate.

Der Rat der EU hat am 2. Oktober 2026 einen Mandatstext zum sogenannten Digital Omnibus vorgelegt. Der Text enthält eine Ausnahme für First-Party-Reichweitenmessung, die anonyme, aggregierte Informationen erzeugt. Das ist noch kein Gesetz. Es ist aber der klarste Hinweis seit 2018, wohin die Reise geht.

Für technisches Analytics bedeutet das: Die Messarchitektur wird zweigeteilt. Eine Basisschicht zählt einwilligungsfrei, eine Erweiterungsschicht misst detailliert mit Einwilligung. Dieser Beitrag zeigt, was rechtlich auf dem Tisch liegt, was die Ausnahme technisch verlangt und wie sich ein solches Setup heute schon bauen lässt.

Stand der Recherche: 10. Oktober 2026. Dieser Beitrag ist keine Rechtsberatung.

Der rechtliche Stand im Oktober 2026

Cookie-Regeln bleiben laut aktuellem Ratstext in der ePrivacy-Richtlinie, bekommen aber sechs feste Ausnahmen von der Einwilligungspflicht. Der ursprüngliche Plan der Kommission, Cookies in die DSGVO zu verschieben (neuer Art. 88a) und Browsersignale verpflichtend zu machen (Art. 88b), ist im Rat gescheitert.

Quellen: PPC Land, 9. Oktober 2026, Acompli, September 2026, Praxikon

Was der Ratstext für Analytics festlegt

Zugriff auf das Endgerät ist ohne Einwilligung erlaubt, wenn er ausschließlich einem dieser sechs Zwecke dient und dafür unbedingt nötig ist:

1. Übertragung einer elektronischen Kommunikation
2. ein ausdrücklich angeforderter Dienst (z. B. Warenkorb, Spracheinstellung)
3. First-Party-Reichweitenmessung mit anonymen, aggregierten Ergebnissen
4. Medien-Reichweitenmessung nach Art. 24 European Media Freedom Act
5. technische Sicherheit des Dienstes oder Endgeräts
6. Messung von Auslieferung und Erfolg kontextueller Werbung, inklusive Frequency Capping

Dazu kommen zwei Regeln für das Banner selbst: Ablehnen muss mit einem Klick möglich sein. Nach einer Ablehnung darf für denselben Zweck mindestens vier Monate nicht erneut gefragt werden. Durchgesetzt werden soll das künftig von den Datenschutzaufsichtsbehörden.

Was noch offen ist

Das Parlament hat noch keine Position. Erst wenn beide Seiten ein Mandat haben, beginnen die Trilog-Verhandlungen, und dort kann sich jede Ausnahme noch ändern. Der Europäische Rat will alle Omnibus-Pakete bis Ende 2026 abschließen; realistisch ist eine Einigung im Lauf des Jahres 2027.

Auch die Fristen sind widersprüchlich: Die ePrivacy-Änderung soll sechs Monate nach Veröffentlichung gelten, die Mitgliedstaaten bekommen aber 24 Monate für die Umsetzung. In Deutschland müsste § 25 TDDDG angepasst werden. Eine verlässliche Rechtsgrundlage für einwilligungsfreie Messung ist deshalb eher Ende 2027 bis 2028 zu erwarten – genug Zeit, die Technik vorzubereiten, aber zu wenig, um erst nach Inkrafttreten anzufangen.

Einwilligungsfreie Reichweitenmessung: was technisch darunter fällt

Die Ausnahme deckt Zählen und Aggregieren ab, nicht Profilbildung. Entscheidend sind drei Bedingungen aus dem Ratstext: Die Messung erfolgt durch den Websitebetreiber selbst oder einen Dienstleister in dessen Auftrag. Das Ergebnis sind anonyme, aggregierte Informationen über die Nutzung des eigenen Dienstes. Die erhobenen Daten werden nicht für andere Zwecke genutzt, nicht an Dritte weitergegeben und nicht mit Daten Dritter kombiniert.

Besonders folgenreich ist Erwägungsgrund 44d. Der Erwägungsgrund schließt die Kombination mit Daten aus anderen Diensten des Anbieters oder von Dritten aus, ausdrücklich auch mit Analysedaten anderer Websites. Damit fallen Tools heraus, die Daten über Kundengrenzen hinweg für Benchmarks oder Modelle zusammenführen.

Die CNIL-Ausnahme als technische Vorlage

Frankreich erlaubt einwilligungsfreie Reichweitenmessung schon seit den CNIL-Leitlinien vom 1. Oktober 2020. Die dortigen Auflagen sind der beste verfügbare Anhaltspunkt dafür, wie Aufsichtsbehörden die EU-Ausnahme später auslegen dürften. Adobe fasst sie in seiner Dokumentation so zusammen (Quelle):

Übersetzt in typische Analytics-Funktionen

Die folgende Einordnung ist eine Einschätzung auf Basis des Ratstextes vom 2. Oktober 2026 und der CNIL-Praxis, kein gesichertes Recht.

Browsersignale: vom Rat gestrichen, technisch trotzdem Pflicht

Das verpflichtende Browsersignal (Art. 88b) steht nicht mehr im Ratstext, ist aber nicht vom Tisch. 19 Organisationen haben im September 2026 seine Rückkehr gefordert, EDPB und EDPS unterstützen es, und das Parlament kann es im Trilog wieder einbringen. Unabhängig davon kommt das Signal ohnehin in die Browser.

Der Grund liegt in Kalifornien: Das Gesetz AB 566 verlangt, dass jeder Browser für Einwohner Kaliforniens bis zum 1. Januar 2027 ein Opt-out-Signal senden kann. Der naheliegende Standard ist Global Privacy Control (GPC), das derzeit beim W3C standardisiert wird. Firefox, Brave und DuckDuckGo unterstützen GPC bereits, laut einer Studie vom Mai 2026 erklären rund 388.000 Websites die Unterstützung (Quelle). Damit landet das Signal 2027 auch bei europäischen Besuchern.

Wie GPC technisch ankommt

GPC ist ein einzelnes Bit. Ist es aktiv, sendet der Browser bei jedem Request den Header Sec-GPC: 1 und setzt im DOM navigator.globalPrivacyControl = true. Ist es inaktiv, fehlt der Header. Optional erklärt eine Website über /.well-known/gpc.json, dass sie das Signal beachtet.

// Client: GPC-Status vor dem Laden der Erweiterungsschicht prüfen
const gpc = navigator.globalPrivacyControl === true;
if (gpc) {
  consentState.marketing = 'denied';   // Ablehnung, keine Einwilligung
}

# Server: Header ins Log schreiben, um die GPC-Quote zu messen
log_format analytics '$time_iso8601 $request_uri gpc=$http_sec_gpc';

Was das Signal bedeutet – und was nicht

GPC kann nur ablehnen oder widerrufen, nie einwilligen. Für die Erweiterungsschicht heißt das: GPC aktiv bedeutet Werbe- und Weitergabe-Tags aus, ohne Banner-Nachfrage. Die einwilligungsfreie Basismessung berührt GPC dagegen nicht, weil reine First-Party-Statistik außerhalb seines Anwendungsbereichs liegt.

Ein Detail wird oft übersehen: GPC muss serverseitig weitergereicht werden. Wer Ereignisse über serverseitige Schnittstellen an Werbeplattformen schickt, etwa die Conversions API von Meta, muss den Signalstatus im eigenen Backend mitführen und den Versand unterdrücken. Der Browser kann das nicht für den Server erledigen.

Empfehlung für 2027: GPC jetzt als harte Ablehnung behandeln und die GPC-Quote als eigene Kennzahl erfassen. Falls das Parlament ein verpflichtendes Signal durchsetzt, ist die Logik dann schon vorhanden.

Die Zwei-Schichten-Messarchitektur

Jedes Ereignis läuft über einen eigenen Endpunkt, der nach Einwilligungsstatus verteilt. Die Basisschicht bekommt immer eine reduzierte, anonymisierte Fassung, die Erweiterungsschicht nur bei Einwilligung.

Die Basisschicht beantwortet die Frage „Wie viel passiert?“: Besuche, Seitenaufrufe, Quellen, Conversions als Zähler. Die Basisschicht arbeitet mit eigenen Identifiern, festen Laufzeiten und ohne jede Weitergabe. Die Erweiterungsschicht beantwortet „Wer macht was und warum?“: Pfade, Attribution, Zielgruppen, Werbe-Conversions.

Der Endpunkt schreibt in jedes Ereignis ein Feld consent_state mit drei Werten: basis (noch keine Entscheidung), granted (Einwilligung erteilt) und denied (aktiv abgelehnt, per Banner oder GPC). Damit ist jederzeit nachweisbar, unter welcher Grundlage ein Datensatz entstanden ist.

Umsetzung in GA4, Matomo, serverseitigem Tagging und eigener Pipeline

Für die Basisschicht eignen sich vor allem Werkzeuge, bei denen die Daten den eigenen Kontrollbereich nicht verlassen. GA4 gehört in die Erweiterungsschicht, selbst gehostetes Matomo oder eine eigene Pipeline in die Basisschicht.

GA4: klar in die Erweiterungsschicht

GA4 im Consent Mode „advanced“ sendet auch ohne Einwilligung cookielose Pings, aus denen Google Daten modelliert. Genau diese Modellierung stützt sich auf Daten, die Google über viele Properties hinweg auswertet. Das passt schlecht zu Erwägungsgrund 44d, der die Kombination mit Analysedaten anderer Websites ausschließt. GA4 bleibt damit ein Werkzeug für Besucher mit Einwilligung, im Consent Mode „basic“ ohne Pings vor der Einwilligung.

Matomo: annähernd CNIL-konform konfigurieren

var _paq = window._paq = window._paq || [];
_paq.push(['setVisitorCookieTimeout', 33955200]); // 393 Tage, knapp unter 13 Monaten
_paq.push(['setReferralCookieTimeout', 0]);       // kein separates Kampagnen-Cookie
_paq.push(['disableBrowserFeatureDetection']);    // weniger Gerätemerkmale
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);

Im Backend kommen hinzu: IP-Anonymisierung auf mindestens zwei Bytes, automatisches Löschen alter Rohdaten nach spätestens 25 Monaten und deaktivierte User-ID- und E-Commerce-Kundenzuordnung in der Basis-Property. Wichtig ist, dass Matomo die Cookie-Laufzeit bei jedem Besuch verlängert. Eine feste, nicht rollierende Laufzeit erfordert ein kleines Zusatzskript, das das Erstsetzungsdatum speichert.

Serverseitiges Tagging: der Verteiler zwischen den Schichten

Ein First-Party-Tagging-Server auf einer eigenen Subdomain nimmt alle Ereignisse an und entscheidet anhand des Einwilligungsstatus, wohin sie gehen. Basis-Ereignisse gehen nur in die eigene Analytics-Datenbank. Erst mit Einwilligung gehen angereicherte Ereignisse an GA4, Werbeplattformen oder ein CRM.

Technisch relevant: Safari begrenzt seit Version 16.4 Cookies, die von einem Server mit fremder IP-Adresse gesetzt werden, auf sieben Tage. Liegt der Tagging-Server bei einem Cloud-Anbieter und nicht im selben IP-Bereich wie die Website, verfallen seine Cookies entsprechend schnell. Die Lösung ist ein Reverse-Proxy-Pfad auf der Hauptdomain, etwa /metrics/, statt einer CNAME-Subdomain.

Eigene Pipeline: minimaler Basis-Beacon

// Läuft ohne Einwilligung: nur Seitenkontext, keine Gerätemerkmale
(function () {
  const data = {
    p: location.pathname,
    r: document.referrer ? new URL(document.referrer).hostname : '',
    u: new URLSearchParams(location.search).get('utm_source') || ''
  };
  navigator.sendBeacon('/metrics/hit', JSON.stringify(data));
})();

-- Server (ClickHouse): tägliche Aggregation, Rohdaten danach löschen
INSERT INTO daily_pages (day, path, source, hits)
SELECT toDate(ts), path, coalesce(nullIf(utm, ''), ref_host), count()
FROM raw_hits
WHERE toDate(ts) = yesterday()
GROUP BY 1, 2, 3;

ALTER TABLE raw_hits DELETE WHERE ts < now() - INTERVAL 7 DAY;

Der Beacon setzt kein Cookie und liest keine Gerätemerkmale aus. Das macht ihn aber nicht automatisch einwilligungsfrei: Die EDPB-Leitlinien 2/2023 legen Art. 5 Abs. 3 ePrivacy weit aus und erfassen auch Pixel und URL-basiertes Tracking. Die neue Messausnahme ist deshalb die robustere Grundlage als die Behauptung, gar nicht auf das Gerät zuzugreifen.

Datenqualität: zwei Schichten, zwei Wahrheiten

Die Basisschicht liefert die Reichweite, die Erweiterungsschicht das Verhalten. Beide Zahlen widersprechen sich zwangsläufig, und genau dieser Unterschied wird zur wertvollsten neuen Kennzahl: der tatsächlich gemessenen Einwilligungsquote pro Segment.

Hochrechnen statt modellieren

Statt Black-Box-Modellierung durch einen Anbieter lässt sich Verhalten transparent hochrechnen. Dafür wird für jedes Segment s (z. B. Quelle × Gerätetyp) der Faktor aus Basis- und Erweiterungsbesuchen gebildet:

Ĉ = Σ_s C_erw,s · B_basis,s / B_erw,s

Dabei ist C die Zahl einer Kennzahl in der Erweiterungsschicht und B die Zahl der Besuche; der Index „erw“ steht für die Erweiterungsschicht, „basis“ für die Basisschicht. Die Segmentierung ist wichtig, weil Besucher mit Einwilligung sich systematisch unterscheiden: Wer über eine Marken-Suche kommt, willigt in der Praxis oft häufiger ein als jemand aus einer Display-Kampagne. Ein einziger globaler Faktor würde diese Verzerrung verstecken.

Die Schichten nie über IDs verknüpfen

Der Abgleich findet ausschließlich auf aggregierter Ebene statt. Sobald eine Basis-ID mit einer Erweiterungs-ID verknüpft wird, ist die Basisschicht nicht mehr anonym, und die Ausnahme fällt weg. Technisch heißt das: getrennte Tabellen, getrennte Identifier, Abgleich nur über Tageswerte je Segment.

Browser-Eigenheiten, die beide Schichten verzerren

• Cookie-Laufzeiten in Safari: Per JavaScript gesetzte Cookies leben in Safari höchstens sieben Tage, bei Ankunft über Links mit Tracking-Parametern teils nur 24 Stunden. „Neue Besucher“ sind dort systematisch überhöht. Kennzahlen zu wiederkehrenden Besuchern sollten deshalb nach Browserfamilie getrennt ausgewiesen werden.
• Entfernte Klick-IDs: Safaris Link Tracking Protection entfernt bekannte Klick-Parameter in privaten Fenstern, Mail und Nachrichten. UTM-Parameter bleiben in der Regel erhalten und sind für die Basisschicht ohnehin die bessere Quelleninformation.
• Automatisierter Traffic: Ohne Banner als natürlichen Filter sieht die Basisschicht deutlich mehr Bots. Eine Bot-Erkennung über User-Agent-Listen, Anfrageraten und Plausibilitätsprüfungen (z. B. Seitenaufruf ohne jede Interaktion) ist Pflicht.
• Plausibilitätsabgleich: Basis-Besuche regelmäßig gegen Server- oder CDN-Logs prüfen. Weicht die Basisschicht um mehr als einen stabilen Prozentsatz ab, blockieren Werbeblocker den Beacon-Pfad oder der Bot-Filter greift falsch.

Typische Fehler bei der Umstellung

Der häufigste Fehler wird sein, die Ausnahme als Freibrief für das bestehende Setup zu lesen. Die Ausnahme erlaubt ein neues, schmaleres Messdesign, nicht das alte ohne Banner.

1. Ein Tool für beide Schichten mit derselben ID. Wenn die Basis-Property und die Property mit Einwilligung denselben Identifier teilen, ist die Trennung nur noch kosmetisch.
2. Rollierende Cookie-Laufzeiten. Ein Cookie, das sich bei jedem Besuch um 13 Monate verlängert, lebt faktisch unbegrenzt. Die CNIL-Praxis verlangt eine feste Ablaufzeit ab Erstsetzung.
3. Weitergabe über den Server-Container. Serverseitiges Tagging verlagert die Datenflüsse nur aus dem Blickfeld. Leitet der Container Basis-Ereignisse an Werbeplattformen weiter, ist das eine Weitergabe an Dritte.
4. UTM-Werte mit Personenbezug. Newsletter-Links mit E-Mail-Adresse oder Kunden-ID im UTM-Parameter machen aus anonymer Statistik personenbezogene Daten. Solche Parameter sind vor dem Speichern zu entfernen.
5. Volle IP-Adressen im Rohdaten-Log. Die Kürzung muss vor dem Schreiben passieren, nicht in einem nächtlichen Job. Auch Webserver- und CDN-Logs zählen dazu.
6. Einwilligungsstatus nicht im Ereignis. Ohne ein Feld wie consent_state in jedem Ereignis lässt sich später weder prüfen noch nachweisen, welche Daten unter welcher Grundlage erhoben wurden.
7. Die Vier-Monats-Sperre im falschen Speicher. Wird die Ablehnung nur in einem Cookie gespeichert, das Safari nach sieben Tagen löscht, darf das Banner zwar laut Ratstext erneut erscheinen. Wer die Regel ernst nimmt, legt die Ablehnung trotzdem in einem serverseitig gesetzten First-Party-Cookie ab.
8. Auf das finale Gesetz warten. Die Umbauten an Datenmodell, Tagging-Server und Reporting dauern Monate. Wer erst nach Inkrafttreten anfängt, misst ein weiteres Jahr mit Lücken.

Checkliste für 2027

Diese Punkte lassen sich unabhängig vom finalen Gesetzestext umsetzen, weil sie auch unter heutigem Recht sauberer und unter dem künftigen Recht nötig sind.

Bestandsaufnahme

• Alle Tags, Pixel und serverseitigen Weiterleitungen inventarisieren, jeweils mit Zweck und Empfänger
• Jedes Tag einer Schicht zuordnen: Basis (einwilligungsfrei geplant) oder Erweiterung (Einwilligung nötig)
• Prüfen, welche Tools Daten für eigene Zwecke, Benchmarks oder Modelle nutzen

Basisschicht aufbauen

• Selbst gehostetes Matomo oder eigene Beacon-Pipeline aufsetzen, getrennt von der Erweiterungs-Property
• Cookie-Laufzeit fest auf maximal 13 Monate, ohne Verlängerung bei jedem Besuch
• IP-Kürzung vor dem Speichern, auch in Webserver- und CDN-Logs
• Rohdaten-Löschung nach spätestens 25 Monaten, besser nach Aggregation
• Personenbezogene Werte aus UTM- und Query-Parametern entfernen
• Bot-Filter einrichten und gegen Server-Logs plausibilisieren
• Opt-out-Mechanismus für die Basismessung bereitstellen

Erweiterungsschicht und Signale

• Ablehnen mit einem Klick, gleichwertig zum Akzeptieren
• Ablehnung serverseitig für mindestens vier Monate speichern
• GPC (Sec-GPC und navigator.globalPrivacyControl) als harte Ablehnung behandeln
• GPC- und Einwilligungsstatus bis in serverseitige Schnittstellen durchreichen

Reporting

• Feld consent_state in jedem Ereignis
• Reichweite aus der Basisschicht, Verhalten aus der Erweiterungsschicht berichten
• Einwilligungsquote und GPC-Quote je Quelle und Gerät als feste Kennzahlen
• Hochrechnung nur segmentiert, nie mit einem globalen Faktor
• Kennzahlen zu wiederkehrenden Besuchern nach Browserfamilie trennen

Fazit

2027 entscheidet sich, ob Web-Analytics in der EU wieder vollständige Reichweitenzahlen liefern darf. Der Ratstext vom 2. Oktober 2026 zeigt die Richtung: Messen ja, Profilbildung nein. Belohnt wird ein Messdesign, das in Daten ohne Einwilligung bewusst auf Personenbezug, Weitergabe und Verknüpfung verzichtet.

Die Zwei-Schichten-Architektur ist dabei kein Notbehelf, sondern das bessere Setup. Die Architektur trennt saubere Reichweite von detailliertem Verhalten, macht die Einwilligungsquote erstmals exakt messbar und ersetzt undurchsichtige Modellierung durch nachvollziehbare Hochrechnung. Der finale Gesetzestext kann Details noch verschieben. An der Grundarchitektur ändert das wenig – und wer sie bis Mitte 2027 aufgebaut hat, ist am Tag des Inkrafttretens fertig statt im Projektstart.