Cloudflare Zaraz Consent-Integrationshandbuch: Server-seitiges Tag-Management am Edge für 2026
Cloudflare Zaraz unterscheidet sich von den meisten Tag-Management-Produkten, die zuvor erschienen sind. Die Prämisse ist strukturell statt inkrementell: Anstatt Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight und das JavaScript jedes anderen Anbieters in den Browser des Besuchers zu laden, führt Zaraz diese Integrationen innerhalb von Cloudflare Workers aus, die am Edge vor dem Ursprungsserver des Publishers laufen. Der Browser sieht lediglich eine einzige kleine Zaraz-Runtime; die Anbieter-Tools laufen server-seitig. Diese architektonische Entscheidung hat kumulierende Auswirkungen auf die Einwilligung. Die Cookie-Oberfläche schrumpft dramatisch, weil die meisten Anbieter-Cookies erst gar nicht gesetzt werden. Die Fingerprinting-Oberfläche schrumpft, weil das meiste JavaScript der Anbieter nie im Browser-Kontext ausgeführt wird. Und der Durchsetzungspunkt für die Einwilligung verschiebt sich von einem JavaScript-Banner, das einen Stapel <script>-Tags blockiert, hin zu einer server-seitigen Entscheidung, die bestimmt, welche Zaraz-Integrationen ausgelöst werden und welche Payload sie erhalten. Der Publisher, der Zaraz korrekt mit einem CMP verbindet, erhält eine kleinere Compliance-Oberfläche, schnellere Seiten und einen klareren Audit-Trail. Der Publisher, der Zaraz wie einen schnelleren Google Tag Manager behandelt und die Einwilligungsverkabelung überspringt, erhält eine regulatorische Exposition, die schwerer zu erkennen ist, weil so viel der Aktivität für Standard-Browser-basierte Audits unsichtbar ist.
Was Zaraz am Edge tatsächlich tut
Zaraz ist ein server-seitiger Tag-Manager, der innerhalb von Cloudflare Workers ausgeführt wird. Wenn ein Besucher eine Seite lädt, enthält das HTML des Publishers ein kleines Zaraz-Initialisierungsskript — typischerweise ein paar Kilobyte — das einen strukturierten Ereignis-Payload aus dem Browser sammelt (Seitenaufruf, Klick, benutzerdefiniertes Ereignis) und diesen per POST an einen Cloudflare-Endpoint auf der eigenen Domain des Publishers sendet. Der Worker empfängt diesen Payload und führt die konfigurierten Zaraz-Tools dagegen aus: Eine Google Analytics 4-Integration sendet einen Measurement Protocol-Hit, eine Meta Pixel-Integration sendet ein Conversions API-Ereignis, eine Mixpanel-Integration sendet einen HTTP API-Aufruf. Das JavaScript des Drittanbieters wird nie in den Browser geladen, die Cookies des Anbieters werden entweder überhaupt nicht gesetzt oder über die First-Party-Domain von Cloudflare via Worker geschrieben, und der Anbieter erhält nur die Daten, die die Zaraz-Konfiguration des Publishers explizit weiterleitet.
Das ist das architektonische Wertversprechen. Es ist auch der Grund, warum das Einwilligungsbild anders ist als bei jedem clientseitigen Tag-Manager. Bei einem traditionellen Setup ist die Einwilligungsfrage, ob das JavaScript des Anbieters geladen wird oder nicht. Bei Zaraz wird JavaScript in keinem Fall geladen — die Frage wird, ob der server-seitige Payload gesendet oder unterdrückt wird, und ob der Payload die Identifikatoren enthält, die der Anbieter zum Tracking des Nutzers benötigt. Beide Fragen haben in der Zaraz Consent API klar definierte Antworten; die Aufgabe des Publishers besteht darin, sie korrekt zuzuordnen.
Die Zaraz Consent API und wie sie sich von clientseitigen CMPs unterscheidet
Zaraz wird mit einem integrierten Einwilligungsmodul geliefert — Zaraz Consent Tools — das einen Einwilligungsstatus pro Besucher pflegt und steuert, welche konfigurierten Tools ausgelöst werden. Der Status wird über eine kleine JavaScript API zugänglich gemacht: zaraz.consent.set({ analytics: true, marketing: false }) zum Aufzeichnen einer Benutzerentscheidung, zaraz.consent.get('analytics') zum Lesen, zaraz.consent.getAll() für die vollständige Zuordnung, zaraz.consent.modal() zum Öffnen der Einwilligungs-UI und Ereignis-Listener auf zaraz.consent.onModalShown und verwandten Ereignissen für benutzerdefiniertes UI-Verhalten. Jedes Zaraz-Tool im Dashboard wird mit einer oder mehreren Zweck-IDs konfiguriert, und der Worker führt ein Tool nur aus, wenn die relevanten Zwecke im Einwilligungsstatus des Besuchers gewährt wurden.
Die Integrationswahl besteht darin, ob der integrierte Einwilligungs-Modal von Zaraz verwendet oder Zaraz mit einem externen CMP verbunden wird. Der integrierte Modal ist der einfachste Weg: Consent Tools aktivieren, Zwecke definieren, jedes Tool mit dem richtigen Zweck konfigurieren und veröffentlichen. Der externe CMP-Weg ist die richtige Wahl für Organisationen, die bereits auf Cookiebot, OneTrust, Usercentrics oder ein benutzerdefiniertes CMP standardisieren — Zaraz arbeitet dann nachgelagert zum CMP, wobei das CMP zaraz.consent.set() aufruft, wenn sich der Benutzer durch das Banner bewegt. Beide Wege landen am gleichen Durchsetzungspunkt: Der Worker prüft den Einwilligungsstatus, bevor jedes Tool ausgeführt wird, und Tools, deren Zwecke nicht gewährt wurden, werden schlicht nicht ausgeführt.
IAB TCF-Unterstützung und die regionalen Regime
Zaraz hat 2023 die Unterstützung für IAB TCF v2 hinzugefügt und das Framework seitdem verfolgt. Für Publisher, die im EEA und im UK unter TCF-basierten Werbepartnerschaften tätig sind, übersetzt die Integration den TCF-Einwilligungsstring automatisch in den Zaraz-Zweckstatus, wenn der Publisher sich anmeldet. Für Nicht-TCF-Regionen ordnet der Publisher benutzerdefinierte Zwecke — typischerweise analytics, marketing, personalization, functional — direkt den relevanten Zaraz-Tools zu. Derselbe Worker setzt beide durch, was bedeutet, dass eine einzige Zaraz-Konfiguration sowohl einen EEA-Besucher über TCF als auch einen kalifornischen Besucher über ein benutzerdefiniertes Marketing-Zweck-Gate ohne zwei parallele Pipelines bedienen kann.
Warum Zaraz das DSGVO- und ePrivacy-Bild verändert
Die rechtliche Position unter DSGVO, ePrivacy und CCPA wird durch die server-seitige Ausführung nicht ausgenommen — die Rechtsgrundlage folgt den Daten, nicht dem Transport — aber die praktische Compliance-Oberfläche ändert sich. Drei Verschiebungen sind bedeutsam.
- Die Cookie-Oberfläche schrumpft. Die meisten Anbieter-Cookies werden nie geschrieben, weil das JavaScript des Anbieters nie im Browser läuft. Die verbleibenden Cookies sind typischerweise Zaraz's eigener Sitzungsidentifikator und etwaige First-Party-Identifikatoren, die der Publisher bewusst propagiert hat. Die nicht-wesentliche Cookie-Oberfläche, die das Banner steuern muss, ist daher dramatisch kleiner — manchmal nur ein oder zwei Cookies gegenüber dem Dutzend und mehr, das ein typischer clientseitiger Stack produziert.
- Die Drittanbieter-Transfer-Offenlegung ändert sich. Da der Worker Daten über Server-zu-Server-Aufrufe an die Anbieter sendet, verläuft der Datenpfad vom Browser des Besuchers zum Edge von Cloudflare und von dort zu den konfigurierten Anbietern. Die Datenschutzerklärung muss dies widerspiegeln — Cloudflare ist ein Auftragsverarbeiter und jedes Zaraz-Tool ist ein nachgelagerter Empfänger — aber die Offenlegung ist in vielerlei Hinsicht klarer als der entsprechende clientseitige Pfad, weil der Publisher die volle Kontrolle darüber hat, was weitergeleitet wird.
- Der Audit-Trail ist zentralisierter. Da jedes Anbieter-Ereignis durch den Worker läuft, hat der Publisher einen einzigen Punkt, an dem Einwilligungsstatus, Ereignis-Payload und nachgelagerter Empfänger protokolliert werden können. Regulatoren, die ein abfragbares Einwilligungsprotokoll erwarten, haben mit Zaraz eine klarere Antwort als mit einem Durcheinander clientseitiger Tags.
Das Integrationsmuster, das funktioniert
Das Referenz-Deployment hat vier bewegliche Teile. Der erste ist die Zaraz-Initialisierung auf der Seite, geladen von der Domain des Publishers über Cloudflares Proxy. Der zweite ist entweder der integrierte Consent Tools-Modal oder ein externes CMP, das zaraz.consent.set() aufruft, wenn der Benutzer Entscheidungen trifft. Der dritte ist die Zaraz-Dashboard-Konfiguration, die jedes Tool den richtigen Zwecken zuordnet — Analytics-Tools dem Analytics-Zweck, Werbungs-Tools dem Marketing-Zweck, Session-Replay-Tools einem strengeren funktionalen oder Forschungszweck und jedes von Drittanbieter-Transfers abhängige Tool dem grenzüberschreitenden Transfer-Zweck, wenn die Datenschutzerklärung des Publishers dies als separate Entscheidung ausweist. Der vierte ist ein server-seitiges Protokoll — entweder Cloudflare Analytics, Logpush zu einem Data-Lake des Publishers oder ein benutzerdefinierter Worker, der Einwilligungsentscheidungen in einen abfragbaren Speicher schreibt — damit der Einwilligungsnachweis auf Anfrage der Regulierungsbehörde vorgelegt werden kann.
Der Validierungsschritt ist die gleiche Vier-Prüf-Sequenz, die für jede Einwilligungsintegration gilt, aber mit einem Zaraz-spezifischen Twist. Eine saubere Browser-Sitzung mit angezeigtem Banner, aber ohne getroffene Entscheidung, sollte null Anfragen vom Browser des Besuchers an eine Anbieter-Domain und null nicht-wesentliche Cookies erzeugen — beides leichter mit Zaraz zu bestätigen als mit einem clientseitigen Stack, weil das Fehlen von Drittanbieter-Anfragen der Standard ist und keine konfigurierte Ausnahme. Ein Ablehnungsbesuch sollte diesen Zustand beibehalten. Ein Annahmebesuch sollte die Zaraz-Endpoint-POSTs erzeugen, die nur die Ereignisse tragen, denen der Benutzer zugestimmt hat, und die Worker-Protokolle sollten die nachgelagerten Tool-Ausführungen zeigen. Ein Widerruf sollte sofort weitere Worker-Tool-Ausführungen stoppen, alle von Zaraz gesetzten Cookies ablaufen lassen und die entsprechenden Lösch- oder Opt-out-Signale an die konfigurierten nachgelagerten Anbieter auslösen.
Wo Zaraz noch sorgfältige Behandlung erfordert
Zaraz ist keine Consent-by-Architecture-Lösung, die das Nachdenken überflüssig macht. Drei Bereiche erfordern bewusstes Handling. Click-to-Load-Einbettungen — YouTube, Twitter, Instagram, TikTok-Video — benötigen weiterhin das gleiche Platzhalter-Muster, das jedes Consent-first-Deployment verwendet, weil Zaraz derzeit keine eingebetteten Video-iframes proxied. Clientseitige Identifikatoren, die der Publisher im Browser für First-Party-Zwecke setzen möchte — eine eingeloggte Benutzer-ID, ein Session-Token, ein A/B-Test-Bucket — verbleiben auf der Publisher-Seite der Einwilligungsgrenze und benötigen ihre eigene Gate-Logik. Und die Datenschutzerklärung muss das server-seitige Transfer-Modell genau beschreiben, einschließlich der Rolle von Cloudflare als Auftragsverarbeiter und des geografischen Standorts der Workers, die die Daten verarbeiten, weil der Cloudflare-Edge in mehreren Regionen läuft und der Datenverkehr des Besuchers in einer Region verarbeitet werden kann, die nicht seine eigene ist. Mit all dem gehandhabt, verwandelt sich ein Zaraz-Deployment im Jahr 2026 von einem Tag-Management-Produkt in eine der saubersten Einwilligungsarchitekturen, die ein Publisher betreiben kann: kleinere Cookie-Oberfläche, weniger Drittanbieter-Anfragen, zentralisierte Durchsetzung und ein Audit-Trail, den ein Regulator tatsächlich lesen kann.