Conversions über Elido-Kurzlinks an die Meta CAPI weiterleiten

Metas eigene Empfehlung, veröffentlicht auf der Conversions API getting started page (abgerufen am 12.05.2026), positioniert das Browser-Pixel als Ergänzung zur CAPI, nicht umgekehrt. Diese Verschiebung kam etwa mit iOS 14.5: App Tracking Transparency hat die Signalqualität 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, regelmäßig, 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, zählt Meta die Conversion nur einmal, auch wenn beide Pfade feuern.

Zur Abgrenzung von seinem Pendant: CAPI misst Conversions, während Link-Retargeting das Werbepublikum aufbaut, gegen das du diese Conversions später ausspielst - gleiche Pixel-Familie, entgegengesetzte Enden des Funnels.

Dies ist die Schritt-für-Schritt-Anleitung, um CAPI über 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 größten Teil der Lücke zurück.
• Der Deduplikationsschlüssel - event_id - muss zwischen deinem browserseitigen Pixel und deinem CAPI-Event identisch sein. Wird das verpasst, kommt es zu Doppelzählung, was Metas Budgetallokation für die Optimierung kaputt macht.
• Eine höhere 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 verknüpft es mit jeder späteren 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 füllt.

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 einfügen 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 trägt eine event_source_url, die Meta sagt, auf welcher Seite die Conversion stattgefunden hat. Bei Purchase-Events ist das typischerweise deine Checkout-Bestätigungs-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 zählt

Meta dedupliziert und matcht Server-Events auf Browser-Sessions mithilfe eines Sets an Kundeninformations-Parametern. Je mehr davon du sendest, desto höher die Match-Rate. Höhere 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, führender und nachfolgender Whitespace entfernt, keine Änderungen 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: Ländervorwahl, 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, erhält 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 angehängt 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 für den browserseitigen Fallback-Pfad.

Die praktische Prioritätsreihenfolge: em zuerst (fast immer verfügbar), fbc als zweites (Elido liefert es für click-basierte Conversions), fbp als drittes (auf der Bestätigungsseite 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.

Füge 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 nötigen Scopes fehlen; prüfe die Berechtigungen des System Users, bevor du fortfährst. Sobald validiert, ist die Integration für 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 zuverlässig, unabhängig davon, ob das JavaScript deiner Zielseite überhaupt läuft.

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 vollständige CAPI-Payload zusammen und POSTet an https://graph.facebook.com/v21.0/{pixel_id}/events. Der API-Aufruf gibt sofort eine Conversion-ID zurück; das Fan-out zu Meta läuft im Hintergrund und ist über 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, übergib "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 über 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 müssen dieselbe event_id teilen. Die zuverlässigste 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), während das Backend ein anderes verwendet (order-98231). Beide Events kommen an. Keines wird dedupliziert. Deine gemeldeten Conversions verdoppeln sich. Metas Algorithmus überverteilt Budget an die Kampagne basierend auf aufgeblasenen Zahlen. Das Budget-Review drei Wochen später offenbart "unsere ROAS ist irgendwie 2,5x unseres tatsächlichen 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 Bestätigungsseite lädt. Der serverseitige CAPI-Forward passiert, wenn dein Bestell-Webhook feuert. Beide müssen event_id: ord_98231 (oder was auch immer dein Bestell-Identifier ist) emittieren. Die zeitliche Lücke zwischen den beiden ist irrelevant, solange beide innerhalb von 48 Stunden ankommen.

Wenn du kein browserseitiges Pixel betreibst (entfernt aus GDPR-Consent-Gründen oder weil deine Zielgruppe komplett Ad-Blocker-lastig ist), ist Deduplikation belanglos. Sende ausschließlich CAPI. Aber die meisten Teams fahren beides; das Browser-Pixel liefert ein Fallback-Signal für Nutzer, deren CAPI-Events keine Match-Keys tragen können (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 für den Test-Event-Code. Hol dir einen Code aus dem Meta Events Manager unter Test Events. Füge ihn ein. Solange dieser Code gesetzt ist, wird jedes CAPI-Event, das Elido sendet, ins Test-Panel geroutet - es läuft niemals ins Produktiv-Reporting.

Schritt zwei: Test-Conversion auslösen. 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 angehängt wurde). POSTe eine Conversion gegen diese click_id mit einer realistischen Order-ID, einem Wert und einer E-Mail-Adresse.

Schritt drei: Test Events prüfen. Im Meta Events Manager sollte das Test-Event innerhalb von 30 Sekunden auftauchen. Prüfe, dass der event_name mit dem übereinstimmt, was dein Browser-Pixel sendet. Prüfe, dass die event_id die Order-ID ist und keine UUID. Prüfe, 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 für den Test-Event-Code und speichere. Produktive Events beginnen zu fließen. Das Match-Rate-Dashboard im Events Manager braucht 24 Stunden, bis es sich mit aussagekräftigen Daten füllt.

Worauf du nach 24 Stunden achten solltest: Match-Rate über 60 % ist arbeitsfähig; über 75 % ist gut; über 85 % bedeutet, dass deine Match-Key-Dichte hoch ist und die Attribution zuverlässig 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.

Häufige 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-Bestätigungs-URL, deine Lead-Formular-Landingpage, das App-Äquivalent. Elido leitet es aus der Ziel-URL des Klick-Datensatzes ab, wenn es nicht überschrieben wird; übergib es explizit im Conversion-POST, wenn deine Bestätigungs-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 für Telefonnummern: entferne Variationen in der Ländervorwahl-Formatierung, erzwinge E.164. Wenn du über Elidos /v1/conversions-Endpoint routest, wird die Normalisierung für dich erledigt; du übergibst 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. Übergib "source": "app" im Elido-Conversion-POST für App-seitige Events.

fbc fehlt, weil fbclid nicht auf der URL war. Das passiert, wenn die Ziel-URL der Anzeige keine fbclid enthält - entweder weil die Kampagne kein "Auto-advanced matching" aktiviert hat, oder weil die URL manuell ohne sie gebaut wurde, oder weil der Nutzer über einen Retargeting-Pfad kam, der den Parameter nicht mitgeführt hat. Wenn fbc fehlt, wird die Conversion trotzdem weitergeleitet, aber die Match-Rate fällt auf reines E-Mail/Telefon-Niveau. Prüfe die Kampagneneinstellungen im Meta Ads Manager; fbclid sollte für Standard-Traffic-Kampagnen auf den Ziel-URLs erscheinen.

Doppelte event_id-Schemata. Das Browser-Pixel und das CAPI-Event verwenden unterschiedliche Formate für 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 Österreich 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 über Elido mit em + fbc als primären 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 für Conversions, bei denen das _fbp-Cookie abgelaufen war.

Der CPA fiel über 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.

Für die Produktoberfläche: conversion tracking features dokumentiert die vollständige API, einschließlich 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 später 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)