Wie bringe ich Meta Signals Gateway dazu, die Cookie-Einwilligung zu beachten?

Alle Beiträge

Geben Sie dem Signals Gateway Pixel eine eigene Einwilligungsprüfung. Es ist vom Standard-Meta-Pixel getrennter Code und läuft über eine eigene cbq-Funktion, Sie können sich also nicht darauf verlassen, dass ein Consent-Aufruf an fbq es erreicht. Ergänzen Sie in Tag Manager an seinem Tag Consent-Einstellungen für ad_storage, ad_user_data und ad_personalization und lassen Sie es bei Ihrem Consent-Update-Event erneut feuern. Ohne Tag Manager halten Sie den Code zurück, bis der Besucher Werbung akzeptiert.

Die meisten Consent-Setups für Meta wurden für ein Pixel gebaut. Signals Gateway bringt ein zweites mit, und genau dieses zweite Pixel wird gern vergessen. Hier lesen Sie, warum das passiert, wie Sie es beheben und wie Sie die Lösung prüfen.

Warum steuert mein Cookie-Banner das Gateway-Pixel nicht schon?

Weil das Banner mit einer anderen Funktion spricht. Metas Consent-Steuerung für das Standard-Pixel ist ein Befehl an fbq: fbq('consent', 'revoke') vor init, dann fbq('consent', 'grant'), sobald der Besucher zustimmt. Metas Consent-Anleitung für das Pixel beschreibt genau dieses Paar. Die meisten Consent-Plattformen, Velo eingeschlossen, senden diese beiden Aufrufe, sobald eine Entscheidung wirksam wird.

Das Signals Gateway Pixel wird mit einem eigenen Basiscode installiert. Er definiert cbq, verweist mit cbq('setHost', …) auf das Gateway auf Ihrer eigenen Subdomain und sendet die Events von dort. Ein revoke an fbq ist ein Aufruf an ein anderes Objekt, und die Meta-Dokumentation zum Gateway-Pixel sagt überhaupt nichts zur Einwilligung. Verlassen Sie sich nicht darauf, dass der Consent-Aufruf des Standard-Pixels das Gateway-Pixel mit abdeckt.

Auch Google Consent Mode hilft hier nicht. Es ist Googles Signal für Google-Tags. Der Basiscode von Meta liest es nicht von sich aus, und ein Custom-HTML-Tag in Tag Manager liest es überhaupt nicht. Die Consent-Einstellungen von Tag Manager sind etwas anderes: Sie entscheiden, ob ein Tag feuert, egal welcher Code darin steckt. Damit bleiben zwei Stellen, an denen sich das Gateway-Pixel stoppen lässt: die Consent-Einstellungen des Tags in Tag Manager oder die Seite selbst.

Wie richte ich das Gateway-Pixel so ein, dass es auf die Einwilligung wartet?

Die folgenden Schritte gehen von Tag Manager aus, weil die meisten Websites das Gateway-Pixel so installieren. Schritt 4 behandelt Code direkt in der Seite.

1. Jede Kopie des Gateway-Pixels finden

   Durchsuchen Sie Ihren Container nach Tags, die cbq aufrufen, ob Gateway-Pixel-Template oder Custom-HTML-Tag, und prüfen Sie den Seitenquelltext auf denselben Basiscode. Eine zweite, ungesperrte Kopie macht die Arbeit an der ersten zunichte.

2. Consent-Einstellungen am Tag ergänzen

   Öffnen Sie am Tag des Gateway-Pixels Advanced Settings und dann Consent Settings. Wählen Sie Require additional consent for tag to fire und fügen Sie ad_storage, ad_user_data und ad_personalization hinzu. Ein so blockiertes Tag feuert nicht und sendet daher nichts.

3. Nach der Zustimmung erneut feuern

   Ein beim Laden blockierter Page View kommt nicht von selbst zurück. Ergänzen Sie einen Trigger auf das Update-Event Ihrer Consent-Plattform (bei Velo ist das velo_consent_update) und stellen Sie Tag firing options auf Once per page, damit eine Zustimmung den Page View genau einmal auslöst.

4. Ohne Tag Manager den Code zurückhalten

   Steht der Basiscode direkt in der Seite, ändern Sie seinen Script-Typ auf text/plain und kennzeichnen Sie ihn mit der Werbe-Kategorie Ihrer Consent-Plattform. Bei Velo ist das data-velo-category="ads". Der Code läuft dann erst, wenn der Besucher Werbung erlaubt.

5. Beiden Pixeln dieselbe Event-ID geben

   Senden Standard-Pixel und Gateway-Pixel beide einen Purchase, kann Meta ihn doppelt zählen. Duplikate entfernt Meta am zuverlässigsten, wenn beide denselben Event-Namen und dieselbe Event-ID verwenden. Setzen Sie eine einzige Tag-Manager-Variable in das Feld Event ID beider Tags.

6. Vor dem Veröffentlichen testen

   Führen Sie die vier Prüfungen aus dem nächsten Abschnitt auf der Live-Website durch, jedes Mal in einer frischen Browser-Sitzung.

Templates unterscheiden sich, lesen Sie also die Dokumentation des Templates, das Sie installiert haben. Manche Community-Templates für das Gateway-Pixel, darunter das von Stape, dokumentieren ein eigenes Consent-Handling auf Basis von ad_storage. Manche haben ein eigenes Consent-Feld, in der Version aus unserer Anleitung zu Meta Pixel und Signals Gateway mit der Bezeichnung Consent Granted (GDPR). Sind die Consent-Einstellungen in Tag Manager gesetzt, lässt die Anleitung es auf True, weil die Consent-Einstellungen das Tag bereits zurückhalten. Installieren Sie das Gateway-Pixel als Custom-HTML-Tag, gibt es dieses Feld nicht, und die Consent-Einstellungen sind die einzige Sperre. Sie funktionieren gleich, egal welches Template Sie nutzen.

Wie prüfe ich, ob das Gateway-Pixel die Entscheidung respektiert?

Beobachten Sie das Netzwerk, nicht die Tag-Liste. Ein Tag kann in der Vorschau von Tag Manager als blockiert erscheinen, während eine fest im Theme verbaute Kopie weiter Events sendet.

• Vor jeder Entscheidung: Öffnen Sie das Network-Panel und filtern Sie nach Ihrer Gateway-Subdomain und facebook.com/tr. Es sollte nichts erscheinen.
• Nach Zustimmung zu Werbung: Der Page View sollte Ihr Gateway erreichen. Prüfen Sie das in der Event-Aktivität des Gateways oder unter Test events im Events Manager.
• Nach Ablehnung: Rufen Sie zwei Seiten auf. Keine Anfragen an das Gateway oder an Meta.
• Nach dem Widerruf: Stimmen Sie zu, widerrufen Sie dann über den Datenschutz-Button und laden Sie eine weitere Seite. Ab dieser Seite sollten keine Anfragen mehr rausgehen.

Prüfen Sie dann im Events Manager, ob Warnungen zur Deduplizierung auftauchen. Unsere Checkliste zum Testen eines Cookie-Banners vor dem Livegang enthält den vollständigen Ablauf im Browser, und dieselbe Sorgfalt bei den Sitzungen gilt auch hier.

Ändert ein Gateway auf meiner eigenen Subdomain, welche Einwilligung ich brauche?

Nein. Die EU-Regel in Art. 5 Abs. 3 der ePrivacy-Richtlinie betrifft das Speichern von Informationen auf dem Gerät des Besuchers und den Zugriff darauf. Sie fragt nicht, an wessen Domain die Anfrage geht. Meta beschreibt Signals Gateway als Möglichkeit, Events auf der eigenen Infrastruktur zu empfangen und zu senden. Das ändert den Weg der Daten, nicht die Entscheidung des Besuchers darüber.

Das ist dieselbe Antwort, die wir für Googles Version der Idee gegeben haben: Braucht Google Tag Gateway eine Cookie-Einwilligung? Ein First-Party-Pfad ist eine Routing-Entscheidung. Ob das Tag läuft, entscheidet weiterhin die Einwilligung.

Was ist mit Events, die das Gateway an die Conversions API weiterleitet?

Ist das Browser-Pixel gesperrt, erhält das Gateway nichts aus dem Browser dieses Besuchers und hat folglich nichts weiterzuleiten. Die Lücke liegt woanders. Events, die Ihr eigener Server sendet, etwa ein Kauf, den Ihr Checkout an die Conversions API meldet, laufen nie über das Banner. Wenden Sie die Werbe-Entscheidung des Besuchers auf diese Events an, bevor Sie sie senden. Sonst ignoriert der Serverweg stillschweigend die Entscheidung, die der Browser respektiert hat.

Das ist dasselbe Muster wie beim Standard-Pixel, nur eine Ebene tiefer. Unser Beitrag dazu, warum das Facebook-Pixel trotz blockierter Tags weiter lädt, behandelt die fest eingebauten Kopien, die hinter den meisten dieser Lecks stecken.

Velo sendet grant und revoke an das Standard-Meta-Pixel, sobald eine Entscheidung wirksam wird. An das Signals Gateway Pixel übermittelt es die Entscheidung noch nicht. Für dieses Pixel nutzen Sie also die Consent-Einstellungen in Tag Manager oder die oben gezeigte Sperre über die Kategorie ads.