Warum Tags auslösen, bevor das Cookie-Banner lädt

Alle Beiträge

Ein anderes Tag teilt sich den Trigger, den Ihr Cookie-Banner eigentlich für sich allein haben sollte. Das Banner auf Consent Initialization zu legen, ist notwendig, aber nicht ausreichend. Dieser Trigger lässt alles, was an ihm hängt, gleichzeitig los, nicht der Reihe nach. Ein leichteres Tag daneben kann also das Netzwerk zuerst erreichen, während das Banner noch seine Konfiguration lädt.

Der Trigger ist ein Startschuss, keine Warteschlange

Den Consent Initialization-Trigger gibt es, damit Consent-Standardwerte registriert sind, bevor irgendetwas anderes ausgewertet wird. Jede Anleitung, die Ihnen rät, Ihr Consent-Tool dort einzuhängen, hat recht. Was sie verschweigen: was passiert, wenn ein zweites Tag auf demselben Trigger liegt. Der Trigger wird dadurch keine Warteschlange. Er lässt alles los, was an ihm hängt, und ab diesem Moment liefern sich die Tags ein Rennen über das Netzwerk.

Die Priorität der Tag-Auslösung wirkt wie die Antwort, ist es aber nicht. Die Hilfeseite von Tag Manager zur Tag-Priorität sagt, dass Tags mit höherem Prioritätswert vor Tags mit niedrigerem Wert ausgelöst werden. Dann folgt der entscheidende Satz: Tags werden trotzdem asynchron ausgelöst. Die Priorität bestimmt, in welcher Reihenfolge Anfragen starten. Sie lässt den Container nicht warten, bis eine fertig ist. Ein Consent-Tool, das seine Konfiguration über das Netzwerk laden muss, kann also zuerst starten und trotzdem als Zweites ankommen. Genau dieser Fall kostet Sie.

Was wir auf einer Live-Website gemessen haben

Das gemeldete Symptom: Eine Werbeanfrage verließ den Browser, bevor überhaupt ein Consent-Status existierte, und das auf einer Website, deren Consent-Setup ansonsten in Ordnung war. Die „denied“-Standardwerte waren gesetzt, das Signal auf der ausgehenden Analytics-Anfrage stand auf „denied“, und das Template des Consent-Tools lag genau wie dokumentiert auf Consent Initialization.

Auf demselben Trigger lag ein Remarketing-Tag. Wir haben das Netzwerk-Panel in der Reihenfolge gelesen, in der die Anfragen starteten, nicht in der Vorschau. Bei jedem aufgezeichneten Ladevorgang ging die Werbeanfrage vor dem Loader des Consent-Tools raus, mit einem Vorsprung von etwa zwei Millisekunden. Entscheidend ist die Reihenfolge, der Abstand dient nur zur Veranschaulichung: Das Netzwerk-Panel eines Browsers misst nicht im Submillisekundenbereich, und die Zahl schwankt mit Verbindung und Cache. Was sich nicht ändert, ist, welche Anfrage zuerst rausging und warum. Das ist kein langsames Banner. Es sind zwei Dinge, die gleichzeitig losgelassen werden, und eines davon hatte weniger zu tun.

Warum jedes Audit des Consent-Tools sauber war

Weil jedes Audit ein Audit des Consent-Tools war, und das Consent-Tool hat seine Arbeit gemacht. Prüft man es so, wie wir es normalerweise empfehlen, also indem man das Consent-Signal auf der ausgehenden Anfrage liest, ist das Ergebnis bestanden. Denn die Anfrage, die Sie lesen, ist die, die sich korrekt verhalten hat.

Auch der Vorschaumodus klärt das nicht. Er zeigt, welche Tags in welchem Ereignis ausgelöst wurden. Das ist nicht dasselbe wie die Frage, welche von zwei gleichzeitig losgelassenen Anfragen das Netzwerk zuerst erreicht hat. Ein Container, der in der Vorschau korrekt aussieht, kann neben einer Seite stehen, die es nicht ist.

Es gibt auch das Spiegelbild dazu, das im Audit ebenfalls sauber aussieht. Das Consent-Tool funktioniert einwandfrei, aber die Tags, die es steuern soll, feuern überhaupt nicht, weil noch Variablen einer früheren Plattform in ihren Blockierregeln stecken. Diesen Fall behandeln wir in Was Sie beim Wechsel der Consent-Management-Plattform prüfen sollten.

Vier Ursachen, ein Symptom

Ein Tag, das vor dem Laden des Banners feuert, hat mehr als eine Ursache. Sie lassen sich leicht auseinanderhalten, sobald man weiß, dass es verschiedene Dinge sind.

1. Ein anderes Tag teilt sich den Trigger

   Der Fall oben. Das Consent-Setup ist korrekt, das störende Tag ist schnell, und das Rennen sieht man nirgends außer im Netzwerk-Panel. Es tritt konstant auf, nicht sporadisch, weil bei jedem Laden dasselbe Tag gewinnt.

2. Das Consent-Tool liegt auf dem falschen Trigger

   Auf All Pages konkurriert es mit dem gesamten Container statt mit einem einzelnen Tag. Diesen Fall löst der Standardrat bereits, schließen Sie ihn also zuerst aus. Die richtige Platzierung steht in Cookie-Banner mit Google Tag Manager installieren.

3. Das Consent-Tool lädt außerhalb des Containers

   Steht das Banner im Seitenquelltext und lädt der Container separat, hängt es von der Seite ab, welche Anfrage gewinnt, nicht von einer Tag-Einstellung. Es variiert je nach Template und Cache-Zustand. Sporadisches Verhalten deutet auf diesen Fall hin. Wie Sie das Skript in WordPress ganz am Anfang des Heads ausgeben, steht in Cookie-Banner in WordPress ohne Plugin einbinden. Auch das Google Tag Gateway kann die Position des Google-Tags in dieser Reihenfolge verschieben. Mehr dazu in Braucht das Google Tag Gateway eine Cookie-Einwilligung?.

4. Das Tag hat gar keine Einwilligungsprüfung

   Kein Rennen. Ein Tag ohne Einwilligungsprüfung fragt den Consent-Status nie ab. „Denied“-Standardwerte halten es also nicht auf, und keine Reihenfolge wird es tun. Es feuert zuerst, weil es nie gewartet hat.

So sehen Sie die Reihenfolge selbst

Dafür braucht es einen Seitenaufruf und keinen Debug-Modus. Der ganze Trick: Hören Sie auf, den Container zu lesen, und lesen Sie, was den Browser verlassen hat.

1. Die Website in einem sauberen Profil laden und nichts anklicken

   Eine Sitzung, in der schon zugestimmt wurde, sagt nichts aus: Der Status wird aus einer gespeicherten Entscheidung wiederhergestellt, bevor das Rennen stattfindet.

2. Das Netzwerk-Panel nach Startzeit der Anfragen sortieren

   Die Standardansicht gruppiert Anfragen so, dass das untergeht. Sie brauchen die Zeitleiste, nicht die Liste.

3. Die Anfrage des Consent-Tools finden, dann nach oben lesen

   Alles darüber von einem Werbe- oder Analytics-Anbieter ging raus, bevor es eine Einwilligung gab. Damit haben Sie das Tag gefunden.

4. Den Container öffnen und jedes Tag auf Consent Initialization auflisten

   Dort sollten höchstens zwei liegen: das Consent-Tool und das Tag, das Ihre „denied“-Standardwerte registriert. Alles andere ist ein Kandidat. Alles auf dieser Liste, was misst oder wirbt, ist zugleich genau das, was Aufsichtsbehörden tatsächlich ahnden. Das erklären wir in Drohen Bußgelder ohne Cookie-Banner?.

5. Zweimal neu laden, bevor Sie Schlüsse ziehen

   Eine konstante Reihenfolge bedeutet einen geteilten Trigger. Ändert sich die Reihenfolge zwischen Ladevorgängen, lädt das Consent-Tool außerhalb des Containers, und das braucht eine andere Lösung.

Die Lösung, und warum es nicht die Priorität ist

Nehmen Sie das störende Tag von Consent Initialization und geben Sie ihm All Pages oder ein eigenes Ereignis. Das Rennen endet, weil es kein Rennen mehr gibt, und die Änderung dauert zwei Minuten. Muss ein Tag wirklich früh laufen, ist die Tag-Sequenzierung das präzisere Werkzeug als die Priorität, weil sie festlegt, welches Tag vor welchem feuert, statt nur eine Präferenz auszudrücken.

Widerstehen Sie den zwei verlockenden Scheinlösungen. Eine höhere Priorität lässt beide Tags auf dem Trigger und verlangt von einem asynchronen System eine synchrone Garantie, die es nicht bietet. Ein zweites Tag für die Standardwerte bedeutet zwei Stellen, die Consent-Standardwerte setzen. Das ist ein neues Problem, keine Lösung. Wenn Sie wirklich doppelt absichern wollen, setzen Sie ein kleines Inline-Snippet mit „denied“-Standardwerten in den Head der Seite, oberhalb des Container-Snippets. Dann existiert ein abgelehnter Status, bevor der Container geparst wird. Auf einer gehosteten Plattform, bei der der Head aus einem einzigen Eingabefeld besteht, ist diese Reihenfolge schon der größte Teil der Installation: was Squarespace Ihnen bietet und was nicht.

Messen Sie danach noch einmal, genauso wie Sie das Problem gefunden haben. Eine echte Lösung zeigt bei jedem sauberen Ladevorgang zuerst die Anfrage des Consent-Tools, und die Werbeanfrage wartet entweder oder trägt ein „denied“-Signal. Haben sich die Zahlen bewegt, die Reihenfolge aber nicht, haben Sie etwas anderes behoben. Conversions, die sich um dasselbe Datum herum verschoben haben, verdienen denselben Blick: warum GA4-Conversions über Nacht einbrechen.

Eine Prüfung noch, bevor Sie überhaupt schließen, dass die Reihenfolge Ihr Problem ist. Ist die Werbeanfrage auch bei korrekter Reihenfolge noch da, schauen Sie, wer sie erzeugt hat. Ein Pixel, das zur Laufzeit vom Skript eines anderen Anbieters eingefügt wird, ist nie durch den Container gelaufen. Keine Trigger-Änderung erreicht es. Diesen Fall beschreiben wir in Warum das Facebook-Pixel trotz blockierter Tags lädt.

Velo nimmt den Ladevorgang aus diesem Rennen. Das Skript setzt die „denied“-Standardwerte, sobald es läuft, noch vor jeder Konfigurationsanfrage. Steht das Skript über dem Container, existieren sie also, bevor der Container erreicht wird. Die Platzierung bleibt trotzdem wichtig, und andere Tags gehören weiterhin nicht auf diesen Trigger. Wie es funktioniert, steht auf der Produktseite.