Google Consent Mode v2 mit FlowConsent

FlowConsent implementiert Google Consent Mode v2 von Haus aus: Ein Inline-Stub registriert denied-Standardwerte für alle vier Einwilligungssignale, bevor irgendein Google-Tag lädt, das Banner sendet gtag('consent', 'update', …), sobald der Besucher wählt, und Googles cookielose Pings (gcs=G100) erhalten die Conversion-Modellierung, ohne eine Ablehnung zu verletzen. Kein zusätzliches Template, kein Drittanbieter-Plugin.

Der Stub: denied als Standard, vor jedem Tag

Ihr Integrations-Snippet beginnt mit diesem Inline-Script — es wird in Builder → Deployment → Integration für Sie generiert:

<script>
window.dataLayer=window.dataLayer||[];
function gtag(){dataLayer.push(arguments);}
gtag('consent','default',{
  'ad_storage':'denied',
  'analytics_storage':'denied',
  'ad_user_data':'denied',
  'ad_personalization':'denied',
  'wait_for_update':500
});
gtag('set','url_passthrough',true);
gtag('set','ads_data_redaction',true);
</script>

Alle vier v2-Signale — ad_storage, analytics_storage, ad_user_data, ad_personalization — starten mit denied. Das Banner-Bundle registriert dieselben Standardwerte, lädt aber asynchron: Ein von einem anderen Kanal hinzugefügtes Google-Tag (Site-Builder-Einstellungen, ein Plugin) könnte es überholen. Der Stub wird beim HTML-Parsing ausgeführt, die Standardwerte stehen also vor jedem Tag fest, egal wer es lädt. Deshalb muss der Stub in Ihrem Snippet vor dem Loader bleiben.

wait_for_update

wait_for_update: 500 weist Google-Tags an, ihre ersten Hits bis zu 500 ms zurückzuhalten — genug Zeit für das Banner, die gespeicherte Wahl eines früheren Besuchs nachzureichen. Ein wiederkehrender Besucher, der bereits zugestimmt hat, erhält volle Messung, ohne dass erste Hits als abgelehnt abgehen. Die Verzögerung ist in den Consent-Mode-Einstellungen Ihres Banners konfigurierbar.

url_passthrough und ads_data_redaction

Beide sind standardmäßig aktiv und lassen sich in der Banner-Konfiguration abschalten:

• url_passthrough — reicht Anzeigenklick-Informationen (gclid, dclid…) über URL-Parameter weiter, solange die Einwilligung verweigert ist, damit eine spätere Einwilligung die Attribution nicht verliert.
• ads_data_redaction — ist ad_storage verweigert, schwärzt Google zusätzlich Anzeigenklick-Kennungen in seinen cookielosen Pings.

So sieht eine Ablehnung aus: gcs=G100

Lehnt der Besucher ab, bleiben die Tags im cookielosen Modus: Es werden keine Cookies geschrieben, und Google erhält anonyme Pings mit gcs=G100 (Signal „Einwilligung verweigert"). Diese Pings sind konform mit der Ablehnung — der Compliance-Scan von FlowConsent erkennt sie, weist sie separat aus und zählt sie nie als Verstöße. Eine Website, die Consent Mode korrekt einsetzt, wird dafür nie bestraft.

Das Rennen, das FlowConsent nicht gewinnen kann — aber erkennt

Consent-Mode-Standardwerte schützen nur Tags, die nach ihnen in den dataLayer gelangen. Wird ein gtag('config', 'G-XXXX') vor den Einwilligungs-Standardwerten eingereiht — typischerweise die native Analytics-Integration eines Site-Builders, injiziert oberhalb Ihres Custom Code, wie es Webflows Einstellungen tun — verarbeitet Google es uneingeschränkt und setzt seine Cookies, was auch immer eine CMP danach tut.

Das Banner prüft genau diesen Fall beim Start und erneut nach dem Laden der Seite: Steht ein config vor dem consent default im dataLayer, protokolliert es einen Konsolenfehler mit den Tag-IDs und meldet ein ConsentDefaultRaceLost-Ereignis an die FlowConsent-Telemetrie. Die Lösung ist immer dieselbe: das Tag aus dem Kanal entfernen, der es zu früh injiziert, und den Dienst in Builder → Services deklarieren, damit das Banner ihn verwaltet.