Conversions ueber Elido-Kurzlinks an die Meta CAPI weiterleiten

Metas eigene Empfehlung, veroeffentlicht auf der Conversions API getting started page (abgerufen am 12.05.2026), positioniert das Browser-Pixel als Ergaenzung zur CAPI, nicht umgekehrt. Diese Verschiebung kam etwa mit iOS 14.5: App Tracking Transparency hat die Signalqualitaet von Meta beschnitten, ITP hat einen weiteren Teil verschluckt, und die Installationszahlen von Ad-Blockern sind weiter gestiegen. Bis 2026 sehen Teams, die Meta-Anzeigen auf iOS-lastige Zielgruppen ausspielen, regelmaessig, dass 30-40 % der Conversion-Events verschwinden, bevor sie im Reporting ankommen.

CAPI ist der serverseitige Kanal, der all das umgeht. Dein Server spricht direkt mit Metas Graph-API. ITP greift nicht. Ad-Blocker fangen nichts ab. Die Match-Rate steigt, weil du gehashte E-Mail-Adresse und Telefonnummer zusammen mit der Click-ID senden kannst; und weil beide Events - Browser und Server - denselben Dedup-Key teilen, zaehlt Meta die Conversion nur einmal, auch wenn beide Pfade feuern.

Dies ist die Schritt-fuer-Schritt-Anleitung, um CAPI ueber Elidos Kurzlinks anzubinden. Die server-side conversion tracking overview deckt die breitere Architektur ab (GA4, TikTok, Mixpanel, Retry-Semantik). Das end-to-end UTM tutorial lohnt sich vorab, wenn euer Kampagnen-Tagging noch informell ist.

TL;DR#

• Meta Pixel verliert auf iOS-lastigem Traffic 30-40 % der Conversion-Events an ITP und Ad-Blocker; CAPI sendet diese Events direkt vom Server und gewinnt den groessten Teil der Luecke zurueck.
• Der Deduplikationsschluessel - event_id - muss zwischen deinem browserseitigen Pixel und deinem CAPI-Event identisch sein. Wird das verpasst, kommt es zu Doppelzaehlung, was Metas Budgetallokation fuer die Optimierung kaputt macht.
• Eine hoehere Dichte an Match-Keys (gehashte E-Mail, Telefon, fbc Click-ID, fbp-Cookie) verbessert direkt die Attribution-Match-Rate; Elido erfasst fbclid zum Klickzeitpunkt und verknuepft es mit jeder spaeteren Conversion.
• Die Validierung dauert etwa 10 Minuten: der Meta Events Manager hat ein Test-Events-Panel, in dem CAPI-Events innerhalb von 30 Sekunden auftauchen - lange bevor sich das 24-Stunden-Match-Rate-Dashboard fuellt.

Was du vor dem Start brauchst#

Drei Dinge, alle aus dem Meta Business Manager.

Pixel ID. Jedes Meta-Werbekonto hat mindestens ein Pixel. Du findest es im Events Manager unter Data Sources. Die numerische Zeichenfolge - so etwas wie 1234567890 - ist das, was du in die Integrationseinstellungen von Elido einfuegen wirst.

System User Access Token. Das ist der Credential, der Elido autorisiert, Events an dein Pixel zu schreiben. Navigiere zu Business Settings, dann Users, dann System Users. Lege einen System User mit Standard-Zugriff an, weise ihn dem Pixel zu (Manage permissions) und erzeuge ein Token mit den Scopes ads_management und business_management. Das Token ist langlebig; rotiere es zusammen mit anderen Service-Credentials, nicht nach festem Plan. Speichere es als Workspace-Secret - nicht im Quellcode, nicht in einer Tabellenkalkulation.

Event Source URL Pattern. Jedes CAPI-Event traegt eine event_source_url, die Meta sagt, auf welcher Seite die Conversion stattgefunden hat. Bei Purchase-Events ist das typischerweise deine Checkout-Bestaetigungs-URL. Bei Lead-Events ist es die Seite mit dem Formular-Submit. Diese URLs hardcodest du nicht; sie kommen aus deinem Bestell-Webhook oder dem Request-Kontext deines Backends zum Conversion-Zeitpunkt.

Die Match-Keys: warum Dichte zaehlt#

Meta dedupliziert und matcht Server-Events auf Browser-Sessions mithilfe eines Sets an Kundeninformations-Parametern. Je mehr davon du sendest, desto hoeher die Match-Rate. Hoehere Match-Rate bedeutet mehr Conversions, die deinen Kampagnen zugeordnet werden, was bedeutet, dass der Optimierungsalgorithmus besseres Signal hat, was bessere ROAS bedeutet. Der Zusammenhang ist direkt.

Die vier wichtigsten Keys:

em (SHA-256 gehashte E-Mail). Das wertvollste Signal von allen. Wenn du die E-Mail-Adresse des Kunden zum Conversion-Zeitpunkt hast (im E-Commerce hast du sie fast immer), sende sie. Die Meta customer information parameters reference (abgerufen am 12.05.2026) spezifiziert die Normalisierungsregeln: Kleinbuchstaben, fuehrender und nachfolgender Whitespace entfernt, keine Aenderungen an der Domain. Hashe den normalisierten String. [email protected] direkt zu hashen produziert den falschen Wert; [email protected] ist das, was du hashen musst.

ph (SHA-256 gehashte Telefonnummer). Gleiche Normalisierungsdisziplin. E.164-Format: Laendervorwahl, keine Leerzeichen, keine Bindestriche, keine Klammern. +4915123456789 hasht zu etwas, das Meta matchen kann; 015123456789 nicht.

fbc (Facebook Click ID). Wenn ein Nutzer auf eine Meta-Anzeige klickt, erhaelt die Ziel-URL einen fbclid-Query-Parameter. Deine Landingpage oder der Elido-Redirect-Handler liest ihn aus und speichert ihn. Das Feld fbc wird daraus konstruiert: fb.{version}.{creationTime}.{fbclid}, wobei version 1 ist und creationTime der Unix-Zeitstempel in Millisekunden. Elido erfasst den fbclid aus der Redirect-URL zum Klickzeitpunkt und speichert ihn am Klick-Datensatz. Wenn du eine Conversion mit einer click_id POSTest, ist der fbc-Wert bereits angehaengt und wird automatisch mit weitergeleitet.

fbp (Facebook Browser Pixel Cookie). Das ist das _fbp-Cookie, das das Meta-Pixel-JS auf deiner Domain setzt. Aus Sicht deiner Domain ist es ein First-Party-Cookie. Dein Server liest es zum Checkout-Zeitpunkt aus den Request-Headern und nimmt es in das Conversion-Payload auf. Ohne dieses Cookie verschlechtert sich Metas Match-Rate fuer den browserseitigen Fallback-Pfad.

Die praktische Prioritaetsreihenfolge: em zuerst (fast immer verfuegbar), fbc als zweites (Elido liefert es fuer click-basierte Conversions), fbp als drittes (auf der Bestaetigungsseite aus dem Cookie gelesen), ph zuletzt (oft nicht erfasst). Ein Payload mit em + fbc matcht deutlich besser als eines mit nichts.

Anbindung in Elido#

Die Integration liegt in den Workspace Settings, unter /integrations, dann Meta CAPI.

Fuege deine Pixel ID und das System-User-Access-Token ein. Elido validiert das Token sofort gegen Metas Graph-API - ein 400 hier bedeutet, dass das Token fehlerhaft ist oder die noetigen Scopes fehlen; pruefe die Berechtigungen des System Users, bevor du fortfaehrst. Sobald validiert, ist die Integration fuer den Workspace aktiv. Alle getrackten Links im Workspace nehmen teil; es gibt keinen Toggle pro Link.

Wenn auf einen getrackten Link geklickt wird, liest Elidos Edge-Handler die fbclid aus dem Query-String (falls vorhanden) und schreibt sie in den Klick-Datensatz. Das passiert auf der Redirect-Ebene, bevor der Nutzer deine Seite erreicht - die Erfassung ist also zuverlaessig, unabhaengig davon, ob das JavaScript deiner Zielseite ueberhaupt laeuft.

Wenn ein Conversion-Event feuert, POSTe es an /v1/conversions:

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "Purchase",
    "event_id":   "ord_98231",
    "value":      89.50,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789"
    }
  }'

Beim Empfang sucht Elido den Klick-Datensatz, liest die gespeicherte fbclid, um fbc zu konstruieren, normalisiert und hasht email und phone, baut das vollstaendige CAPI-Payload zusammen und POSTet an https://graph.facebook.com/v21.0/{pixel_id}/events. Der API-Aufruf gibt sofort eine Conversion-ID zurueck; das Fan-out zu Meta laeuft im Hintergrund und ist ueber GET /v1/conversions/{id} beobachtbar.

Das rohe CAPI-Payload, das Elido konstruiert, sieht so aus:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1747047600,
      "event_id": "ord_98231",
      "action_source": "website",
      "event_source_url": "https://shop.example.com/checkout/thanks?order=98231",
      "user_data": {
        "em": ["a3b6e2f4...sha256 of [email protected]"],
        "ph": ["c7d9f1a3...sha256 of +4915123456789"],
        "fbc": "fb.1.1747040000.AbCdEfGhIj",
        "fbp": "fb.1.1747040000.987654321",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
        "client_ip_address": "203.0.113.42"
      },
      "custom_data": {
        "currency": "EUR",
        "value": 89.5,
        "content_ids": ["sku-spring-jeans-32-blue"],
        "content_type": "product",
        "num_items": 1
      }
    }
  ],
  "access_token": "EAAxxxxxxx"
}

Die Felder event_source_url und action_source werden aus der Ziel-URL des Klick-Datensatzes und dem Parameter source der Conversion-Anfrage abgeleitet (Standard: website). Wenn du App-seitige Conversions weiterleitest, uebergib "source": "app" im POST-Body.

Deduplikationsdisziplin#

Lies Metas Dokumentation zur Event-Deduplikation (abgerufen am 12.05.2026), bevor du Production-Traffic anfasst. Die Kurzfassung: Meta matcht Browser-Pixel-Events und CAPI-Events ueber event_id + event_name innerhalb eines 48-Stunden-Fensters. Wenn beide Events dasselbe Paar tragen, wird das zweite stillschweigend verworfen.

Die daraus folgende operative Anforderung: das Purchase-Event deines browserseitigen Pixels und dein serverseitiges CAPI-Event muessen dieselbe event_id teilen. Die zuverlaessigste Wahl ist deine Order-ID: beide Seiten sehen sie, sie ist stabil und wird bei Wiederholungen nicht neu erzeugt.

Wo das in der Praxis kaputtgeht: der Server erzeugt zum Forward-Zeitpunkt eine UUID, statt die Order-ID zu verwenden. Oder das Browser-Pixel verwendet ein ID-Schema (ord_98231), waehrend das Backend ein anderes verwendet (order-98231). Beide Events kommen an. Keines wird dedupliziert. Deine gemeldeten Conversions verdoppeln sich. Metas Algorithmus ueberverteilt Budget an die Kampagne basierend auf aufgeblasenen Zahlen. Das Budget-Review drei Wochen spaeter offenbart "unsere ROAS ist irgendwie 2,5x unseres tatsaechlichen Umsatzes" - und die Forensik ist unangenehm.

Das untenstehende Sequenzdiagramm zeigt, wie die event_id durch das System wandert:

Der browserseitige Pixel-Aufruf passiert clientseitig, wenn die Bestaetigungsseite laedt. Der serverseitige CAPI-Forward passiert, wenn dein Bestell-Webhook feuert. Beide muessen event_id: ord_98231 (oder was auch immer dein Bestell-Identifier ist) emittieren. Die zeitliche Luecke zwischen den beiden ist irrelevant, solange beide innerhalb von 48 Stunden ankommen.

Wenn du kein browserseitiges Pixel betreibst (entfernt aus GDPR-Consent-Gruenden oder weil deine Zielgruppe komplett Ad-Blocker-lastig ist), ist Deduplikation belanglos. Sende ausschliesslich CAPI. Aber die meisten Teams fahren beides; das Browser-Pixel liefert ein Fallback-Signal fuer Nutzer, deren CAPI-Events keine Match-Keys tragen koennen (keine E-Mail erfasst, keine fbclid).

Validierung#

Die Validierungsschleife ist kurz und sollte ablaufen, bevor irgendein Production-Traffic durchflieesst.

Schritt eins: Test-Event-Code setzen. In Elidos Meta-CAPI-Integrationseinstellungen gibt es ein Feld fuer den Test-Event-Code. Hol dir einen Code aus dem Meta Events Manager unter Test Events. Fuege ihn ein. Solange dieser Code gesetzt ist, wird jedes CAPI-Event, das Elido sendet, ins Test-Panel geroutet - es laeuft niemals ins Produktiv-Reporting.

Schritt zwei: Test-Conversion ausloesen. Klicke auf einen deiner getrackten Links aus einem Browser (das erfasst die fbclid, falls die Link-URL aus einer Meta-Anzeige stammt oder falls die fbclid zum Testen manuell angehaengt wurde). POSTe eine Conversion gegen diese click_id mit einer realistischen Order-ID, einem Wert und einer E-Mail-Adresse.

Schritt drei: Test Events pruefen. Im Meta Events Manager sollte das Test-Event innerhalb von 30 Sekunden auftauchen. Pruefe, dass der event_name mit dem uebereinstimmt, was dein Browser-Pixel sendet. Pruefe, dass die event_id die Order-ID ist und keine UUID. Pruefe, dass em, fbc oder fbp im user_data-Abschnitt erscheinen - mindestens ein Match-Key sollte vorhanden sein.

Schritt vier: Test-Event-Code entfernen. Sobald validiert, leere das Feld fuer den Test-Event-Code und speichere. Produktive Events beginnen zu fliessen. Das Match-Rate-Dashboard im Events Manager braucht 24 Stunden, bis es sich mit aussagekraeftigen Daten fuellt.

Worauf du nach 24 Stunden achten solltest: Match-Rate ueber 60 % ist arbeitsfaehig; ueber 75 % ist gut; ueber 85 % bedeutet, dass deine Match-Key-Dichte hoch ist und die Attribution zuverlaessig sein wird. Wenn du unter 60 % liegst, ist die wahrscheinlichste Ursache eine fehlende fbc (die fbclid war nicht auf der Landing-URL) oder ein Normalisierungsfehler beim Hashing.

Haeufige Fehlerbilder#

Fehlende event_source_url. CAPI-Events ohne dieses Feld werden akzeptiert, aber in Metas Matching-Logik benachteiligt. Das Feld sollte die URL der Seite sein, auf der die Conversion stattgefunden hat - deine Checkout-Bestaetigungs-URL, deine Lead-Formular-Landingpage, das App-Aequivalent. Elido leitet es aus der Ziel-URL des Klick-Datensatzes ab, wenn es nicht ueberschrieben wird; uebergib es explizit im Conversion-POST, wenn deine Bestaetigungs-URL vom Redirect-Ziel abweicht.

Gehashter Key nicht in Kleinbuchstaben und ohne Trim. [email protected] und [email protected] ergeben unterschiedliche SHA-256-Werte. Metas Server hashen die kanonische Form, die in ihrem User-Graph gespeichert ist. Wenn dein Hash nicht passt, landet das Event als nicht gematcht. Die Normalisierungsanforderung gilt auch fuer Telefonnummern: entferne Variationen in der Laendervorwahl-Formatierung, erzwinge E.164. Wenn du ueber Elidos /v1/conversions-Endpoint routest, wird die Normalisierung fuer dich erledigt; du uebergibst rohe E-Mail und Telefonnummer, Elido hasht nach Spec.

action_source-Mismatch. Web-basierte Conversions verwenden "action_source": "website". Mobile-App-Conversions verwenden "app". Wenn du einen Kauf weiterleitest, der in deiner iOS-App passiert ist, aber action_source: "website" sendest, kann Metas Attributionsmodell das Signal verschlechtern. Uebergib "source": "app" im Elido-Conversion-POST fuer App-seitige Events.

fbc fehlt, weil fbclid nicht auf der URL war. Das passiert, wenn die Ziel-URL der Anzeige keine fbclid enthaelt - entweder weil die Kampagne kein "Auto-advanced matching" aktiviert hat, oder weil die URL manuell ohne sie gebaut wurde, oder weil der Nutzer ueber einen Retargeting-Pfad kam, der den Parameter nicht mitgefuehrt hat. Wenn fbc fehlt, wird die Conversion trotzdem weitergeleitet, aber die Match-Rate faellt auf reines E-Mail/Telefon-Niveau. Pruefe die Kampagneneinstellungen im Meta Ads Manager; fbclid sollte fuer Standard-Traffic-Kampagnen auf den Ziel-URLs erscheinen.

Doppelte event_id-Schemata. Das Browser-Pixel und das CAPI-Event verwenden unterschiedliche Formate fuer dieselbe Order-ID. Das passiert fast immer, wenn unterschiedliche Teams die Frontend-Tag-Manager-Konfiguration und die Backend-Bestell-Webhook-Integration verantworten. Einigt euch vor dem Launch auf ein kanonisches Format. Order-ID als String (ord_98231) funktioniert. Nur Numerisch funktioniert auch. Pixel emittiert "ord_98231" und der Server emittiert "98231" werden als unterschiedliche Events behandelt: keines wird dedupliziert.

Ein konkretes Ergebnis#

Eine EU-basierte E-Commerce-Marke, die Meta-Anzeigen nach Deutschland und Oesterreich ausspielt, meldete eine Match-Rate von 38 % bei reinem Pixel-Tracking. Safari auf iOS machte rund 45 % des Seiten-Traffics aus; die ATT-Opt-out-Raten in der Altersgruppe 25-44 lagen bei etwa 72 %.

Nach der Anbindung von CAPI ueber Elido mit em + fbc als primaeren Match-Keys stieg die Match-Rate innerhalb der ersten Woche auf 76 %. fbc war jetzt bei jeder Conversion vorhanden, die aus einem Meta-Anzeigen-Klick stammte (Elido erfasst fbclid auf der Redirect-Ebene, nicht auf Browser-Ebene), und das Weiterleiten der gehashten E-Mail-Adresse lieferte einen zweiten Match-Pfad fuer Conversions, bei denen das _fbp-Cookie abgelaufen war.

Der CPA fiel ueber die folgenden vier Wochen um 18 %. Gemeldete ROAS stieg von 2,1 auf 2,6. Die 18 % CPA-Reduktion reflektiert bessere Attribution, nicht bessere Kampagnen-Performance: die Kampagnen lieferten schon immer 2,6 ROAS; das Pixel allein hat untertrieben gemeldet.

Wo das in der Attributionspipeline sitzt#

CAPI ist ein Kanal in einem breiteren serverseitigen Forwarding-Setup. Die server-side conversion tracking overview deckt GA4 Measurement Protocol und TikTok Events API mit derselben Tiefe ab, die dieser Post auf Meta anwendet. Cookieless attribution explained lohnt sich, wenn du das zugrundeliegende Warum verstehen willst - ITP, Link Tracking Protection und die Verschiebungen im Attributionsmodell, die daraus folgten.

Fuer die Produktoberflaeche: conversion tracking features dokumentiert die vollstaendige API, einschliesslich Refund-Events, Multi-Touch-Attribution-Modi und Retry/Backoff-Semantik. Solutions for marketers zeigt, wie die Teile in einem Kampagnen-Workflow zusammenpassen.

Das oben beschriebene Setup ist an einem Vormittag machbar. Die wesentliche Investition liegt bei der Validierung - 30 Minuten in den Meta Test Events, bevor du produktiven Traffic umlegst. Diese 30 Minuten lohnen sich; die Alternative ist, drei Tage spaeter eine Fehlkonfiguration zu entdecken, wenn der Algorithmus bereits auf falschen Zahlen gehandelt hat.

---

Quellen

• Meta Conversions API: Getting Started. developers.facebook.com/docs/marketing-api/conversions-api/get-started/ (abgerufen am 12.05.2026)
• Meta Conversions API: Deduplicate Pixel and Server Events. developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/ (abgerufen am 12.05.2026)
• Meta Conversions API: Customer Information Parameters. developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/ (abgerufen am 12.05.2026)