Wird ein Skript Consent-gesteuert, wenn ich es in Google Tag Manager verschiebe?

Alle Beiträge

Ja, für die meisten Anbieter-Skripte, und Google Tag Manager gibt Ihnen eine echte Sperre: Das Tag läuft nur, wenn sein Trigger feuert und seine Einwilligungseinstellungen es zulassen. Ausgenommen ist jedes Skript, das vor dem Rendern handeln oder die allererste Anfrage sehen muss, denn ein Container kann es nicht früh genug auslösen.

Was ändert sich, wenn ein Skript in Google Tag Manager wandert?

Ein fest im Head eingebautes Skript läuft in dem Moment, in dem der Parser es erreicht. Davor steht keine Sperre. Deshalb ist ein Anbieter-Snippet im Head der häufigste Grund, warum eine Website Cookies setzt, bevor der Besucher irgendetwas zugestimmt hat.

Verschieben Sie es in einen Container, ist es kein Markup mehr, sondern ein Tag. Es läuft dann, wenn ein Trigger es auslöst und seine Einwilligungseinstellungen es zulassen. Genau das wollten Sie. Und genau diesen Teil unterschätzen viele: Sie haben nicht nur eine Sperre eingebaut, Sie haben auch geändert, wann das Skript läuft. Für die meisten Anbieter ist das harmlos. Für einige ist es das ganze Problem.

Welche Skripte können nicht in den Container?

Drei Arten von Skripten scheitern am Umzug, und zwar aus demselben Grund. Ein Container lädt und wertet aus, nachdem die Seite schon begonnen hat, und diese Skripte müssen vorher handeln.

• Alles, was vor dem Rendern laufen muss. Skripte für Personalisierung und A/B-Tests schreiben die Seite um, bevor der Besucher sie sieht. Hinter einem Trigger kommen sie erst nach dem ersten Rendern an. Der Besucher sieht also den ursprünglichen Inhalt erscheinen und sich dann ändern. Genau dieses Flackern sollte das Skript verhindern. Das Verschieben sperrt es also nicht, es macht es kaputt.
• Alles, was die erste Anfrage sehen muss. Manche Tools gegen Bots und Betrug sind darauf ausgelegt, den frühesten Moment eines Besuchs zu beobachten. Aus einem Container ausgelöst, sehen sie eine Seite, die schon eine Weile offen ist, und ihr Ergebnis ändert sich entsprechend.
• Die Consent-Ebene selbst. Was die Einwilligung einholt, lässt sich nicht hinter die Einwilligung sperren. Das Banner muss laufen können, bevor es eine Entscheidung gibt. Deshalb gehört es in den Head, und deshalb ist es eines der wenigen Skripte, die wirklich unbedingt erforderlich sind.

Lässt sich ein Skript nicht verschieben, ist die ehrliche Antwort: Lassen Sie es, wo es ist, und sperren Sie es dort. Ihr Consent-Tool blockiert es in der Seite nach Kategorie, statt dass ein Container es zurückhält. Gleiches Ergebnis, anderer Mechanismus. Die Frage nach der Kategorie behandeln wir in In welche Einwilligungskategorie ein Skript gehört.

Wie verschieben Sie ein Skript, ohne eine Kopie zurückzulassen?

1. Zuerst aus dem Head entfernen

   Nicht zuletzt. Ein Skript, das an beiden Stellen existiert, läuft zweimal, und die Kopie im Head läuft ungesperrt. Das Container-Tag, das Sie gerade gebaut haben, beweist dann nichts. So sieht eine Migration am häufigsten fertig aus, ohne etwas zu ändern.

2. Als Tag neu aufbauen

   Ein Custom-HTML-Tag mit dem Snippet des Anbieters oder dessen eigene Vorlage, falls es eine in der Galerie gibt. Nehmen Sie lieber die Vorlage: Sie stellt die Parameter des Anbieters als richtige Felder bereit und bringt ihre Einwilligungseinstellungen meist schon mit.

3. Einwilligung am Tag einstellen, nicht nur am Trigger

   Bei einem Web-Tag finden Sie das unter Advanced Settings und dann Consent Settings. Dort verlangen Sie eine zusätzliche Einwilligung, damit das Tag feuert, und nennen die Einwilligungstypen, von denen es abhängt. Google dokumentiert das Panel in seiner Übersicht zur Einwilligung im Tag Manager. Der Trigger ist die andere Stellschraube. Sie brauchen beide, aus dem Grund im nächsten Abschnitt.

4. Veröffentlichen und auf der Live-Seite testen

   Der Vorschaumodus läuft mit der Debug-Verkabelung des Containers und sehr oft mit einem Einwilligungsstatus, den Sie selbst eine Minute vorher durchgeklickt haben. Er eignet sich, um zu bestätigen, dass ein Tag existiert. Was ein echter Besucher bekommt, belegt er nicht.

5. Beide Wege in der Seite prüfen, nicht im Container

   Bei Ablehnung sollte der Anbieter weder im DOM noch im Resource Timing auftauchen. Dann wurde nichts eingefügt und nichts abgerufen. Bei Zustimmung sollte er in beiden erscheinen. Entscheidend ist das Resource Timing: Wurde der Host des Anbieters abgerufen, dann wurde er abgerufen, egal was der Container gemeldet hat.

Eine Ausnahme von Schritt drei, und sie ist wichtig: Alles oben Gesagte gilt für Skripte von Drittanbietern. Googles eigene Tags haben eingebaute Einwilligungsprüfungen. Eine Additional-Consent-Prüfung an einem GA4- oder Google-Ads-Tag blockiert es deshalb komplett, statt sein Verhalten anzupassen. Ob Sie Googles eigene Tags bis zur Einwilligung blockieren sollten erklärt, warum, und wie Sie ablesen, was Ihr Container tatsächlich tut.

Taucht der Anbieter danach bei Ablehnung immer noch auf, ist das verschobene Skript wahrscheinlich nicht das, was feuert. Etwas anderes auf der Seite lädt ihn. Das ist ein anderer Fehler mit eigener Diagnose, beschrieben in Warum das Facebook-Pixel trotz blockierter Tags lädt.

Ist eine Einwilligungsprüfung am Tag dasselbe wie ein Trigger, der wartet?

Diese Unterscheidung entscheidet, ob die Sperre tatsächlich hält. Ein Trigger steuert, wann ein Tag in Betracht kommt. Die Einwilligungseinstellungen steuern, ob es dann laufen darf.

Sperren Sie nur mit einem Trigger, haben Sie den ersten Seitenaufruf abgedeckt und sonst nichts. Ein Tag, dessen Trigger ein späteres Ereignis ist, ein Klick, ein abgeschicktes Formular, ein Routenwechsel in einer Single-Page-App, kommt in dem Moment erneut in Betracht, in dem das Ereignis eintritt. Ohne Einwilligungsanforderung am Tag läuft es dann, egal was der Besucher gewählt hat.

Setzen Sie die Anforderung zusätzlich am Tag, hält die Sperre, egal auf welchem Weg das Tag erreicht wird. Der Trigger sagt, wann das Feuern in Betracht kommt. Die Einwilligungseinstellungen sagen, ob es erlaubt ist. Zusammen wird die Sperre zu einer Eigenschaft des Tags und nicht nur eines Weges dorthin.

Darf ein als unbedingt erforderlich eingestuftes Skript die Sperre umgehen?

Die letzte Einschränkung ist nicht technischer Art. Manchmal wird ein Anbieter als unbedingt erforderlich eingestuft, damit er vor der Einwilligung laufen darf, und gelegentlich ist das Argument stichhaltig. Wichtig ist, dass der Consent-Hinweis und die Cookie-Tabelle der Website Wort für Wort dasselbe sagen.

Wenn Ihr Hinweis einen Anbieter in einer Kategorie aufführt, die der Besucher ablehnen kann, muss das Tag diese Ablehnung respektieren. Ein Skript, das ungesperrt läuft, während die Seite dem Besucher sagt, er könne es ablehnen, ist ein Widerspruch, den eine Aufsichtsbehörde direkt auf Ihrer eigenen Website ablesen kann. Und er ist deutlich leichter zu finden als ein falsch konfigurierter Container.

Velo blockiert nach Kategorie in der Seite und gibt dieselbe Entscheidung an den Container weiter. Die Wahl des Besuchers erreicht Seite und Container also gleichzeitig.