Google Consent Mode v2 im Headless-Frontend umsetzen

Google Consent Mode v2 ist eine Produktanforderung von Google, kein Schweizer Gesetz — und genau diese Verwechslung führt zu falschen Schlüssen. Die Signale werden relevant, wenn Sie Google Ads oder GA4 nutzen und EU/EWR-, UK- oder (seit dem 31. Juli 2024) Schweizer Nutzer messen. Fehlen sie, erfasst Google für diese Nutzer praktisch keine neuen Conversion-Daten mehr. Eine rein Schweizer Firma ohne Google-Ads-Targeting braucht den Mechanismus dagegen nicht zwingend. Welches Analyse-Tool überhaupt zu Ihrem Mess-Ziel passt, ordnet der Beitrag zu DSG-konformem Tracking mit Plausible oder Google Analytics ein — hier geht es ausschliesslich um die technische Umsetzung im entkoppelten Frontend.

Denn im Headless-Aufbau liegt die eigentliche Arbeit nicht in der CMP-Wahl, sondern in der Lade-Reihenfolge: Der gtag-Default-State muss feuern, bevor irgendein Google-Tag liest. Genau diese Verdrahtung — Default-States vor dem CMP-Load, beforeInteractive versus afterInteractive, Update-Events, optionaler Server-Side-Relay — deckt kein CMP-Anbieter in seiner Standard-Dokumentation ab. Sie zeigen die klassische WordPress-Einbindung, nicht den App Router. Dieser Beitrag schliesst diese Lücke. Die rechtliche Einordnung nach revDSG bleibt beim Beitrag zu Headless WordPress und Datenschutz nach revDSG — und dies ist ausdrücklich keine Rechtsberatung.

Gilt Consent Mode v2 überhaupt für Ihre Website?

Consent Mode v2 ist eine Anforderung von Google, nicht des Schweizer Rechts. Sie gilt, wenn Sie Google Ads, GA4 oder den Google-Marketing-Stack nutzen und EU/EWR-, UK- oder seit Juli 2024 Schweizer Nutzer messen. Eine rein Schweizer Firma ohne Google-Ads-Targeting — etwa mit Plausible — ist von Consent Mode v2 technisch gar nicht betroffen.

Kein revDSG-Paragraph verlangt Consent Mode v2. Das revidierte Datenschutzgesetz schreibt keinen Cookie-Banner vor; nach Art. 45c FMG genügt für Cookies die Information, eine Einwilligung ist nur bei EU-Targeting (ePrivacy) oder besonders schützenswerten Daten nötig. Diese Einordnung stützt sich auf die Analyse von Steiger Legal zum Cookie-Banner unter dem neuen Datenschutzgesetz. Die Anforderung kommt aus einer ganz anderen Ecke: Googles eigener EU User Consent Policy.

Für den EWR und UK wurde diese Policy durch den Digital Markets Act getrieben und ist seit dem 6. März 2024 wirksam — ohne Consent Mode v2 fliessen seither keine neuen EWR/UK-Daten mehr in Google-Audiences. Für die Schweiz kam der Stichtag später: Google hat seine EU User Consent Policy mit Wirkung zum 31. Juli 2024 auf Schweizer Traffic ausgeweitet. Entscheidend ist die Rahmung: Das ist eine Google-Policy, kein Schweizer Statut. Wer kein Google-Werbe- oder -Analyse-Produkt einsetzt, ist davon technisch nicht berührt.

Was bricht ohne Consent Mode v2 konkret weg?

Ohne korrekte Consent-Signale erfasst Google für betroffene Nutzer praktisch keine neuen Conversion- und Remarketing-Daten mehr. GA4-Audiences füllen sich nicht, Enhanced Conversions versagen, und Ad-Personalisierung entfällt. Das Modeling, mit dem Google fehlende Conversions aus cookielosen Pings rekonstruiert, funktioniert nur mit implementiertem Consent Mode als Datengrundlage.

Konkret heisst das: keine neuen EWR-, UK- oder (seit Juli 2024) CH-Daten in GA4-Audiences und Remarketing-Listen, weggebrochene Enhanced Conversions und ein blindes tag-basiertes Conversion-Tracking. Die Folge für die Praxis ist unangenehm direkt: Ihre Kampagnen-Optimierung läuft ohne Datengrundlage, das ROAS-Reporting wird unzuverlässig. Das trifft Performance-Marketing deutlich härter als eine reine Reichweiten-Messung — wer nur wissen will, welche Seiten gelesen werden, spürt es kaum; wer Budget auf Conversions optimiert, fliegt blind.

Der Hebel, der diesen Schaden begrenzt, ist das Conversion- und Behavioral-Modeling. Google beschreibt in der Tag-Platform-Dokumentation zum Consent Mode, wie bei Ablehnung cookielose Pings gesendet werden, aus denen Conversions modelliert werden. Aber: Dieses Modeling setzt einen korrekt implementierten Consent Mode voraus. Ohne ihn gibt es keine Pings, aus denen modelliert werden könnte — und damit auch keine Schätzung der entgangenen Conversions.

Die vier Consent-Signale verstehen

Consent Mode v2 erweitert die zwei v1-Signale (ad_storage, analytics_storage) um zwei neue: ad_user_data und ad_personalization. Jedes Signal nimmt den Wert granted oder denied an. Die Trennung erlaubt feinere Entscheidungen — ein Nutzer kann die Messung erlauben, personalisierte Werbung aber ablehnen, ohne dass beides am selben Schalter hängt.

Die beiden neuen Parameter sind in der Google-Ads-Hilfe zu Consent Mode definiert: ad_user_data setzt die Einwilligung «for sending user data to Google for advertising purposes», ad_personalization die Einwilligung «for personalized advertising». Die Granularität ist real nutzbar: ad_user_data auf granted bei gleichzeitig ad_personalization auf denied ist ein valider Zustand — Sie dürfen Daten senden, aber nicht für Remarketing personalisieren.

Basic oder Advanced Consent Mode — welche Variante?

Basic blockiert Google-Tags vollständig, bis der Nutzer zustimmt — vorher fliessen keine Daten. Advanced lädt die Tags sofort mit Default denied und sendet cookielose Pings, aus denen Google Conversions modelliert. Advanced liefert mehr Datenqualität, ist aber heikler in der Reihenfolge — und genau an diesem Punkt scheitern Headless-Builds am häufigsten.

Der Unterschied ist in der Google-Dokumentation zum Consent-Mode-Konzept beschrieben: Bei Basic bleiben die Tags blockiert, bis der Nutzer interagiert — einfacher, aber mit weniger Daten. Bei Advanced laden die Tags mit Default denied und senden cookielose Pings, was ein advertiser-spezifisches, genaueres Conversion-Modeling ermöglicht. Der Preis dafür: Advanced verlangt korrekte Default-States vor jeder Tag-Ausführung — der kritische Punkt im entkoppelten Frontend.

Advanced Consent Mode steht und fällt mit einer einzigen Frage: Feuert der Default-State, bevor das erste Google-Tag liest? Im Headless-Frontend ist das keine Konfigurations-, sondern eine Architekturentscheidung.

Welche Variante passt, ist kein technischer Default, sondern eine Trade-off-Entscheidung entlang Ihres Datenschutz-Anspruchs — und keine Rechtsberatung. Wer vorher keine Daten erheben will, nimmt Basic: Die Tags warten ohnehin, das Reihenfolge-Risiko ist gering, dafür bleibt die Modeling-Qualität eingeschränkt. Wer das Modeling ausschöpfen und maximale Datenqualität im erlaubten Rahmen will, nimmt Advanced — und kauft sich damit das hohe Reihenfolge-Risiko ein, weil der Default vor jedem Tag feuern muss.

Consent Mode v2 im Next.js-Frontend korrekt verdrahten

Im entkoppelten Frontend entscheidet die Lade-Reihenfolge über Funktion oder Fehler. Der gtag-Default-State muss feuern, bevor irgendein Google-Tag liest. Im Next.js App Router heisst das konkret: Default-Consent und CMP über die Script-Strategie beforeInteractive, GA4 beziehungsweise GTM über afterInteractive — sonst greifen die Defaults nicht und der Autoblocker fängt das falsche Skript ab.

Die Google-Dokumentation ist hier unmissverständlich. In den Consent-Guidelines der Tag Platform steht, dass gtag('consent', 'default', ...) vor jedem config- oder event-Befehl gesetzt werden muss: «If your consent code is called out of order, consent defaults won't work.» Das ist der häufigste Fehler im Headless-Build — der berüchtigte «consent default out of order»: Tags lesen, bevor der Default überhaupt gesetzt ist.

Die saubere Verdrahtung im App Router folgt deshalb einer festen Ordnung:

• Default-Consent zuerst. Das Snippet mit allen vier Signalen auf denied läuft als allererstes — inline im Root-Layout über next/script mit strategy="beforeInteractive".
• CMP ebenfalls beforeInteractive. So initialisiert die Consent-Plattform, bevor ihr Autoblocker greift. Diese Reihenfolge entspricht der Cookiebot-Anleitung für den Next.js App Router, die das CMP-Script bewusst in beforeInteractive legt.
• GA4 beziehungsweise GTM über afterInteractive. Das Mess-Skript wird vom CMP-Autoblocker abgefangen und verzögert, bis ein gültiger Consent-Status vorliegt.
• wait_for_update setzen. Dieser Parameter (in Millisekunden) gibt asynchronen CMPs Zeit, den Status zu aktualisieren, bevor der erste Hit rausgeht. Er ist ebenfalls in den Consent-Guidelines dokumentiert.
• region-Parameter nutzen. Damit setzen Sie EWR- oder CH-spezifische Defaults statt einer globalen Blockade — Schweizer Nutzer können andere Defaults bekommen als Besucher ausserhalb des Geltungsbereichs.

Consent-Update-Events und Server-Side-Tagging

Nach der Nutzerentscheidung feuert die CMP ein gtag('consent', 'update', ...) mit den realen Werten. Optional verlagert Server-Side-Tagging die Tags hinter einen eigenen Endpoint: Der Consent-Status reist in den System-Properties mit, der GA4-Client im Container wertet ihn aus. Das reduziert die Zahl der Drittanbieter-Requests im Browser spürbar.

Im Headless-Build muss das Update-Event exakt dann feuern, wenn der Nutzer in der CMP interagiert. Praktisch koppeln Sie den CMP-Callback an einen Consent-State-Listener, der gtag('consent', 'update', ...) mit den tatsächlich gewählten Werten auslöst. Erst dieser Schritt schaltet von den denied-Defaults auf die echte Einwilligung um — ohne ihn bleibt jeder Nutzer dauerhaft im «denied»-Zustand, egal was er im Banner geklickt hat.

Server-Side-Tagging ist die optionale Kür darüber. Der Consent-Status liegt in den System-Properties des sGTM-Containers, sodass weniger browserseitige Drittanbieter-Skripte nötig sind. Der Vorteil ist doppelt: bessere Web Vitals durch weniger Client-Skripte und mehr Datenkontrolle. Warum weniger Browser-Skripte direkt schneller laden, vertieft der Beitrag zu Core Web Vitals und Browser-Skripten. Wichtig bleibt: Server-Side-Tagging ersetzt nicht die Einwilligung. Die Consent-Signale müssen trotzdem korrekt gesetzt und an den Container weitergereicht werden.

CMP-Wahl: zertifizierte CMP, TCF und der Unterschied Advertiser vs. Publisher

Eine TCF-zertifizierte CMP ist für Publisher-Produkte (AdSense, Ad Manager) vorgeschrieben, die Werbung an EWR-, UK- oder CH-Nutzer ausspielen. Reine Advertiser (GA4, Google Ads) brauchen primär korrekte Consent-Mode-Signale, nicht zwingend TCF. Schweizer CMPs wie Cookiebot, Usercentrics und consentmanager decken beides ab — die Headless-Verdrahtung aber nicht.

Die Unterscheidung ist entscheidend für die Frage, wie viel Sie überhaupt brauchen. Als Publisher mit AdSense oder Ad Manager ist laut der AdSense-Hilfe zur EU User Consent Policy eine zertifizierte, TCF-2.2-integrierte CMP vorgeschrieben — für EWR und UK seit Januar 2024, für die Schweiz seit Juli 2024. Als reiner Advertiser mit GA4 und Google Ads sind dagegen die korrekten Consent-Mode-v2-Signale das Entscheidende, eine TCF-Zertifizierung ist dann nicht zwingend.

Die meisten KMU-Sites fallen in die zweite Kategorie. Schweizer Anbieter mit DSG-Fokus — Cookiebot, Usercentrics, consentmanager — decken beide Welten ab. Der Haken liegt anderswo: Ihre Vendor-Dokumentation zeigt die Standard-WordPress- oder HTML-Einbindung, nicht die App-Router-Script-Order. Diese Lücke zwischen CMP-Doku und Headless-Realität ist exakt die Stelle, an der Tracking still kaputtgeht — der Banner erscheint, die Defaults greifen nicht, und niemand merkt es, bis die Conversions ausbleiben.

Wo Ihre Site heute steht — der schnelle Check

Bevor Sie an der Consent-Verdrahtung schrauben, lohnt der Blick auf den Ist-Zustand: Welche Skripte laden bereits, ist eine CMP eingebunden, und feuert das Default-Snippet vor den Tags? Der kostenlose Website-Check prüft sichtbare Indikatoren von aussen und liefert eine erste Standortbestimmung — kein Ersatz für ein GA4-Debug-View, aber ein guter Startpunkt, um den eigenen Tracking-Stack zu sortieren.

Wie die saubere Trennung von datentragendem Backend und ausliefernden Frontend technisch aussieht, beschreibt unsere Übersicht zur Headless-WordPress-Architektur. Und wenn Sie über das Tracking hinaus Lead-Attribution sauber aufsetzen wollen, ordnet der Beitrag zu Formularen und Lead-Erfassung im Headless-Frontend ein, wie Quelle und Conversion zusammenfinden, ohne dass die Consent-Logik im Weg steht.

Nächster Schritt

Consent Mode v2 im Headless-Frontend ist keine Frage des richtigen CMP-Anbieters, sondern der korrekten Lade-Reihenfolge: Default-States vor dem CMP-Load, Update-Events am richtigen Callback, optional ein Server-Side-Relay. Ob für Ihr Projekt Basic genügt oder Advanced den Aufwand rechtfertigt — und wie die Script-Order im App Router sauber aufgesetzt wird — lässt sich in einem kurzen Gespräch konkret einordnen. Wenn Sie Ihr Tracking-Setup oder eine datenschutzfreundliche Headless-Architektur planen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos.

Welche Leistungen wir dabei abdecken, finden Sie unter unseren Leistungen für Headless-Projekte. Wer zuerst die Tool-Frage klären will, findet die Einordnung im Beitrag zu DSG-konformem Tracking mit Plausible oder Google Analytics — dort geht es um die Wahl davor, hier ging es um die Umsetzung danach.