Warum das Facebook-Pixel lädt, obwohl Ihre Tags blockiert sind

Alle Beiträge

Das Facebook-Pixel lädt meist aus einem von drei Gründen: Sein Basiscode läuft im Head Ihrer Seite vor dem Banner, sein Tag feuert, bevor Ihre Consent-Standardwerte gesetzt sind, oder das Tag hat nie eine Werbeeinwilligung vorausgesetzt. Ist all das sauber, fügt vermutlich das Skript eines anderen Anbieters das Pixel zur Laufzeit ein, und Ihr Container kann keine Anfrage steuern, die er nie gestellt hat.

Zuerst die üblichen Ursachen ausschließen

Meistens ist es eine dieser Ursachen.

• Der Basiscode des Pixels steht im Head Ihrer Seite ohne fbq('consent', 'revoke') darüber und initialisiert sich deshalb, bevor Ihr Banner erscheint.
• Das Tag feuert über einen Trigger, der läuft, bevor Ihre Consent-Standardwerte gesetzt sind. Es liest also überhaupt keine Entscheidung.
• Das Tag war nie so eingestellt, dass es eine Werbeeinwilligung voraussetzt. Es feuert also, egal was drumherum passiert.
• Ein Social-Media-Embed, ein Like-Button oder ein Kommentar-Widget setzt eigene Cookies.

Prüfen Sie jeden Punkt auf einer Live-Seite, nicht im Container. Die Methode steht in So erkennen Sie, ob ein Tag wirklich vor der Einwilligung Cookies setzt. Ist all das sauber und bleiben die Anfragen, liegt die Ursache außerhalb Ihres Containers.

Ein Consent-Tool steuert, was Ihr Container kontrolliert

Ein Werbe-Pixel gelangt auf einem von drei üblichen Wegen auf eine Seite, und ein Consent-Tool erreicht jeden davon anders. Die meisten veröffentlichten Antworten gehen von den ersten beiden aus.

Der erste ist ein Tag in Ihrem Container, das feuert, wenn der Consent-Status es erlaubt. Der zweite ist ein Skript im Quelltext Ihrer Seite, das ein Consent-Tool meist ebenfalls zurückhalten kann, indem es das Skript erkennt, bevor der Browser es ausführt.

Den dritten Weg lassen die meisten Anleitungen aus. Ein Skript, das bereits läuft und das Sie berechtigterweise zugelassen haben, lädt zur Laufzeit sein eigenes Werbemodul und fügt das Pixel ein. Ihr Container hat diese Anfrage nie gestellt, also wird keine Änderung darin sie stoppen.

So sah der dritte Weg auf einer Live-Website aus, die wir im August geprüft haben. Cookies von Meta und LinkedIn wurden vor der Einwilligung geschrieben, und die interne Diagnose gab den Container-Tags die Schuld. In einer frischen Sitzung, mit sichtbarem Banner und ohne einen Klick, waren beide Tags an eine Bedingung für Werbespeicherung geknüpft, und keines feuerte. Die Cookies tauchten trotzdem auf, mit denselben Pixel-IDs. Der Grund: Ein zugelassenes Tag einer Marketingplattform lud seine eigene Werbe-Pixel-Datei, und die lud die Bibliotheken von Meta und LinkedIn. Falsch konfiguriert war nichts. Die Grenze lag nur nicht dort, wo alle sie vermuteten.

So erkennen Sie, welche Form Sie haben

Ein paar Minuten, ohne den Container zu öffnen.

1. Die Website in einem frischen Profil öffnen und alles ablehnen

   Keine gespeicherte Einwilligung, das Netzwerk-Panel vor dem ersten Rendern geöffnet und eine bewusste Ablehnung.

2. Nach den Hosts des Pixels filtern

   Für Meta sind das connect.facebook.net für die Bibliothek und facebook.com/tr für das Ereignis. Schauen Sie auch in das Application-Panel: Taucht in dieser frischen Sitzung ein _fbp-Cookie auf Ihrer eigenen Domain auf, wurde die Bibliothek meist geladen. Keine Anfragen und kein Cookie heißt: Dieses Problem haben Sie nicht.

3. Die Initiator-Kette aufklappen, nicht nur die oberste Zeile lesen

   Bei diesem Schritt passieren die meisten Fehler. Ihr Tag Manager taucht oft in der Kette auf, weil er das Anbieterskript viel früher geladen hat. Das ist kein Beleg dafür, dass ein Tag aus dem Tag Manager diese Anfrage gestellt hat. Entscheidend ist der Eintrag direkt über dem Pixel-Aufruf: Er nennt das Skript, dem der Aufruf gehört.

4. Den Container mit dem Gesehenen abgleichen

   Öffnen Sie die Vorschau und prüfen Sie, ob die Werbe-Tags ausgelöst wurden. Ein Tag in der Liste „nicht ausgelöst“, während die Anfrage trotzdem erscheint, ist kein Widerspruch: Die beiden Werkzeuge beschreiben zwei verschiedene Ebenen.

5. Das zuständige Skript bis zu seiner Plattform zurückverfolgen

   Finden Sie den Anbieter dahinter und dann dessen Einstellung für die Werbeintegration. Diese Einstellung, nicht Ihre Consent-Konfiguration, bringt das Pixel auf die Seite.

Warum strengere Regeln im Container nicht helfen können

Es fühlt sich nach Fortschritt an, und genau deshalb ist es teuer. Das Team ergänzt an den Werbe-Tags eine Consent-Bedingung, dann einen Blockier-Trigger, dann eine Ausnahme, und kommt zu dem Schluss, dass das Consent-Tool kaputt ist. Dabei betraf jede Änderung ein Tag, das ohnehin nicht feuerte.

Trennen Sie das vom Fehler, mit dem es verwechselt wird. Dass Ihre eigenen Tags feuern, bevor das Banner seine Standardwerte registriert, ist ein Timing-Problem. Das lässt sich im Container tatsächlich beheben, und wir haben es in Warum feuern Tags, bevor das Cookie-Banner lädt? behandelt. Hier geht es um Reichweite, nicht um Timing: Ihre Tags haben sich korrekt verhalten, und etwas außerhalb ihrer Reichweite hat genau das getan, was Sie verhindern wollten.

Wo die Lösung tatsächlich liegt

Vier Hebel. Welcher der richtige ist, hängt davon ab, was das Anbieterskript vor der Einwilligung tut und in welche Kategorie das Skript von Anfang an gehört hätte. Diese Entscheidung behandelt In welche Consent-Kategorie gehört welches Drittanbieter-Skript?.

• Das Portal des Anbieters. Die meisten Plattformen, die Werbe-Pixel einfügen, bieten dafür eine Einstellung. Diese Integration abzuschalten ist der sauberste Weg: Das Skript erledigt weiter seine eigentliche Arbeit und trägt kein fremdes Pixel mehr mit sich.
• Ein früher Aufruf zum Widerruf der Einwilligung. fbq('consent', 'revoke') läuft, bevor irgendetwas das Pixel initialisieren kann, und weist die Meta-Bibliothek an, ihre Ereignisse zurückzuhalten, egal wer sie geladen hat. Metas eigene Dokumentation zur Einwilligung beschreibt die Aufrufe für Widerruf und Erteilung. Das ist eine Absicherung, keine vollständige Antwort: Die Bibliothek lädt trotzdem, und es hilft nur, wenn Ihr Aufruf wirklich zuerst läuft.
• Das Tag des Anbieters in Ihrem Container. Lädt ein Tag, das Ihnen gehört, das Anbieterskript, knüpfen Sie dieses Tag an die Werbeeinwilligung. Grob, denn Sie verlieren für ablehnende Besucher auch alles andere, was das Skript leistet, etwa Formulare oder Chat.
• Kategorie-Blockierung im Consent-Tool. Lädt das Anbieterskript außerhalb Ihres Containers, kategorisieren Sie das Skript selbst als Werbung, damit das Tool es zurückhält, bevor es läuft. Derselbe Kompromiss.

Wiederholen Sie dann denselben Test: frisches Profil, ablehnen, filtern, bestätigen, dass nichts die Pixel-Hosts erreicht. Eine Einschränkung: Das prüft nur den Browser. Alles, was Ihre Server über eine Conversions API senden, müssen Sie an der Quelle prüfen. Am Ziel zu prüfen statt am Banner ist die generelle Gewohnheit, beschrieben in So prüfen Sie, ob Ihr Banner das Consent-Signal wirklich sendet.

Wenn Sie auch Metas Signals Gateway nutzen, filtern Sie zusätzlich nach Ihrer Gateway-Subdomain: Dessen Pixel ist separater Code, der eine eigene Einwilligungsprüfung braucht. Mehr dazu in So berücksichtigt Meta Signals Gateway die Cookie-Einwilligung.

Velo hält die Skripte, die Sie mit einer Consent-Kategorie markieren, zurück, bis diese Kategorie erlaubt ist. Ein Pixel, das ein anderer Anbieter ohne diese Markierung einfügt, müssen Sie trotzdem bis zum Anbieter zurückverfolgen.