Benutzerdefinierte HTML-Werbe-Tags in GTM verfügen über keine integrierte Einwilligungserkennung. Um ein Pixel, ein Remarketing-Skript oder einen Besucher-Tracker erst dann auszulösen, wenn ein Nutzer in CookieYes Werbe-Cookies akzeptiert hat, benötigst du eine triggerbasierte Konfiguration, die auf Ereignisse zur ausdrücklichen Einwilligung reagiert – und nicht die Standardkombination „Alle Seiten + Einmal pro Seite“, die nach einem blockierten Auslöseversuch stillschweigend fehlschlägt.
Table of Contents
Das Wichtigste in Kürze
- CookieYes speichert die Einwilligungsentscheidungen der Nutzer in dem
cookieyes-consentCookie; GTM liest diese über eine First-Party-Cookie-Variable aus - Der richtige Trigger ist ein benutzerdefiniertes Ereignis auf
cookie_consent_updatemit einer Bedingung, die prüft, obadvertisement:yesim Cookie-Wert vorkommt - Wenn man „Alle Seiten“ mit „Einmal pro Seite“ kombiniert, zählt GTM einen blockierten Versuch, die Seite zu laden, als Auslösezeitpunkt; das Tag wird nie ausgelöst, nachdem der Nutzer auf „Akzeptieren“ geklickt hat
- Erforderlich
ad_storage,ad_user_dataund „ad“personalizationin den erweiterten Einwilligungseinstellungen des Tags als zweite Überprüfungsstufe - Dieser Ansatz gilt nur für benutzerdefinierte HTML-Tags; native Google Ads- und GA4-Tags haben ihr eigenes Verhalten im Einwilligungsmodus
Warum benutzerdefinierte HTML-Tags den Einwilligungsmodus von sich aus nicht berücksichtigen
Benutzerdefinierte HTML-Tags in GTM erkennen keine Signale des Google-Einwilligungsmodus. Wenn du ein Meta-Pixel-Snippet, ein LinkedIn Insight Tag oder ein beliebiges Remarketing-Skript eines Drittanbieters in ein benutzerdefiniertes HTML-Tag einfügst, wird dieses Tag immer dann ausgelöst, wenn sein Trigger ausgelöst wird. Es hat keine Kenntnis von adstorage aduser_data – diese Signale wirken sich automatisch nur auf native Google-Tags (Google Ads-Conversions, GA4) aus.
Laut der Dokumentation zum „Consent Mode“ von Google werden Einwilligungssignale wie ad_storage und ad_user_data steuern standardmäßig nur das Verhalten von Googles eigenen Tags. Skripte von Drittanbietern, die in benutzerdefinierte HTML-Tags eingefügt werden, liegen außerhalb dieser Kontrollebene; sie werden unabhängig vom Zustimmungsstatus ausgeführt, es sei denn, der Auslöser selbst verhindert dies.
Das ist ein wichtiger Unterschied für jede Website, die unter der DSGVO, dem CCPA oder ähnlichen Rahmenwerken betrieben wird. Skripte von Drittanbietern, die als benutzerdefiniertes HTML hinzugefügt werden, können bereits bei ihrer Ausführung Werbe-Cookies setzen. Daher stellt das Auslösen des Triggers vor Erteilung der Einwilligung ein Compliance-Risiko dar und ist nicht nur ein Problem der Tracking-Genauigkeit.
Der Fehler „Einmal pro Seite“
Wenn du „Alle Seiten“ als Trigger hinzufügst und die Auslöseoptionen auf „Einmal pro Seite“ einstellst, wertet GTM das Tag bei jedem Seitenladevorgang aus. Wenn CookieYes seine Einwilligungsinitialisierung auslöst, bevor der Nutzer zugestimmt hat, versucht GTM möglicherweise, das Tag zu diesem Zeitpunkt auszulösen. Die Einwilligungsprüfungen verhindern zwar, dass es tatsächlich ausgeführt wird, aber GTM registriert die Auswertung dennoch als die einzige zulässige Auslösung für diese Seitensitzung.
Das Ergebnis: Der Nutzer öffnet das Banner, klickt auf „Alle akzeptieren“, CookieYes übermittelt eine Aktualisierung der Einwilligung an den dataLayer, und es passiert nichts. Das Werbeskript bleibt während der gesamten Sitzung inaktiv, da GTM den Slot „Einmal pro Seite“ bereits beim blockierten Versuch, die Seite zu laden, genutzt hat.
Das ist kein Fehler, der bei Tests regelmäßig auftritt. Im GTM-Vorschau-Modus kann das Verhalten korrekt erscheinen, wenn du die Vorschau mit bereits gelöschten Cookies lädst und die Einwilligung akzeptierst, bevor irgendwelche Tags ausgelöst werden. Der Fehler tritt in der Produktionsumgebung auf, wenn das CookieYes-Banner geladen und initialisiert wird, bevor andere GTM-Container die Gelegenheit hatten, die Ereigniswarteschlange zu verarbeiten.
Warum das Problem allein durch die Verwendung eines benutzerdefinierten Triggers gelöst wird
Wenn der einzige Auslöser des Tags das cookie_consent_update benutzerdefinierte Ereignis ist, wertet GTM das Tag beim Laden der Seite überhaupt nicht aus. Kein blockierter Versuch, kein verschwendeter Auslöseslot. Das Tag wird erst dann für die Auslösung berücksichtigt, wenn das benutzerdefinierte Ereignis ausgelöst wird – was passiert, wenn CookieYes eine Änderung des Einwilligungsstatus an den dataLayer übermittelt. Wenn zu diesem Zeitpunkt sowohl die Cookie-Bedingung als auch die Einwilligungsprüfungen erfolgreich sind, wird das Tag einwandfrei ausgeführt.
Schritt 1: CookieYes für den Google-Einwilligungsmodus v2 konfigurieren
„CookieYes“ muss so eingerichtet werden, dass es sowohl die Standardeinstellungen des Google-Einwilligungsmodus initialisiert, bevor andere Tags ausgelöst werden, als auch dataLayer-Ereignisse sendet, wenn sich der Einwilligungsstatus des Nutzers ändert.
Aktiviere im CookieYes-Dashboard die Unterstützung für den Google Consent Mode v2. Durch diese Einstellung fügt CookieYes den gtag('consent', 'default', {...}) Call einfügt, bevor der GTM-Container geladen wird, und legt dabei Standardwerte für alle Einwilligungssignale fest.
Lege den Standardstatus für die Einwilligung bei Werbesignalen auf „abgelehnt“ fest:
ad_storage: deniedad_user_data: deniedad_personalization: denied
Wenn ein Nutzer die Kategorie „Werbung“ akzeptiert, ruft CookieYes gtag('consent', 'update', {...}) und setzt alle drei auf granted. Außerdem wird das cookie_consent_update Ereignis an den dataLayer – das ist das Ereignis, auf das dein GTM-Trigger warten wird.
CookieYes-CMP-Tag-Trigger in GTM
In GTM muss das CookieYes-CMP-Tag beim Auslöser „Consent Initialization – All Pages“ ausgelöst werden, nicht beim Standard-Auslöser „All Pages“. Dieser Unterschied ist wichtig: „Consent Initialization“ wird vor allen anderen Auslösertypen ausgelöst und stellt so sicher, dass CookieYes die Standardeinstellungen festlegt, bevor beim Laden der Seite andere Tags ausgeführt werden können. Wenn du den Standard-Trigger „Alle Seiten“ für das CookieYes-Tag verwendest, könnten die Standardwerte für die Einwilligung zu spät eintreffen, und andere Tags könnten ausgelöst werden, bevor die GCM-Signale gesetzt sind.
Das „cookieyes-consent“-Cookie
CookieYes speichert die vollständige Einwilligungsentscheidung des Nutzers in einem First-Party-Cookie namens cookieyes-consent. Ein typischer akzeptierter Wert sieht so aus:
consent:yes,analytics:yes,functional:yes,advertisement:yesEin abgelehnter oder teilweise akzeptierter Status könnte etwa so aussehen:
consent:yes,analytics:no,functional:yes,advertisement:noGTM liest diese Cookie-Zeichenkette aus, um zu prüfen, ob die Werbebedingung erfüllt ist.
Schritt 2: Erstelle die GTM-Variable
Erstelle in GTM eine neue Variable, um den cookieyes-consent Cookie-Wert auszulesen. Diese Variable wird in der Triggerbedingung verwendet.
| Schauplatz | Wert |
|---|---|
| Variablentyp | Erstanbieter-Cookie |
| Variablenname | CookieYes-Einwilligung |
| Cookie-Name | cookieyes-consent |
| Cookie URI-dekodieren | Nein |
Die Variable gibt die vollständige Cookie-Zeichenkette als Klartextwert zurück. Es ist keine JavaScript-Verarbeitung erforderlich, da die Auslösebedingung den Abgleich von Teilzeichenfolgen übernimmt.
Schritt 3: Erstelle den benutzerdefinierten Ereignis-Trigger
Dieser Trigger überwacht das Ereignis, das CookieYes bei jeder Änderung des Einwilligungsstatus an den dataLayer übermittelt: beim ersten Laden der Einwilligung, bei „Akzeptieren“, bei „Ablehnen“ oder bei einer Aktualisierung der detaillierten Kategorien.
| Schauplatz | Wert |
|---|---|
| Triggertyp | Benutzerdefiniertes Ereignis |
| Trigger-Name | CookieYes: Werbung zugelassen |
| Name der Veranstaltung | cookie_consent_update |
| Feuer an | Einige benutzerdefinierte Ereignisse |
| Zustandsvariable | {{CookieYes Consent}} |
| Bedingungsoperator | enthält |
| Zustandswert | Werbung: ja |
Der Wert der Bedingung lautet genau advertisement:yes. Füge das Wort „enthält“ nicht in das Wertfeld ein – das ist der aus der Dropdown-Liste ausgewählte Operator und kein Teil der Zeichenfolge.
Dieser Trigger wird bei jeder Änderung des Zustimmungsstatus ausgelöst, bei der der resultierende Cookie-Wert Folgendes enthält advertisement:yes. Lehnt der Nutzer Werbe-Cookies ab, enthält das Cookie advertisement:no, die Bedingung wird nicht erfüllt und der Trigger wird nicht ausgelöst.
Du bist dir nicht sicher, was dein GTM-Container eigentlich macht?
Der „Once per page“-Fehler ist einer von Dutzenden versteckten Fehlern, die wir in GTM-Setups finden: Tags, die vor der Einwilligung ausgelöst werden, Pixel, die schon seit Monaten nicht mehr funktionieren, und Einwilligungssignale, die nie bei den Tags ankommen, die sie eigentlich steuern sollten. Jeder einzelne davon stellt entweder ein Compliance-Risiko dar oder führt zum Verlust von Conversion-Daten.
Unser WordPress-Website-Audit umfasst eine umfassende Überprüfung deines GTM-Containers, des Einwilligungsablaufs und des Auslöseverhaltens jedes einzelnen Tags – inklusive einer nach Priorität geordneten Liste mit Korrekturmaßnahmen, die du noch in derselben Woche umsetzen kannst.
Schritt 4: Konfiguriere das Werbe-Tag
Sobald die Variable und der Trigger eingerichtet sind, erstelle oder aktualisiere dein Werbe-Tag.
Tag-Typ und Auslöseeinstellungen
Stell den Tag-Typ auf „Benutzerdefiniertes HTML“ ein und füge dein Werbeskript in den Body ein. Stell unter „Erweiterte Einstellungen“ die Option „Tag-Auslösung“ auf „Einmal pro Seite“ ein.
Weise dem Trigger ausschließlich den Trigger „CookieYes: Werbung genehmigt“ zu. Füge daneben weder „Alle Seiten“ noch irgendeinen anderen Seitenaufruf-Trigger hinzu. Die Option „Einmal pro Seite“ ist hier unbedenklich, da der Trigger selbst erst nach der bestätigten Einwilligung ausgelöst wird und es keine Auswertung beim Laden der Seite gibt, die den Auslöseplatz vorzeitig belegen könnte.
Erweiterte Einwilligungseinstellungen
Öffne in der Tag-Konfiguration die Einwilligungseinstellungen und wähle „Zusätzliche Einwilligung für die Auslösung des Tags erforderlich“ aus. Füge die folgenden Einwilligungsarten hinzu:
ad_storagead_user_dataad_personalization
Dadurch entsteht eine zweite Verifizierungsstufe. Selbst wenn der Trigger ausgelöst wird (Cookie-Bedingung erfüllt), wird das Tag nur ausgeführt, wenn alle drei Einwilligungssignale im Google-Einwilligungsmodus auf granted. Falls im Browser des Nutzers eine bestehende Sitzung vorliegt, in der die Signale noch denied, oder wenn „CookieYes“ das Cookie aktualisiert, die GCM-Signale aber noch nicht nachziehen, verhindert diese Überprüfung eine vorzeitige Ausführung.
Warum beide Ebenen notwendig sind
Die Auslösebedingung liest das „CookieYes“-Cookie aus (ein vom CMP gesteuerter String-Wert). Die Einwilligungsprüfungen lesen die Signale des Google Consent Mode, einen vom GCM-API gesteuerten dataLayer-Zustand. Beide müssen anzeigen, dass der Nutzer Werbung akzeptiert hat. In den meisten Implementierungen werden sie gleichzeitig aktualisiert, aber wenn man sich nur auf eine der beiden stützt, entsteht ein Zeitfenster, in dem die andere möglicherweise noch nicht weitergegeben wurde.
Wenn ein Nutzer Werbe-Cookies akzeptiert und diese später in derselben Sitzung ausdrücklich widerruft, fallen die GCM-Signale auf denied. Selbst wenn der Slot „Einmal pro Seite“ noch nicht genutzt wurde, wird das Tag nicht ausgelöst, da die Einwilligungsprüfung fehlschlägt.
Schritt 5: In der GTM-Vorschau testen
Beim Testen müssen zwei Abläufe überprüft werden: der „Accept“-Ablauf und der „Reject“-Ablauf.
| Schritt | Aktion | Erwartetes Ergebnis |
|---|---|---|
| 1 | Website-Cookies löschen, GTM-Vorschau öffnen | Beim Laden der Seite wird kein Werbe-Tag in den Tags ausgelöst |
| 2 | Lade die Seite so, dass das Einwilligungsbanner sichtbar ist | cookie_consent_update Feuer; Tag nicht in „Tags Fired“ |
| 3 | Klick auf „Alle ablehnen“ | cookie_consent_update Feuer; Tag fehlt in „Tags Fired“ |
| 4 | Seite neu laden; klick auf „Alle akzeptieren“ | cookie_consent_update Feuer; die Veranstaltung starten |
| 5 | Überprüfe die Registerkarte „Einwilligung“ in der GTM-Vorschau | ad_storage, ad_userdata, ad_personalization anzeigen granted |
| 6 | Überprüfe die Tags, die bei diesem Ereignis ausgelöst wurden | Hier erscheint das Werbe-Tag |
| 7 | Schau dir den Reiter „Netzwerk“ im Browser an | Pixel- oder Skript-Anfrage sichtbar |
| 8 | Wiederhole den vollständigen Durchlauf, aber nur mit „Alle ablehnen“ | Auf der Registerkarte „Netzwerk“ fehlt durchgehend das Tag |
In Googles offiziellem Leitfaden zur Überprüfung des Einwilligungsmodus wird erklärt, wie du die Registerkarte „Einwilligung“ in der GTM-Vorschau nutzt, um zu überprüfen, ob adstorage, aduserdataund adpersonalization auf granted nach der Benutzerinteraktion aktualisiert.
Schritt 8 wird bei den meisten Implementierungen übersprungen. Dass das Tag in Schritt 6 nicht ausgelöst wird, ist notwendig; dass das Tag bei einer Ablehnung nicht unter „Netzwerk“ erscheint, ist die Compliance-Anforderung. Beides muss erfüllt sein.
Wichtig: Das gilt nicht für native Google-Tags
Die oben beschriebene Konfiguration ist für benutzerdefinierte HTML-Tags gedacht, die Werbeskripte von Drittanbietern enthalten, die den Consent-Modus nicht nativ unterstützen.
Native Google Ads- und GA4-Tags verhalten sich unterschiedlich. Im erweiterten Einwilligungsmodus dürfen native Google-Tags bereits vor der Einwilligung ausgelöst werden; sie erfassen cookielose, modellierte Daten und senden begrenzte Pings, ohne Werbe-Cookies zu setzen. Dies ist ein beabsichtigtes Verhalten, das die Konversionsmodellierung unterstützt und dabei hilft, verlorene Attributionsdaten wiederherzustellen.
Die Anwendung des cookie_consent_update Triggers auf native Google Ads- oder GA4-Tags würde deren Datenerfassung vor der Einwilligung vollständig unterbinden und sie in den „Basic Consent Mode“ versetzen. Ob das akzeptabel ist, hängt von deiner Messstrategie ab, aber es ist ein anderer Kompromiss als die bloße Sicherstellung, dass ein Drittanbieter-Pixel zum richtigen Zeitpunkt ausgelöst wird.
Wenn deine Website sowohl native Google-Tags als auch benutzerdefinierte HTML-Skripte von Drittanbietern enthält, konfiguriere diese separat. Native Tags können Standard-Trigger für Seitenaufrufe verwenden, wobei die Einwilligungsprüfungen automatisch von GCM übernommen werden. Für benutzerdefinierte HTML-Tags gilt die hier beschriebene Trigger-Einrichtung.
FAQ
Funktioniert diese Konfiguration mit jedem Werbe-Pixel?
Ja. Die Konfiguration ist plattformunabhängig. Sie funktioniert für Meta Pixel, LinkedIn Insight Tag, Pinterest Tag, TikTok Pixel oder jedes andere proprietäre Remarketing-Skript, das als benutzerdefiniertes HTML hinzugefügt wurde. Die Trigger- und Einwilligungsprüfungen laufen vollständig auf der GTM-Ebene ab; der konkrete Inhalt des Skripts spielt keine Rolle.
Was ist, wenn das Ereignis „cookie_consent_update“ in der GTM-Vorschau gar nicht auftaucht?
Überprüfe zwei Dinge. Erstens: Vergewissere dich, dass das CookieYes-CMP-Tag in GTM so eingestellt ist, dass es bei der „Einwilligungsinitialisierung – Alle Seiten“ ausgelöst wird, und nicht bei einem Standard-Seitenaufruf-Trigger. Zweitens: Überprüfe im CookieYes-Dashboard, ob der Google Consent Mode aktiviert ist. Wenn das Ereignis im Vorschau-Ereignisstrom komplett fehlt, ist das CookieYes-Tag entweder nicht im Container vorhanden, wird durch den falschen Trigger ausgelöst oder die GCM-Integration ist in den CookieYes-Einstellungen deaktiviert.
Soll ich das auf Google Ads und GA4-Tags anwenden?
Nein. Native Google Ads- und GA4-Tags verfügen über eine integrierte Verarbeitung des Einwilligungsmodus. Würde man sie auf den cookie_consent_update Trigger würde ihre cookielosen Pings vor der Einwilligung deaktivieren, was in der Regel nicht das beabsichtigte Ergebnis ist. Konfiguriere native Google-Tags mit Standard-Seitenansicht-Triggern und lass GCM ihr Einwilligungsverhalten verwalten.
Was ist der Unterschied zwischen dem einfachen und dem erweiterten Einwilligungsmodus?
Im „Basic Consent Mode“ werden Tags erst ausgelöst, wenn der Nutzer seine Einwilligung erteilt hat; vor der Interaktion mit dem Banner finden keine Datenerfassungen statt. Im „Advanced Consent Mode“ werden native Google-Tags zwar bereits vor der Einwilligung ausgelöst, erfassen jedoch nur anonymisierte, cookielose Daten; erst nach Erteilung der Einwilligung wird auf vollständiges Tracking umgeschaltet. Benutzerdefinierte HTML-Tags arbeiten unabhängig von deiner GCM-Konfiguration immer im Basis-Modus: Sie werden nur ausgelöst, wenn ein Trigger sie aktiviert, und der Trigger in dieser Anleitung wird erst nach Erteilung der Einwilligung ausgelöst.
Warum regelt gerade die Kategorie „Werbung“ diese Einwilligungssignale?
CookieYes ordnet seine Cookie-Kategorien den GCM-Einwilligungsarten zu. Die Kategorie „Werbung“ entspricht ad_storage, ad_user_dataund ad_personalization. Wenn ein Nutzer „Werbung“ akzeptiert, aktualisiert CookieYes alle drei Signale auf granted. Die Kategorien „Funktional“, „Analytik“ und andere werden verschiedenen Signalen zugeordnet (functionality_storage, analytics_storage) und haben keinen Einfluss auf das Auslösen von Werbe-Tags.
Zusammenfassung
Um benutzerdefinierte HTML-Skripte nach der Einwilligung bei CookieYes zuverlässig zu laden, müssen drei Komponenten zusammenwirken: ein CookieYes-CMP-Tag, das bei der Einwilligungsinitialisierung ausgelöst wird, ein Trigger für benutzerdefinierte Ereignisse, der das cookieyes-consent Cookie für advertisement:yes, sowie explizite Einwilligungsanforderungen für ad_storage, ad_user_datasowie ad_personalization auf dem Tag selbst.
Der häufigste Fehler ist die Kombination von „Alle Seiten“ mit „Einmal pro Seite“ – dadurch erhält GTM bereits beim gesperrten Versuch, die Seite zu laden, einen Auslösezeitpunkt, sodass nichts mehr übrig bleibt, wenn der Nutzer tatsächlich seine Einwilligung erteilt. Erst wenn man „Alle Seiten“ komplett aus dem Trigger entfernt, wird die Konfiguration zuverlässig.
Wenn du WordPress-Seiten mit komplexen Tag-Konfigurationen, Compliance-Anforderungen oder leistungskritischen GTM-Einstellungen verwaltest, kümmert sich unser WordPress-Support- und Wartungsteam im Rahmen der laufenden Seitenverwaltung um diese Integrationen. Ein WordPress-Website-Audit kann zudem versteckte Lücken bei der Einwilligungsabfrage oder beim Tracking in deinem gesamten GTM-Container aufdecken. Sprich mit den IMADO-Entwicklern darüber, was deine Seite braucht.
