- Die Meta Conversions API sendet Events wie Purchase von deinem Server, sodass sie Meta auch dann erreichen, wenn das Browser-Pixel blockiert wird.
- Betreibe sie neben dem Pixel und gib beiden Kopien denselben Eventnamen und dieselbe event_id; Meta zählt das Event dann einmal, wenn beide innerhalb von 48 Stunden eintreffen.
- Website-Events brauchen action_source, event_source_url und den User Agent des Käufers; gehashte E-Mail-Adresse und Telefonnummer, IP-Adresse, fbp und fbc entscheiden, wie gut Meta sie zuordnen kann.
- Teste mit dem Tab Test events im Events Manager und entferne danach den Testcode, denn Testevents werden nicht verworfen.
- Die meisten Probleme entstehen durch nicht passende Event-IDs, die eigene IP-Adresse des Servers, eine verlorene fbclid oder Kontaktdaten, die ohne Normalisierung gehasht wurden.
Mit der Meta Conversions API (CAPI) sendet dein Server Events wie Purchase direkt an Meta. Das Meta-Pixel sendet dieselben Events aus dem Browser des Käufers. CAPI sendet sie von deinem Server, sodass sie auch dann ankommen, wenn ein Adblocker das Pixel stoppt, ein Cookie fehlt oder die Dankeseite nie lädt.
Dieser Leitfaden behandelt, was ein Event der Conversions API enthält, wie du sie mit einer einzigen event_id neben dem Pixel betreibst, welche Parameter Meta verlangt und empfiehlt, wie du mit Test events testest und welche Fehler am häufigsten auftreten.
Was ist die Meta Conversions API?
Die Conversions API ist Teil der Graph API von Meta. Dein Server sendet eine HTTPS-POST-Anfrage an graph.facebook.com/VERSION/PIXEL_ID/events mit einem Access Token und einer data-Liste mit bis zu 1,000 Events. Jedes Event beschreibt eine Aktion, etwa einen Kauf, in drei Teilen: was passiert ist, wer es getan hat und die Details.
| Feld | Was es enthält |
|---|---|
event_name | Die Aktion, zum Beispiel Purchase, AddToCart oder InitiateCheckout |
event_time | Wann es passiert ist, als Unix-Zeitstempel in Sekunden |
event_id | Eine eindeutige ID für dieses Event, mit der es gegenüber dem Pixel dedupliziert wird |
action_source | Wo es passiert ist: website bei Shop-Käufen |
event_source_url | Die Seiten-URL, auf der das Event passiert ist |
user_data | Kundeninformationen für das Matching: gehashte E-Mail-Adresse und Telefonnummer, IP-Adresse, User Agent, fbp und fbc |
custom_data | Details wie value, currency und content_ids |
Ein gekürztes Purchase-Event sieht so aus:
{
"data": [{
"event_name": "Purchase",
"event_time": 1792929600,
"event_id": "order-1042",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkouts/thank-you",
"user_data": {
"em": ["<SHA-256 of the normalized email>"],
"ph": ["<SHA-256 of the normalized phone>"],
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; ...)",
"fbp": "fb.1.1792928400000.1234567890",
"fbc": "fb.1.1792928400000.AbCdEf123"
},
"custom_data": { "value": 74.00, "currency": "USD" }
}]
}Kontaktfelder wie E-Mail-Adresse und Telefonnummer werden normalisiert und mit SHA-256 gehasht, bevor sie deinen Server verlassen. IP-Adresse, User Agent, fbp und fbc werden unverändert gesendet.
Warum die Conversions API neben dem Pixel betreiben?
Meta empfiehlt, die Conversions API neben dem Pixel zu betreiben und dieselben Events über beide zu senden. Jede Seite sieht etwas, das die andere nicht sieht, und zusammen liefern sie Meta vollständigere Daten.
- Setzt das Cookie _fbp und speichert die fbclid eines Anzeigenklicks im Cookie _fbc
- Sieht die Seite und den Browser, während der Besuch stattfindet
- Geht verloren, wenn der Browser es blockiert oder die Seite nicht lädt
- Sendet die bezahlte Bestellung aus den Daten deines Shops
- Kann gehashte E-Mail-Adresse, Telefonnummer und Adresse aus der Bestellung hinzufügen
- Hängt nicht vom Browser ab, deshalb stoppen Adblocker es nicht
Der Preis dafür, beides zu betreiben: Meta erhält jetzt zwei Kopien jedes Events. Der nächste Abschnitt zeigt, wie Meta nur eine behält.
Wie funktioniert die Deduplizierung mit einer event_id?
Meta behandelt ein Browser-Event und ein Server-Event als dasselbe Event, wenn zwei Dinge übereinstimmen: der Eventname und die Event-ID. Im Pixel steht die ID in der Option eventID. In der Conversions API steht derselbe Wert in event_id.
fbq('track', 'Purchase', { value: 74.00, currency: 'USD' }, { eventID: 'order-1042' });Meta dedupliziert ein passendes Paar nur, wenn die beiden Kopien innerhalb von 48 Stunden nacheinander eintreffen. Ein paar Regeln sorgen dafür, dass das in der Praxis funktioniert:
- Erzeuge die ID nur einmal. Bilde sie aus etwas, das beide Seiten kennen, etwa der Bestellnummer, und gib sie an den Browser und den Server weiter. Zwei Systeme, die jeweils ihre eigene ID erzeugen, passen nicht zusammen.
- Verwende ein einheitliches Format.
order-1042und1042sind unterschiedliche IDs. - Der Event-Name muss exakt übereinstimmen.
Purchaseundpurchasesind verschiedene Events. - Sende das Server-Event zügig. Ein Server-Event, das mehr als 48 Stunden nach dem Browser-Event eintrifft, wird ein zweites Mal gezählt.
Meta beschreibt außerdem eine zweite Methode, die Events über fbp oder external_id paart. Laut Meta funktioniert sie in der Regel nur, wenn das Browser-Event vor dem Server-Event eintrifft, deshalb ist eine gemeinsame event_id die zuverlässigere Wahl. Wenn Meta trotzdem mehr Käufe meldet, als dein Shop hatte, listet unser Leitfaden zu doppelten Purchase-Events die üblichen Ursachen auf.
Welche Parameter sind erforderlich, und welche werden empfohlen?
Die Pflichtfelder machen ein Event gültig. Die empfohlenen Felder entscheiden, wie viele deiner Events Meta einer Person zuordnen kann, und nur zugeordnete Events lassen sich für die Attribution und die Anzeigenauslieferung nutzen.
| Parameter | Website-Events | Was gesendet werden soll |
|---|---|---|
event_name | Erforderlich | Ein Standard-Event wie Purchase oder ein benutzerdefinierter Eventname |
event_time | Erforderlich | Unix-Zeit in Sekunden, höchstens 7 Tage in der Vergangenheit |
action_source | Erforderlich | website für Events in deinem Shop |
event_source_url | Erforderlich | Die Seiten-URL, auf der das Event passiert ist |
client_user_agent | Erforderlich | Der Browser-String des Käufers, nicht der deines Servers |
user_data | Erforderlich | Mindestens ein Parameter für Kundeninformationen |
event_id | Empfohlen | Dieselbe ID, die das Pixel verwendet, für die Deduplizierung |
em, ph | Empfohlen | E-Mail-Adresse und Telefonnummer, normalisiert und mit SHA-256 gehasht |
client_ip_address | Empfohlen | Die IP-Adresse des Käufers, nicht gehasht |
fbp, fbc | Empfohlen | Die Cookies mit Browser-ID und Click-ID, nicht gehasht |
external_id | Empfohlen | Deine eigene Kunden-ID, in Browser- und Server-Events identisch |
value, currency | Mit Purchase senden | Der Bestellwert und ein dreistelliger Währungscode |
Drei Details verursachen die meisten Probleme:
- Normalisiere, bevor du hashst. Meta erwartet die E-Mail-Adresse ohne Leerzeichen am Rand und in Kleinbuchstaben, Telefonnummern als Ziffern mit Ländervorwahl.
Anna@Example.comundanna@example.comergeben unterschiedliche Hashes, und nur der zweite kann zugeordnet werden. - Hashe keine Browser-Kennungen.
fbp,fbc, die IP-Adresse und der User Agent werden als Klartextwerte übergeben. - Behalte die Click-ID genau so, wie sie ist. Der Wert
fbcbesteht ausfb.1., dem Erstellungszeitpunkt in Millisekunden, einem Punkt und derfbclidaus der URL der Landingpage. Diefbclidunterscheidet Groß- und Kleinschreibung. Speichere sie, wenn der Besucher landet, denn beim Checkout steht sie nicht mehr in der URL.
Wie gut diese Felder zugeordnet werden, misst der Event-Match-Quality-Score von Meta. Unser Leitfaden zur Event Match Quality behandelt jeden Parameter, die Hashing-Regeln und den Score, den du anstreben solltest.
Wie testest du Events mit Test events?
Der Events Manager hat einen Tab Test events, der Events zeigt, sobald sie ankommen. Nutze ihn, bevor du dich auf ein neues Setup verlässt.
- Test events öffnen
Wähle im Events Manager dein Dataset (Pixel) aus und öffne den Tab Test events. Kopiere den dort angezeigten Testcode.
- Den Code zu deinen Server-Events hinzufügen
Sende ihn in der Anfrage als
test_event_code. In ROASaurus fügst du ihn in das Feld Test event code des Meta-Pixels ein. - Eine Testbestellung aufgeben
Besuche den Shop, lege ein Produkt in den Warenkorb und bezahle, damit sowohl das Pixel als auch der Server ein Purchase senden.
- Die beiden Kopien vergleichen
Beide Kopien sollten denselben Eventnamen, dieselbe Event-ID, denselben Wert und dieselbe Währung zeigen.
- Die Kundeninformationen prüfen
Das Server-Event sollte gehashte E-Mail-Adresse und Telefonnummer, die IP-Adresse, den User Agent und fbp enthalten, dazu fbc, wenn der Besuch mit einem Anzeigenklick begann.
- Den Testcode entfernen
Meta sagt, das Feld sei nur zum Testen gedacht, entferne es also, bevor du dich auf die Events verlässt.
Purchase browser order-1042 74.00 USDVom PixelPurchase server order-1042 74.00 USDVon der Conversions APIevent_name + event_id matchAls ein Kauf gezähltem ph fbp fbc client_ip_address client_user_agentKundeninformationen im Server-EventHäufige Fehler der Conversions API und wie du sie behebst
| Was du siehst | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Die gesamte Anfrage schlägt fehl und kein Event wird verarbeitet | Ein Event im Batch hat eine event_time, die mehr als 7 Tage zurückliegt | Sende Events, wenn sie passieren. Korrigiere alte Events oder verwirf sie, bevor du es erneut versuchst. |
| Meta meldet mehr Käufe, als dein Shop hatte | Unterschiedliche Event-IDs, ein Pixel-Event ohne eventID oder eine zweite App, die dasselbe Pixel sendet | Verwende für beide Kopien eine ID und pro Pixel einen Server-Sender. |
| Niedrige Match-Qualität bei Server-Events | Dein Server sendet seine eigene IP-Adresse und seinen eigenen User Agent | Gib die IP-Adresse und den User Agent weiter, die aus dem Browser oder der Bestellung des Käufers erfasst wurden. |
| Wenige Events mit fbc | Die fbclid wurde auf der Landingpage nicht gespeichert oder wurde verändert | Speichere die fbclid genau so, wie sie ankommt, und bilde fbc daraus. |
| E-Mail-Adresse und Telefonnummer passen nicht | Werte ohne Normalisierung gehasht oder ohne Hashing gesendet | Entferne Leerzeichen am Rand der E-Mail-Adresse und schreibe sie klein, behalte bei der Telefonnummer Ziffern und Ländervorwahl und hashe dann mit SHA-256. |
| Anfragen schlagen mit einem Fehler wegen eines abgelaufenen Tokens fehl | Das Access Token stammt aus einem Facebook-Login, und Login-Tokens laufen ab | Verbinde neu oder nutze ein System-User-Token aus dem Business Manager, das du ohne Ablaufdatum erstellen kannst. |
Öffne nach ein paar Tagen mit Live-Traffic den Tab Diagnostics im Events Manager. Meta listet dort Probleme mit Empfehlungen zur Behebung auf. Vergleiche danach die tägliche Purchase-Zahl im Events Manager mit den bezahlten Bestellungen in deinem Shop für dieselben Tage. Liegt Meta deutlich höher, listet unser Hilfeartikel zum Vermeiden von Doppelzählungen die Einstellungen auf, die du prüfen solltest.
So richtest du die Conversions API mit ROASaurus ein
ROASaurus sendet Events der Conversions API aus den Bestelldaten deines Shops, sodass du die Server-Seite nicht selbst bauen musst. Klicke unter Tracking & platforms auf Connect with Facebook und wähle dein Werbekonto und dein Pixel, oder füge die ID des Pixels (Datasets) und ein Conversions-API-Token ein. Die Einrichtungsanleitung für Meta führt durch beide Optionen, und die Seite zur Meta-Integration listet jedes gesendete Feld auf.
- Eine ID auf beiden Seiten. Browser- und Server-Events teilen sich eine Event-ID. Bei einem Kauf ist es
order-gefolgt von der Bestell-ID. - Eine kurze Wartezeit vor dem Kauf. Das Server-Purchase wartet nach dem Eingang der Bestellung einen kurzen Moment, damit zuerst das Browser-Event des Kaufs zugeordnet werden kann. Dessen IP-Adresse, User Agent und Seiten-URL werden dann zusammen mit den für den Besucher gespeicherten
fbpundfbcmit dem Server-Event gesendet. - Kundeninformationen aus der Bestellung. E-Mail-Adresse, Telefonnummer, Name und Adresse werden normalisiert und mit SHA-256 gehasht. Die Kunden-ID des Shops und die ROASaurus-Besucher-ID werden gehasht als
external_idmitgeschickt. - Events, die Meta nicht zuordnen kann, werden übersprungen. Ein Event ohne
fbc,fbp, E-Mail-Adresse, Telefonnummer oder IP-Adresse wird nicht gesendet.
Im Event log siehst du jede Server-Zustellung mit der Anfrage und der Antwort von Meta. Wenn sich deine Margen zwischen Produkten stark unterscheiden, kannst du neben jedem Kauf auch einen Gewinnwert senden: Unser Leitfaden zur Meta-Wertoptimierung für Gewinn erklärt, wie. Den gesamten Datenweg vom Klick bis zur Bestellung findest du unter Server-Side-Tracking.
Quellen
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Server Event Parameters
- Meta for Developers: Customer Information Parameters
- Meta for Developers: Using the API - Conversions API
- Meta for Developers: ClickID and the fbp and fbc Parameters