Wie löse ich GTM-Tags beim Consent-Update-Event aus?

Alle Beiträge

cookie_consent_update ist ein Data-Layer-Event, das eine Consent-Plattform sendet, sobald die Wahl des Besuchers wirksam wird, damit Tag Manager zurückgehaltene Tags ausführen kann. Um Tags darauf auszulösen, legen Sie einen Custom-Event-Trigger mit diesem Event-Namen an, ergänzen die Bedingung, dass die vom Tag benötigte Kategorie erteilt ist (gelesen aus einer Data-Layer-Variable oder dem Cookie der Plattform), und verwenden ihn statt All Pages.

Der Trigger selbst ist schnell gebaut. Die Probleme kommen meist danach: ein doppelt gezählter Page View oder ein Tag, das auslöst, obwohl der Besucher abgelehnt hat. Hier steht, wofür das Event da ist, wie Sie es anbinden und wie Ihre Zahlen verlässlich bleiben.

Was ist das Event cookie_consent_update?

Es ist ein benutzerdefiniertes Event, dieselbe Art, die Ihre eigene Website mit dataLayer.push({event: '…'}) sendet. Google definiert es nicht. Die Consent-Plattform wählt den Namen, und mehrere Plattformen verwenden cookie_consent_update in ihren Anleitungen für Tag Manager; mindestens eine schreibt, dass sie diesen Namen sendet, damit Container, die für eine andere Plattform eingerichtet wurden, weiter funktionieren. Velo sendet velo_consent_update und daneben die Entscheidung in einem Objekt velo_categories mit analytics, ads, functional und personalization, jeweils true oder false.

Es ist nicht dasselbe wie Googles Consent-Update-Befehl. Dieser Befehl ändert den Einwilligungsstatus, den Google-Tags und die Einwilligungsprüfungen von Tag Manager lesen. Das benutzerdefinierte Event ist das Signal für Ihre Trigger: etwas, auf das ein Trigger vom Typ Custom Event reagieren kann. Eine gute Consent-Plattform sendet beides, in dieser Reihenfolge, damit der Status schon aktualisiert ist, wenn Ihr Tag geprüft wird.

Warum brauchen Tags nach der Einwilligung einen zweiten Trigger?

Weil Tag Manager die Einwilligung nur einmal prüft, und zwar in dem Moment, in dem der Trigger des Tags auslöst. Googles Hilfe zu den Einwilligungseinstellungen sagt, dass ein Tag mit zusätzlichen Einwilligungsanforderungen nur auslöst, wenn alle aufgeführten Einwilligungstypen zum Zeitpunkt des Auslösens erteilt sind. Beim ersten Besuch löst der Trigger All Pages aus, bevor der Besucher etwas gewählt hat. Ein Tag, das analytics_storage verlangt, wird also zurückgehalten. Stimmt der Besucher ein paar Sekunden später zu, holt nichts im Container das Tag nach. Das Tag braucht einen Trigger, der nach der Wahl auslöst, und das ist das Consent-Update-Event.

Das gilt für Tags ohne eigene Einwilligungslogik: ein Meta- oder Hotjar-Tag mit der Einstellung Require additional consent oder Google-Tags im einfachen Consent Mode, die erst laden sollen, wenn der Besucher zustimmt. Googles eigene Tags lesen im erweiterten Modus den Einwilligungsstatus selbst und bleiben deshalb an ihren üblichen Triggern. Unser Beitrag dazu, ob Sie Google-Tags bis zur Einwilligung blockieren sollten, erklärt diese Unterscheidung.

Wie löse ich ein GTM-Tag beim Consent-Update-Event aus?

1. Finden Sie den Event-Namen Ihrer Plattform

   Öffnen Sie Preview von Tag Manager auf Ihrer Website, stimmen Sie im Banner zu und lesen Sie die Event-Liste links. Übernehmen Sie den Namen genau so, wie er dort steht. Bei Velo ist es velo_consent_update.

2. Eine Variable für die Kategorie anlegen

   Legen Sie eine Data-Layer-Variable an, die die Kategorie liest, von der das Tag abhängt. Bei Velo ist das velo_categories.analytics für Analyse-Tags und velo_categories.ads für Werbe-Tags. Andere Plattformen speichern den Status woanders, manchmal in einem First-Party-Cookie. Prüfen Sie also, wo Ihre ihn ablegt.

3. Den Trigger mit einer Bedingung anlegen

   Legen Sie einen Custom-Event-Trigger auf den Event-Namen an und lassen Sie ihn bei einigen benutzerdefinierten Events auslösen, wenn die Variable gleich true ist. Ohne die Bedingung löst der Trigger auch aus, wenn der Besucher ablehnt, und ein Tag ohne eigene Einwilligungseinstellungen feuert dann trotzdem.

4. Statt All Pages einsetzen

   Entfernen Sie am Tag den Trigger All Pages und fügen Sie den neuen hinzu. Behalten Sie beide, löst das Tag bei wiederkehrenden Besuchern zweimal aus, weil das Update-Event auch bei deren Seitenaufrufen auslöst.

5. Page-View-Tags auf einmal pro Seite stellen

   Wählen Sie unter Advanced Settings und dann Tag firing options die Option Once per page. Ein Besucher, der das Banner erneut öffnet und eine neue Wahl speichert, sendet das Event auf derselben Seite ein zweites Mal.

6. Lassen Sie Conversion-Tags an ihren eigenen Triggern

   Ein Kauf- oder Lead-Tag sollte beim Kauf oder beim Formular auslösen, nie beim Consent-Event. Dort würde es bei jeder Wahl eines Besuchers eine Conversion zählen.

7. Erst in Preview testen, dann auf der Live-Website

   Führen Sie die vier Prüfungen unten jedes Mal in einer neuen Browsersitzung durch und veröffentlichen Sie dann den Container.

Warum löst mein Tag nach der Einwilligung zweimal aus?

Drei Einrichtungen lassen ein Tag doppelt zählen:

• Zwei Trigger an einem Tag. Ein wiederkehrender Besucher hat bereits eine gespeicherte Wahl, also kann das Tag seine Einwilligungsprüfung bei All Pages bestehen und kurz darauf beim Update-Event noch einmal auslösen. Aus einem Page View werden zwei.
• Eine geänderte Wahl auf derselben Seite. Jede gespeicherte Wahl sendet das Event erneut. Once per page verhindert den zweiten Page View.
• Ein Conversion-Tag am Consent-Trigger. Jede Zustimmung sieht aus wie ein Lead. Hängen Sie das Conversion-Tag wieder an das Event, das die Conversion definiert.

Wenn die Zahlen in der Woche gestiegen sind, in der Sie eine Consent-Plattform installiert haben, prüfen Sie diese Punkte, bevor Sie der Plattform oder den Besuchern die Schuld geben.

Wann sendet Velo velo_consent_update?

Jedes Mal, wenn auf einer Seite eine Einwilligungsentscheidung wirksam wird, nicht nur bei einem Klick:

• wenn ein Besucher im Banner zustimmt, ablehnt oder seine Auswahl speichert;
• bei jedem Seitenaufruf eines wiederkehrenden Besuchers, wenn die gespeicherte Wahl erneut angewendet wird;
• wenn ein Besucher aus einer Region mit Opt-out-Regeln ein Global-Privacy-Control-Signal sendet, das Velo als Ablehnung speichert;
• wenn ein neuer Besucher aus einer Region mit Opt-out-Regeln kommt und Velo den Standard „alles erlaubt“ anwendet, den das Banner ihn weiterhin ablehnen lässt.

Deshalb kann der Trigger All Pages ersetzen: Hat ein Besucher eine Kategorie erlaubt, lösen die Tags dieser Kategorie auf jeder Seite aus, die er aufruft. Unsere Hilfeseite zum einfachen und erweiterten Consent Mode enthält dieselbe Einrichtung als kurze Checkliste, und ein Cookie-Banner mit Google Tag Manager installieren behandelt den Teil mit Consent Initialization, der zuerst kommt.

Wie prüfe ich, ob der Trigger funktioniert?

• Erstbesuch, vor der Wahl: Das Tag erscheint als nicht ausgelöst, und das Network-Panel zeigt keine Anfrage von ihm.
• Nach der Zustimmung: Das Tag löst einmal aus, beim Update-Event.
• Nach dem Neuladen: Das Tag löst einmal pro Seite aus, weiterhin beim Update-Event, nie ein zweites Mal bei Container Loaded.
• Nach einer Ablehnung: Rufen Sie in einer neuen Sitzung zwei Seiten auf. Das Tag löst nie aus.

Preview zeigt, was Tag Manager entschieden hat. Das Network-Panel zeigt, was den Browser tatsächlich verlassen hat, also prüfen Sie beides. Unser Ablauf, um ein Cookie-Banner vor dem Livegang zu testen, enthält die vollständige Checkliste für den Browser.

Velo sendet velo_consent_update in jedem dieser Fälle. Ein einziger Trigger pro Kategorie deckt also Erstbesuche, wiederkehrende Besucher und geänderte Entscheidungen ab.