Blog · Meta
Meta server-side: Event Match Quality, fbp und fbc
Die Conversions API ist schnell angeschlossen. Ob Meta die Events aber einer Person zuordnen kann, hängt an wenigen Feldern. Zwei davon, fbp und fbc, sind Cookies, und genau die sind im Shopify-Checkout schwer zu greifen.
Worauf die Event Match Quality schaut
Meta bewertet pro Event, wie gut es einem Konto zugeordnet werden kann. Dafür zählen gehashte Kundendaten (E-Mail, Telefon, Name, PLZ, Land), eine externe ID, IP und User-Agent sowie die Browser-ID fbp und die Klick-ID fbc.
Zwei Dinge helfen in der Praxis am meisten:
- Eingeloggte Kunden nutzen. Shopify stellt im Pixel für eingeloggte Kunden ein Kundenobjekt bereit. Damit lassen sich E-Mail und Kunden-ID schon ab dem ersten Seitenaufruf mitgeben, nicht erst beim Kauf.
- Formate prüfen. Meta erwartet zum Beispiel beim Land einen ISO-Code, nicht den Landesnamen. In einem Projekt lagen Adressfelder unter falschen Schlüsseln und kamen nie an. Das fällt erst auf, wenn man den ausgehenden Request im Server-Container liest.
fbc gibt es nur nach einem Klick auf eine Meta-Anzeige. Eine niedrigere Abdeckung als bei fbp ist also normal.
Braucht es ein eigenes Custom Pixel für die Cookies?
Kurz: nein, nicht zwingend. Zwingend ist, dass fbp und fbc existieren, stabil bleiben und mit jedem Event beim Server ankommen. Dafür gibt es drei Wege.
| Weg | Wer erzeugt die Cookies | Worauf achten |
|---|---|---|
| Server erzeugt sie | Das Meta-Tag im sGTM setzt _fbp, wenn es fehlt, und bildet _fbc aus der fbclid in der URL |
Die echte Seiten-URL mit fbclid muss im sGTM ankommen. Aus dem Shopify-Pixel heißt das: page_location aus dem Event-Kontext mitgeben. |
| Pixel liest und schreibt sie | Das Custom Pixel liest die Cookies über browser.cookie und gibt sie als Parameter weiter |
Das gleiche Pixel nutzen, das GTM lädt. browser.cookie ist asynchron. |
| Meta-Pixel im Browser plus CAPI | Das Meta-Pixel setzt die Cookies, der Server sendet parallel | Deduplizierung über eine gemeinsame event_id. Cookie-Domain abstimmen, sonst entstehen zwei verschiedene fbp-Werte. |
In einem Projekt haben wir mit dem zweiten Weg begonnen: Das Pixel las die Cookies und schickte sie als eigene Parameter an den Server-Container. Später zeigte die Bestandsaufnahme, dass das Server-Tag die Werte längst selbst aus Cookie und Event-Daten holte. Die zusätzlichen Parameter wurden von keinem Tag mehr gelesen und kosteten nur Platz im GA4-Request (mehr dazu im Beitrag zu GA4 als Transportschicht).
Meine Empfehlung: ein Pixel, eine Quelle. Lassen Sie das Server-Tag die Cookies verwalten, und sorgen Sie dafür, dass URL und Klick-IDs korrekt ankommen. Ein zweites Pixel nur für Cookies löst selten ein Problem, das ein sauber konfiguriertes erstes nicht auch löst.
Falls Sie zusätzlich das Meta-Pixel im Browser einsetzen: Prüfen Sie zuerst, ob nicht schon eine Shopify-App ein eigenes Meta-Pixel lädt. Sonst zählen Sie dreifach.
Plausibilitätscheck im Event-Funnel
Ein schneller Test: Ordnen Sie die Events im Events Manager nach der Funnel-Logik. Gibt es mehr AddToCart als ViewContent, stimmt etwas nicht. Entweder fehlt ein Event auf bestimmten Seitentypen, oder ein anderes wird doppelt gesendet. Dieses Muster habe ich in einem Projekt gesehen. Die Ursache lag nicht bei Meta, sondern in der Event-Quelle.
Offizielles Meta-Tag oder Stape-Template?
Für den Server-Container gibt es ein Tag von Meta und ein Community-Template von Stape. Beide senden an die Conversions API. Der Unterschied liegt im Drumherum.
| Kriterium | Offizielles Meta-Tag | Stape-Template |
|---|---|---|
| Datenquelle | Erwartet Werte nach Metas Namenskonvention im GA4-Request (z. B. x-fb-ck-fbp, x-fb-ud-em) |
Liest Standard-Felder aus den Event-Daten, user_data und Cookies |
| Cookies | Liest vorhandene Cookies | Kann _fbp erzeugen, wenn es fehlt, und _fbc aus der URL bilden; optional HttpOnly |
| Consent | Über Trigger im Container | Eigene Consent-Einstellungen im Tag, zusätzlich zu Triggern |
| Debugging | Test-Event-Code | Test-Event-Code, optional Logging |
| Wann sinnvoll | Wenn Sie bewusst nur Meta-eigene Bausteine nutzen wollen | Wenn der Server die Cookies verwalten soll und Sie wenig clientseitige Vorbereitung wollen |
Ich nutze in Shopify-Projekten meist das Stape-Template. Der Grund ist der Punkt Cookies: Es nimmt der Sandbox Arbeit ab. Der Funktionsumfang beider Tags ändert sich laufend; prüfen Sie die aktuelle Version vor der Entscheidung.
Quellen: Stape: Meta Conversions API einrichten · Stape Community: zwei verschiedene fbp-Werte