Facebook Pixel: Fehlerbehebung und FAQ
Facebook Pixel Plugin für Sylius: häufige Probleme nach Symptom, Prüfung und Lösung, bekannte Einschränkungen und häufige Fragen.
Facebook Pixel: Fehlerbehebung und FAQ
Live Demo: Teste dieses und weitere Plugins live — ohne Installation, ohne Risiko: demo.markus-michalski.net
Häufige Probleme
Das Pixel-Skript erscheint nie in der Storefront
- Symptom: keine
fbq-Aufrufe im Seitenquelltext, nichts in der Meta-Pixel-Helper-Browser-Erweiterung. - Prüfung: Hat der Channel eine Zeile mit angehaktem Tracking aktiviert und einer gültigen numerischen Pixel-ID? Ist Tracking-Skripte über Klaro-Einwilligung freischalten wirksam (angehakt und Klaro installiert), und wurde im Browser noch keine Einwilligung erteilt? Dann steht das Skript als
text/plainim Quelltext und läuft erst nach der Einwilligung. - Lösung: Channel-Einstellungen unter MMKreativ Plugins > Facebook Pixel korrigieren. Bei Klaro-Gating zum Test im Klaro-Dialog die Einwilligung für
facebook_pixelerteilen.
Ein einzelnes Event fehlt
- Symptom:
PageViewkommt an,Purchaseoder ein anderes Event nicht. - Prüfung: Ist das Tracking für genau dieses Event angehakt (z. B. Purchase tracken)? Wird die Hook-Stelle von einem Theme überschrieben, ohne den Hook weiter zu rendern (siehe Storefront-Integration)?
- Lösung: Checkbox setzen bzw. den Hook im Theme weiter rendern.
Events erscheinen im Meta Events Manager doppelt
- Symptom: Dieselbe Aktion (z. B. ein
Purchase) scheint doppelt gezählt zu werden. - Prüfung: Ist das die erwartete Deduplizierung (Browser- und Server-Event stehen getrennt in der Rohliste, Metas Auswertung fasst sie über die
event_idzusammen), oder werden zwei Pixel-Basis-Codes auf derselben Seite geladen (ein anderes Plugin, eine Theme-Überschreibung, ein Tag-Manager)? - Lösung: Bei echten Duplikaten sicherstellen, dass der Bootstrap-Hook genau einmal pro Seite rendert und keine andere Integration
fbq()ein zweites Mal lädt.
CAPI-Events kommen nie bei Meta an
- Symptom: Browser-Events erscheinen im Events Manager, serverseitige ("Conversions API") nicht.
- Prüfung: Ist Conversions API aktiviert angehakt? Ist das Zugriffstoken gespeichert (das Feld wird immer leer angezeigt, im Zweifel erneut eingeben)? Ist das Event unter Über Conversions API gesendete Events ausgewählt (standardmäßig ist keins ausgewählt)? Ist das Browser-Tracking für dieses Event angehakt? Und, die häufigste Ursache: Ist Für serverseitige Events nachgewiesene Einwilligung verlangen an, ohne dass ein Provider die Einwilligung des Test-Besuchers bestätigen kann (kein Klaro installiert, keine Cookie-Speicherung, nie zugestimmt)?
- Lösung: Vor dem Test die Klaro-Einwilligung erteilen, einen eigenen Provider ergänzen (siehe Erweiterbarkeit) oder, nur in voller Kenntnis der Konsequenzen, die Pflicht ausschalten. Außerdem prüfen, ob ein Messenger-Worker für den
main-Transport läuft (bin/console messenger:consume), denn CAPI-Nachrichten werden asynchron versendet. Mit einem Test-Event-Code aus dem Events Manager siehst du die Events dort unter Test-Events.
Preise sind 0 oder wirken falsch
- Symptom:
valueist0, fehlt oder stimmt nicht mit der Storefront überein. - Prüfung: Hat die Variante einen Preis für diesen Channel? Fehlt der Channel-Preis, entfällt
valuebeiViewContent. Ist Brutto-Preise tracken passend gesetzt (an für B2C, aus für B2B)? - Lösung: Brutto-/Netto-Einstellung korrigieren.
ViewContentnutzt immer den Variantenpreis des Channels,AddToCart,InitiateCheckoutundPurchasedie Summen der Position bzw. der Bestellung.
Bekannte Einschränkungen
- Das Ausschalten von Für serverseitige Events nachgewiesene Einwilligung verlangen entfernt die serverseitige Einwilligungsprüfung komplett: Events gehen dann ohne jeden Nachweis an Meta. Nur ausschalten, wenn der Grund bekannt ist.
- Der eingebaute Provider braucht
mmd/sylius-klaro-consent-pluginmit Cookie-Speicherung und einer aktiven Zeile für den Channel. Ohne ihn (nicht installiert, keine aktive Zeile, oderlocalStorage, das der Server nicht lesen kann) sendet CAPI für diesen Channel nie, solange die Pflicht an ist und kein anderer Provider bestätigt. - Die CAPI-Kopien entstehen beim Rendern der Twig-Storefront und bei der Add-to-Cart-Aktion. Ein Headless-Frontend ohne Twig-Rendering löst keine serverseitigen Events aus.
- Ein erneutes Laden der Bestellbestätigungsseite erzeugt mit derselben
event_iderneut ein Browser- und ein CAPI-Event; die stabile ID erlaubt Meta, sie zusammenzufassen. - Einzel-Event-Skripte ohne Klaro-Gating warten auf
DOMContentLoaded, falls das Dokument noch lädt. Klaro-gegatete Skripte werden nicht gesondert verzögert. - Der
valuevonViewContentist der Variantenpreis des Channels; Brutto-Preise tracken wirkt dort nicht. - Der Klaro-Katalogeintrag wird bestmöglich angelegt: Ein abweichendes Klaro-Schema wird geloggt und übersprungen, statt das Speichern scheitern zu lassen. Lege den Dienst
facebook_pixelin dem Fall von Hand im Klaro-Katalog an. - CAPI-Aufrufe werden bei Fehlern nicht wiederholt, sondern nur geloggt.
FAQ
Allgemein
Braucht dieses Plugin mmd/sylius-klaro-consent-plugin? Nein. Es wird zur Laufzeit erkannt und genutzt, falls vorhanden; das Plugin funktioniert auch ohne. Ohne Klaro musst du selbst sicherstellen, dass dein Consent-Tool das Pixel-Skript blockiert, und für CAPI einen eigenen Provider ergänzen oder die Pflicht bewusst ausschalten.
Ist das derselbe Code wie das Shopware-Plugin? Es ist der Sylius-Port der Funktionalität von mmd/sw67-facebook-pixel, gebaut auf Syliuss eigener Architektur (Twig Hooks, Doctrine-Entities, Shop API, Symfony Messenger) statt einer Zeile-für-Zeile-Übersetzung.
Konfiguration
Kann ich auf einem Channel Brutto- und auf einem anderen Nettopreise tracken? Ja, Brutto-Preise tracken ist eine Einstellung pro Channel.
Kann ich CAPI nur für einzelne Events aktivieren? Ja. Wähle unter Über Conversions API gesendete Events nur die gewünschten Events aus. Ein Event kann nur serverseitig gesendet werden, wenn auch sein Browser-Tracking angehakt ist.
Kompatibilität
Funktioniert das mit einem Headless-Frontend? Teilweise: Der Endpunkt der Shop API liefert die Einstellungen, und das Frontend feuert das Pixel selbst. Serverseitige Events löst nur die Twig-Storefront aus.
Bricht ein eigenes Theme den Pixel? Nur, wenn es einen Hook-Punkt überschreibt, ohne den Hook weiter zu rendern. Siehe Storefront-Integration.