Sollten Sie Googles eigene Tags bis zur Einwilligung blockieren?

Alle Beiträge

Bei einer Implementierung mit Advanced Consent Mode nicht. Im Basic-Modus schon: Basic bedeutet, dass Google-Tags blockiert bleiben, bis der Besucher einwilligt. Im Advanced-Modus bleiben Googles eigene Tags entsperrt und setzen die Entscheidung des Besuchers über integrierte Einwilligungsprüfungen selbst durch. Eine zusätzliche „Additional Consent“-Prüfung blockiert sie vollständig. Damit wird Advanced still zu Basic, und das „denied“-Signal, aus dem Google modelliert, fällt weg. Der Test: Ein abgelehnter Besuch sollte trotzdem gcs=G100 senden.

Der Rat stimmt. Er betrifft nur nicht Googles Tags.

Fast alles, was über Einwilligung in Google Tag Manager geschrieben wird, läuft auf dieselbe Anweisung hinaus: Tag absichern. „Advanced Settings“ öffnen, dann „Consent Settings“, zusätzliche Einwilligung verlangen, Typen benennen. Für ein Anbieter-Skript, das beim Laden sofort sein eigenes Cookie schreibt, ist das richtig, und unser eigener Leitfaden zum Verschieben eines Skripts in Google Tag Manager, um es abzusichern, sagt genau das.

Vorab ein Hinweis, denn er betrifft die Rechtslage und nicht die Technik. Manche Betreiber, gerade in Deutschland, blockieren auf anwaltlichen Rat den ganzen Container bis zur Einwilligung. Das ist eine bewusste Entscheidung für Basic, bei der die Kosten für die Messung in Kauf genommen werden, und etwas anderes als eine vergessene Einwilligungsprüfung an einem GA4-Tag. In diesem Beitrag geht es um Letzteres.

Googles eigene Tag-Typen sind die Ausnahme, und das ist keine Geschmacksfrage. Google sagt es klar in seinem Leitfaden zum Entsperren von Google-Tags. Seine Tags haben integrierte Einwilligungsprüfungen und passen ihr Verhalten selbst an. Zusätzliche Prüfungen brauchen sie nicht, und wer beides gleichzeitig einsetzt, sorgt dafür, dass sie nicht mehr richtig funktionieren. Ein GA4-Konfigurations-Tag oder ein Google-Ads-Conversion-Tag weiß bereits, worauf ad_storage und analytics_storage gesetzt sind. Eine „Additional Consent“-Prüfung sitzt vor dieser Mechanik und lässt sie nie laufen.

Gelernt haben wir das über fünf Container-Versionen einer Einwilligungs-Sanierung. Das Banner war in Ordnung. Der Container hatte an allem eine Einwilligungsprüfung, gleichmäßig verteilt, und deshalb hatte das Konto aufgehört, irgendetwas zu modellieren.

Was die zusätzliche Prüfung wirklich kostet

Ein entsperrtes Google-Tag sendet auf einer Seite, auf der der Besucher abgelehnt hat, trotzdem eine Anfrage. Sie geht an /g/collect, ohne Cookies und ohne Client-Kennung, mit gcs=G100: Consent Mode ist aktiv, beide Speichertypen sind verweigert. Das ist eine erfasste Ablehnung, und genau sie nutzt Googles Modellierung als Input, um die Conversions zu schätzen, die Google nicht beobachten darf.

Ein blockiertes Google-Tag sendet überhaupt nichts. Nichts ist keine Ablehnung. Es ist Abwesenheit, und aus Abwesenheit kann ein Modell nicht lernen. Privater wird der Besuch dadurch auch nicht, denn die entsperrte Anfrage war auf diesem Weg ohnehin cookielos. Sie haben nur Ihren eigenen Nachweis gelöscht, dass der Besucher da war.

Diese eine Einstellung entscheidet also faktisch, ob die Website Advanced oder Basic Consent Mode nutzt, egal was im Banner-Bildschirm steht. Es ist dieselbe Frage wie Basic oder Advanced Consent Mode, nur von der Tag-Seite aus betrachtet. Dieser „denied“-Ping ist der Input, aus dem Google modelliert, und die Modellierung läuft erst, wenn Ihre Website die Datenschwellen aus Googles Dokumentation zum Consent Mode erfüllt. Was dabei herauskommt, ist eine Schätzung, keine beobachteten Conversions.

So prüfen Sie, was Sie tatsächlich ausgeliefert haben

Fünf Schritte, in dieser Reihenfolge.

1. Jedes Tag mit einer „Additional Consent“-Prüfung auflisten

   Gehen Sie den Container Tag für Tag durch, statt dem Integrationsleitfaden zu vertrauen, mit dem er eingerichtet wurde. In jedem Tag steht unter „Advanced Settings“ und dann „Consent Settings“ entweder „No additional consent required“ oder eine Liste benannter Einwilligungstypen. Notieren Sie jedes Tag mit einer solchen Liste. In einem Container, der zwei CMP-Wechsel hinter sich hat, ist sie zuverlässig länger, als alle erwarten.

2. Die Prüfung bei jedem Google-Tag-Typ entfernen

   GA4-Konfigurations- und Event-Tags, Google-Ads-Conversion- und Remarketing-Tags, Floodlight und das Google-Tag selbst kommen zurück auf „No additional consent required“. Lassen Sie die Prüfungen an echten Drittanbieter-Tags. Die Grenze ist die Zuständigkeit, nicht die Sensibilität: Ein Google-Tag setzt die Einwilligung selbst durch, ein Meta- oder Hotjar-Tag nicht.

3. Auslöseoption von „Once per page“ auf „Once per event“ umstellen

   Ein Tag, das einmal pro Seite auslösen soll, zählt einen blockierten Versuch als sein eines Auslösen. Der Trigger löst aus, bevor der Besucher entscheidet, die Einwilligungsprüfung stoppt das Tag, und der Zähler verbucht seinen Durchgang trotzdem als verbraucht. Kommt die Einwilligung und der Trigger löst erneut aus, überspringt der Container das Tag. Es sieht in jeder Ansicht korrekt aus und liefert nichts. „Once per event“ ist die richtige Einstellung für alles, was vor einer Entscheidung ausgelöst werden kann.

4. Das Einwilligungs-Update abwarten, bevor Sie einen Trigger bewerten

   Der Container bewertet den Einwilligungsstatus eines Tags genau in dem Moment, in dem sein Trigger auslöst, und eine CMP wendet eine gespeicherte Entscheidung asynchron an, typischerweise einige hundert Millisekunden nach Seitenstart. Ein Tag beim Seitenaufruf kann also bewertet werden, während die Einwilligung noch auf „denied“ steht, bei einem Besuch von jemandem, der vor Wochen akzeptiert hat. Das Symptom: ein Tag, das bei einem Klick auslöst, aber nie bei einem Seitenaufruf. Googles integrierte Prüfungen regeln dieses Timing selbst. Das ist der zweite Grund, sie nicht zu umhüllen.

5. Auf der Live-Seite prüfen, nie im Vorschaumodus

   Der Vorschaumodus läuft mit der Debug-Verkabelung des Containers und sehr oft mit einem Einwilligungsstatus, den Sie selbst angeklickt haben. Laden Sie die Produktivseite in einem frischen Browser, lehnen Sie ab und lesen Sie, was den Browser verlässt. Tag Assistant sagt Ihnen, dass das Tag ausgelöst hat. Nur der Netzwerk-Tab sagt Ihnen, was Google erhalten hat.

Die Diagnose in einer Zeile

Öffnen Sie den Netzwerk-Tab auf der Live-Seite, filtern Sie nach collect und lehnen Sie ab. Verlässt eine Anfrage mit gcs=G100 den Browser, sind Ihre Google-Tags entsperrt, und die Ablehnung wird gemeldet. Ein leerer Tab bedeutet, dass etwas sie blockiert, und dafür gibt es nur zwei realistische Kandidaten: eine „Additional Consent“-Prüfung am Tag oder ein Banner, das den ganzen Container blockiert, bevor das Tag überhaupt existiert.

Akzeptieren Sie dann und wiederholen Sie den Test: gcs=G111 bedeutet, dass beide Signale erteilt sind. Wie das Update überhaupt in den Container gelangt, beschreibt die Installationsanleitung für Google Tag Manager. Es lohnt sich, sie mit dieser Ausnahme im Kopf noch einmal zu lesen.

Velo arbeitet standardmäßig andersherum: Es aktualisiert Consent Mode, überlässt es Googles Tags, das Ergebnis selbst durchzusetzen, und sichert nur die Skripte ab, die das nicht können. Was Ihnen kein Banner abnehmen kann, ist Schritt eins, denn die Prüfungen in Ihrem Container hat das eingebaut, was ihn vorher eingerichtet hat.