Facebook Pixel: Konfiguration
Facebook Pixel Plugin für Sylius: Einstellungen pro Channel, Conversions-API-Einrichtung, Fail-Closed-Einwilligungspflicht und Praxisbeispiele.
Facebook Pixel: Konfiguration
Live Demo: Teste dieses und weitere Plugins live — ohne Installation, ohne Risiko: demo.markus-michalski.net
Einstellungen pro Channel
Im Admin unter MMKreativ Plugins > Facebook Pixel gibt es eine Zeile pro Sylius-Channel. Die Übersicht zeigt Channel, Pixel-ID, Tracking aktiviert und Conversions API aktiviert. Ein Channel ohne Zeile, oder mit ausgeschaltetem Tracking aktiviert, verhält sich genau so, als wäre das Plugin nicht installiert.
| Einstellung | Standard | Beschreibung |
|---|---|---|
| Channel | - | Der Sylius-Channel, für den diese Zeile gilt; pro Channel ist nur eine Zeile möglich. |
| Tracking aktiviert | Aus | Hauptschalter. Browser-Pixel und CAPI bleiben aus, solange er fehlt, unabhängig von allen Einstellungen darunter. |
| Pixel-ID | leer | Numerische Meta-Pixel-ID aus dem Meta Events Manager. Nur Ziffern werden akzeptiert; ohne gültige Pixel-ID wird auch bei gesetztem Tracking aktiviert nichts gerendert und nichts gesendet. |
| Brutto-Preise tracken | Ein | Ob AddToCart, InitiateCheckout und Purchase den Brutto- oder den Nettowert melden (Summe der Position bzw. der Bestellung mit oder ohne Steuer). Gilt nicht für ViewContent. |
| PageView tracken | Ein | Feuert auf jeder Storefront-Seite. |
| ViewContent tracken | Ein | Produktdetailseite. |
| ViewCategory tracken | Ein | Kategorie-Listenseite (wird als Meta-Custom-Event gesendet, fbq('trackCustom', ...)). |
| AddToCart tracken | Ein | Feuert bei der tatsächlichen Warenkorb-Aktion, nicht bei jedem Neuladen der Warenkorbseite. |
| InitiateCheckout tracken | Ein | Erster Checkout-Schritt (Adresse). |
| Purchase tracken | Ein | Bestellbestätigungsseite. |
| Tracking-Skripte über Klaro-Einwilligung freischalten | Ein | Siehe Storefront-Integration. Wirkt nur, solange mmd/sylius-klaro-consent-plugin installiert ist; sonst ist das Feld deaktiviert und wird abgewählt angezeigt. |
| Conversions API aktiviert | Aus | Serverseitige Kopie der Events, siehe unten. |
| Für serverseitige Events nachgewiesene Einwilligung verlangen | Ein | Standardmäßig Fail-Closed, siehe unten. |
| Conversions-API-Zugriffstoken | leer | Nur schreibend: Das gespeicherte Token wird nie wieder angezeigt; leer lassen behält das aktuelle Token. |
| Gespeichertes Token entfernen | Aus | Ankreuzen löscht das Token, unabhängig vom Inhalt des Token-Felds. |
| Test-Event-Code | leer | Aus dem Meta Events Manager unter Test-Events, nur zum Testen. In Produktion leer lassen. |
| Über Conversions API gesendete Events | keins ausgewählt | Welche der getrackten Events zusätzlich serverseitig gesendet werden. Zur Auswahl stehen alle sechs Events. |
Conversions API (serverseitig)
Ein Event geht per CAPI an Meta, wenn alle diese Bedingungen erfüllt sind:
- Tracking aktiviert ist an und die Pixel-ID ist gültig.
- Das Tracking für dieses Event ist angehakt (z. B. Purchase tracken). Die CAPI-Kopie entsteht an derselben Stelle wie das Browser-Event; ist das Event ausgeschaltet, gibt es auch keine serverseitige Kopie.
- Conversions API aktiviert ist an und ein Zugriffstoken ist gespeichert.
- Das Event ist unter Über Conversions API gesendete Events ausgewählt. Standardmäßig ist keins ausgewählt, ein frisch angelegter Channel sendet also nichts per CAPI.
- Die Einwilligungsprüfung lässt es zu (siehe unten).
Der Versand läuft asynchron über Symfony Messenger (der main-Transport), sodass ein langsamer oder fehlgeschlagener Aufruf bei Meta nie den Storefront-Request oder die Warenkorb-Aktion blockiert. Fehler beim Versand werden nur geloggt, es gibt keinen erneuten Versuch.
Für serverseitige Events nachgewiesene Einwilligung verlangen (standardmäßig an, auch für bestehende Zeilen) entscheidet, ob CAPI überhaupt senden darf: Ist die Option an, muss mindestens ein Consent-Evidence-Provider die Einwilligung des aktuellen Besuchers bestätigen, sonst wird nichts gesendet (Fail-Closed). Wird die Option ausgeschaltet, entfällt diese Prüfung komplett: Events gehen dann ohne jeden Einwilligungsnachweis an Meta, und die Verantwortung für eine anderweitig eingeholte Einwilligung liegt beim Betreiber. Der eingebaute Klaro-Provider und eigene Provider: siehe Erweiterbarkeit.
Welche Daten dabei übertragen werden, steht auf der Seite Datenschutz.
Praxisbeispiele
B2C-Shop mit Klaro, CAPI nur für Purchase
- Tracking aktiviert: ein, Pixel-ID: die eigene numerische ID
- Tracking-Skripte über Klaro-Einwilligung freischalten: ein (Standard)
- Conversions API aktiviert: ein, Zugriffstoken eingefügt, Über Conversions API gesendete Events:
Purchase - Für serverseitige Events nachgewiesene Einwilligung verlangen: ein (Standard). CAPI sendet dann nur für Besucher, deren Klaro-Cookie
facebook_pixelzustimmt.
B2B-Shop ohne Klaro, Nettopreise, kein CAPI
- Tracking aktiviert: ein, Pixel-ID: die eigene numerische ID
- Brutto-Preise tracken: aus
- Tracking-Skripte über Klaro-Einwilligung freischalten: deaktiviert (Klaro-Plugin nicht installiert). Ein anderes Consent-Tool im Shop muss das Pixel-Skript selbst blockieren, bis die Einwilligung vorliegt.
- Conversions API aktiviert: aus