Meta Conversions API (CAPI) einrichten
Der Facebook-Pixel im Browser verliert heute einen großen Teil deiner Conversions: an Adblocker, an die Tracking-Prevention der Browser und an Nutzer, die dem Tracking nicht zustimmen. Die Meta Conversions API meldet Conversion-Events stattdessen serverseitig, direkt von deinem Backend an Meta, und füllt damit einen Teil der Lücke wieder auf. Der Standard ist heute nicht Pixel oder CAPI, sondern beide zusammen, sauber dedupliziert. Dieser Artikel zeigt, was CAPI technisch ist, wie das Setup abläuft, warum die Deduplizierung Pflicht ist und was CAPI ausdrücklich nicht löst.
Worum es geht, und warum der Pixel allein nicht mehr reicht
Lange war der Facebook-Pixel der einzige Weg, Käufe und andere Conversions an Meta zu melden. Der Pixel ist ein Stück JavaScript, das im Browser des Nutzers läuft und beim Kauf ein Event an Meta sendet. Solange der Browser dieses Skript ausführt und der Request durchgeht, funktioniert das gut. Genau diese Voraussetzung ist heute aber nicht mehr verlässlich gegeben.
Drei Entwicklungen reißen Löcher in den Pixel. Adblocker und Browser-Erweiterungen blockieren Tracking-Skripte, oft genau die von Meta. Die Tracking-Prevention der Browser, allen voran ITP in Safari, verkürzt oder löscht die Cookies, auf die der Pixel angewiesen ist. Und ein wachsender Teil der Nutzer lehnt das Tracking im Consent-Banner ab oder ignoriert es, sodass der Pixel gar nicht erst feuern darf. Jede dieser drei Lücken kostet dich Events, und alle drei werden eher größer als kleiner.
Hier setzt die Conversions API an. CAPI sendet das Conversion-Event nicht aus dem Browser, sondern Server-zu-Server: Dein Backend übergibt das Event direkt an Meta. Ein Adblocker im Browser kann diesen Weg nicht blockieren, und auch die Cookie-Restriktionen der Browser greifen hier anders. CAPI ersetzt den Pixel aber nicht, sondern ergänzt ihn. Der Pixel liefert weiterhin Signale aus dem Browser, die der Server nicht hat. Deshalb ist der heute übliche Aufbau Pixel und CAPI gemeinsam, und damit dieselbe Conversion nicht doppelt zählt, müssen beide dedupliziert werden.
Zurück zum Überblick: Server-Side Tracking, der vollständige Leitfaden. Im Glossar: Conversion API, Pixel.
Was die Conversions API technisch ist
Im Kern ist CAPI eine Schnittstelle, an die dein Server Conversion-Events als Server-zu-Server-Request schickt. Ziel ist die Graph-Schnittstelle von Meta, an die du pro Ereignis ein strukturiertes Event übergibst. Authentifiziert wird das über die Pixel-ID, die als Dataset-ID auch für CAPI gilt, und ein dafür erzeugtes Zugriffstoken. Mehr braucht es technisch nicht, um Events anzunehmen.
Wie ein Event aufgebaut ist
Ein CAPI-Event ist ein klar gegliedertes Datenpaket. Es enthält mindestens den event_name, also die Art des Ereignisses wie Purchase oder Lead, und die event_time, den Zeitstempel des Ereignisses. Dazu kommen zwei Blöcke: user_data mit Informationen über den Nutzer und custom_data mit Informationen über das Ereignis, etwa Wert und Währung eines Kaufs. Die user_data werden nicht im Klartext übergeben, sondern vorab gehasht, sodass Meta sie zur Zuordnung nutzen kann, ohne sie im Klartext zu erhalten.
Wie die Zuordnung funktioniert
Damit Meta ein serverseitig gemeldetes Event einem Klick oder einer Anzeige zuordnen kann, braucht es Anhaltspunkte über den Nutzer. Das sind die gehashten Identifier in den user_data: eine mit SHA-256 gehashte E-Mail-Adresse, eine gehashte Telefonnummer, dazu die Meta-Cookies fbp und fbc, die der Browser kennt und die du an den Server durchreichst. Je mehr verlässliche Identifier ein Event mitbringt, desto besser die Zuordnung. Meta drückt das in der Event Match Quality aus, auf die ein eigener Abschnitt weiter unten eingeht.
Wichtig ist eine ehrliche Einordnung: CAPI ist keine magische Datenschutz-Lösung. Die Schnittstelle sendet personenbezogene Daten an Meta, auch wenn diese gehasht sind, und ein Hash einer E-Mail bleibt rechtlich ein personenbezogenes Datum. Der serverseitige Weg ändert nichts daran, dass diese Übermittlung eine Einwilligung voraussetzt. CAPI löst ein technisches Mess-Problem, kein rechtliches. Wer das verwechselt, baut sich ein Compliance-Risiko ein, das später teuer wird.
Im Glossar: Hashing, Conversion API. Im Produkt: Server-Side Tracking in DataFirst Track.
Pixel und CAPI zusammen, ohne doppelt zu zählen
Wenn Pixel und CAPI parallel laufen, meldet derselbe Kauf zwei Wege an Meta: einmal aus dem Browser über den Pixel, einmal vom Server über CAPI. Das ist gewollt, denn so kommt das Event auch dann an, wenn einer der beiden Wege blockiert ist. Ohne weitere Vorkehrung würde Meta aber beide Signale als zwei Käufe zählen. Genau das verhindert die Deduplizierung.
Der gemeinsame Schlüssel: event_id und event_name
Die Deduplizierung läuft über zwei Felder, die auf beiden Wegen identisch sein müssen: den event_name und die event_id. Feuern Pixel und CAPI für denselben Kauf mit demselben event_name, etwa Purchase, und derselben event_id, erkennt Meta die beiden als ein und dasselbe Ereignis und zählt es nur einmal. Als event_id eignet sich fast immer deine Bestell- oder Transaktions-ID, weil sie pro Kauf eindeutig ist und auf beiden Wegen verfügbar sein muss. Entscheidend ist, dass sie wirklich identisch erzeugt wird, nicht zweimal unabhängig.
Was passiert, wenn du die Deduplizierung auslässt
Fehlt die gemeinsame event_id, oder weichen die Event-Namen voneinander ab, zählt Meta jeden Kauf doppelt. Die Folgen sind nicht nur ein zu schönes Reporting. Ein kleines Muster: Melden Pixel und CAPI jeweils 100 Käufe pro Tag und überschneiden sich die Wege bei 60 davon, stehen ohne Deduplizierung 160 Käufe in der Statistik statt der echten 100. Die Zahlen sind illustrativ gewählt, das Muster aber ist real. Auf dieser aufgeblähten Basis optimiert das Smart Bidding von Meta falsch, weil es Conversions sieht, die es so nicht gibt, und dein ROAS im Bericht hat mit der Realität wenig zu tun. Eine fehlende Deduplizierung ist deshalb kein kosmetisches Problem, sondern eine verzerrte Steuerungsgrundlage.
Tiefer: Event-Deduplizierung: Pixel und CAPI sauber trennen. Im Glossar: Deduplizierung, Pixel.
CAPI einrichten: die Schritte
Das Setup folgt einer festen Reihenfolge. Jeder Schritt baut auf dem vorigen auf, und wer einen überspringt, merkt es spätestens beim Testen. Die folgende Sequenz geht vom häufigsten Fall aus: ein bestehender Pixel, der um CAPI ergänzt werden soll.
Schritt 1: Datenquelle, Pixel-ID und Zugriffstoken bereitstellen
Im Meta Events Manager legst du die Datenquelle an oder nutzt die bestehende. Die Pixel-ID dieser Quelle gilt als Dataset-ID zugleich für CAPI, Pixel und Server senden also auf dieselbe Quelle. Dort erzeugst du ein Zugriffstoken für die Conversions API. Mit Pixel-ID und Token darf dein Server Events an die Graph-Schnittstelle senden. Das Token gehört in eine sichere Konfiguration, nicht in den Quelltext im Browser.
Schritt 2: Server-Container oder Backend-Integration wählen
Jetzt entscheidet sich, von wo die Events tatsächlich abgehen. Drei Wege sind üblich: ein Server-Side-GTM-Container, der das Mapping übernimmt und sich auch für andere Plattformen nutzen lässt, eine offizielle Shop-Integration, etwa für gängige Shop-Systeme, oder ein eigener Server-Endpoint, der die Graph-Schnittstelle direkt anspricht. Welcher Weg passt, hängt von deinem Stack ab und davon, ob du eine zentrale Schicht für mehrere Plattformen willst oder nur Meta anbindest.
Schritt 3: Events mappen inklusive event_id und gehashten user_data
Nun bildest du jedes relevante Ereignis auf ein CAPI-Event ab. Pro Event gehören dazu der event_name, die event_time, die verfügbaren user_data und die custom_data wie Wert und Währung. E-Mail und Telefonnummer werden vor dem Versand mit SHA-256 gehasht, die Cookies fbp und fbc reichst du aus dem Browser an den Server durch. Jedem Event gibst du eine eindeutige event_id, in der Regel die Bestell-ID. Dieser Schritt ist die Hauptarbeit, weil hier die Datenqualität entsteht, die später über die Match-Quality entscheidet.
Schritt 4: Pixel- und CAPI-Events deduplizieren
Damit kein Kauf doppelt zählt, müssen Pixel und CAPI für dasselbe Ereignis denselben event_name und dieselbe event_id senden. Das klingt trivial, ist in der Praxis aber die häufigste Fehlerquelle, weil die event_id auf beiden Wegen oft unabhängig erzeugt wird und dann eben nicht identisch ist. Prüfe gezielt, dass der Pixel im Browser und das Server-Event wirklich dieselbe ID tragen, idealerweise dieselbe Bestell-ID aus einer Quelle.
Schritt 5: Im Events Manager testen und Match-Quality prüfen
Zum Schluss kontrollierst du das Ergebnis. Das Test-Events-Werkzeug im Events Manager zeigt eintreffende CAPI-Events live an. Hier siehst du, ob die Events ankommen und ob Pixel und CAPI als dedupliziert markiert werden. Erscheint ein Kauf zweimal ohne Dedup-Markierung, stimmt etwas mit der event_id nicht. Danach prüfst du die Event Match Quality je Event und ergänzt fehlende Identifier, solange dafür Consent vorliegt. Erst wenn Deduplizierung und Match-Quality stimmen, ist das Setup wirklich produktiv.
Die betreute Variante: Meta Conversions API als Lösung. Allgemeiner: Conversion-Tracking. Im Glossar: Hashing.
Match-Quality und Datenqualität verbessern
Ob ein serverseitig gemeldetes Event etwas bringt, hängt davon ab, ob Meta es einem Nutzer zuordnen kann. Genau das misst die Event Match Quality. Sie ist kein Performance-Wert, sondern ein Datenqualitäts-Indikator: Sie sagt dir, wie gut die übergebenen Identifier zu einem Meta-Konto passen. Je höher die Match-Quality, desto mehr deiner Conversions lassen sich tatsächlich zuordnen, und desto besser sind Reporting und Gebotssteuerung.
Der wirksamste Hebel ist die Menge und Verlässlichkeit der first-party Identifier, die du mitschickst. Eine korrekt gehashte E-Mail-Adresse ist der stärkste einzelne Identifier, eine gehashte Telefonnummer ergänzt sie. Dazu kommen die Meta-Cookies fbp und fbc: fbp identifiziert den Browser, fbc trägt die Klick-Information aus dem fbclid-Parameter und ist gerade für die Zuordnung zu einer konkreten Anzeige wertvoll. Wer diese Felder vollständig und sauber übergibt, hebt die Match-Quality spürbar gegenüber einem Event, das nur eine E-Mail kennt.
Worauf du beim Hashing achten musst
Gehashte Identifier helfen nur, wenn das Hashing korrekt vorbereitet ist. E-Mail-Adressen müssen vor dem Hashen normalisiert werden, also klein geschrieben und ohne führende oder nachfolgende Leerzeichen, sonst erzeugen dieselbe Adresse in unterschiedlicher Schreibweise unterschiedliche Hashes und der Treffer geht verloren. Telefonnummern gehören ins internationale Format. Ein falsch normalisierter Identifier ist kein besserer als gar keiner, er kostet nur Arbeit, ohne die Match-Quality zu heben.
Bei aller Optimierung bleibt eine Grenze, die ehrlich genannt gehört: Jeder dieser Identifier ist an Consent gebunden. Ohne Einwilligung darfst du E-Mail, Telefonnummer und die Cookies nicht an Meta übergeben, und damit sinkt die Match-Quality zwangsläufig. Es gibt hier einen echten Zielkonflikt zwischen Datenqualität und Datenschutz, und der lässt sich nicht wegoptimieren. Seriös ist, die Match-Quality innerhalb dessen zu maximieren, wofür Consent vorliegt, und nicht den Consent zu umgehen, um die Zahl zu schönen.
Verwandt im Google-Kosmos: Enhanced Conversions in Google Ads. Im Glossar: Hashing, Conversion API.
Was CAPI nicht löst
CAPI ist ein gutes Werkzeug für ein klar umrissenes Problem: Es bringt Conversion-Events zuverlässiger zu Meta. Es wird in der Vermarktung aber gern größer gemacht, als es ist. Zwei Missverständnisse halten sich besonders hartnäckig, und beide kosten dich Geld oder Rechtssicherheit, wenn du ihnen aufsitzt.
CAPI ist kein Ersatz für Consent
Der häufigste Irrtum lautet, serverseitiges Tracking brauche keine Einwilligung, weil der Server den Cookie-Banner ja nicht sehe. Das ist falsch. Maßgeblich ist nicht, wo der Code läuft, sondern ob personenbezogene Daten verarbeitet und an einen Dritten übermittelt werden, und genau das tut CAPI. TTDSG, beziehungsweise das heutige TDDDG, und die DSGVO gelten unabhängig davon, ob das Event aus dem Browser oder vom Server kommt. Wer CAPI-Events ohne Consent sendet, verlagert das Tracking nur an einen Ort, an dem es schwerer zu prüfen ist, und handelt sich dasselbe Datenschutz-Problem ein wie ein Pixel ohne Einwilligung.
CAPI liefert keine unabhängige Attributions-Wahrheit
Der zweite Irrtum ist subtiler. CAPI verbessert, welche Daten bei Meta ankommen, aber Meta wertet diese Daten weiterhin in seinem eigenen Walled Garden aus und schreibt sich Conversions nach seinen eigenen Attributionsregeln zu. Mehr und bessere Events ändern nichts daran, dass Meta tendenziell sich selbst gut aussehen lässt. Die Zahl in deinem Ads-Manager ist Metas Sicht auf deinen Erfolg, nicht eine neutrale. Wer wissen will, welchen Beitrag Meta neben Google und den anderen Kanälen wirklich leistet, braucht eine Messung, die nicht der Plattform selbst gehört.
Das ist kein Argument gegen CAPI, im Gegenteil: Saubere, dedizierte und einwilligungskonforme Events sind die Voraussetzung für jede vernünftige Auswertung. Der Punkt ist ein anderer: CAPI ist ein Baustein der Datenerfassung, nicht das Schlusswort der Bewertung. Die Bewertung gehört auf eine unabhängige Schicht, die alle Kanäle nach denselben Regeln betrachtet.
Unabhängig messen: Attribution in Google Ads und Meta vs. unabhängige Messung. Das Tracking-Fundament: GA4 server-side.
Häufige Fragen zur Meta Conversions API
Was ist die Meta Conversions API?
Die Meta Conversions API, kurz CAPI, ist eine serverseitige Schnittstelle, über die du Conversion-Events direkt von deinem Backend an Meta meldest, statt sie allein vom Browser-Pixel senden zu lassen. Ein Event wie ein Kauf wird dabei als Server-zu-Server-Request an die Graph-Schnittstelle von Meta übergeben, mit dem Event-Namen, dem Zeitstempel und gehashten Nutzer-Identifiern. Weil dieser Weg nicht im Browser läuft, umgeht er Adblocker und einen Teil der Browser-Restriktionen. Der Pixel verschwindet dadurch nicht, beide laufen in der Regel parallel.
Brauche ich CAPI zusätzlich zum Pixel?
In den meisten Fällen ja. Der Browser-Pixel allein verliert heute einen spürbaren Teil der Events an Adblocker, an die Tracking-Prevention der Browser und an Nutzer, die dem Tracking nicht zustimmen. CAPI füllt diese Lücke serverseitig wieder auf, ersetzt den Pixel aber nicht vollständig, weil der Pixel weiterhin Signale wie das Surfverhalten im Browser liefert. Der von Meta empfohlene und in der Praxis übliche Aufbau ist deshalb Pixel und CAPI gemeinsam, mit sauberer Deduplizierung. Ohne Deduplizierung würdest du dieselbe Conversion doppelt zählen.
Wie funktioniert die Event-Deduplizierung zwischen Pixel und CAPI?
Du gibst demselben Ereignis auf beiden Wegen dieselbe Kennung mit: denselben Event-Namen und dieselbe event_id. Feuert für einen Kauf sowohl der Pixel als auch das CAPI-Event mit identischem event_name und identischer event_id, erkennt Meta die beiden als ein und dasselbe Ereignis und zählt es nur einmal. Die event_id ist dabei meistens deine Bestell- oder Transaktions-ID, weil sie pro Kauf eindeutig ist und auf beiden Wegen identisch verfügbar sein muss. Fehlt die event_id auf einem der beiden Wege, kann Meta nicht deduplizieren, und die Conversion wird doppelt gezählt.
Ist die Conversions API DSGVO-konform?
Sie kann es sein, aber sie ist es nicht automatisch. CAPI sendet personenbezogene Daten an Meta, auch wenn diese vor dem Versand gehasht werden, denn ein Hash einer E-Mail bleibt rechtlich ein personenbezogenes Datum. Deshalb gilt für CAPI dieselbe Voraussetzung wie für den Pixel: Es braucht eine wirksame Einwilligung des Nutzers, bevor Identifier übermittelt werden. Wer CAPI-Events ungefiltert serverseitig sendet, weil der Server den Cookie-Banner nicht sieht, umgeht den Consent und handelt sich ein Datenschutz-Problem ein. Serverseitig heißt nicht einwilligungsfrei.
Was ist Event Match Quality?
Event Match Quality ist eine Bewertung von Meta dafür, wie gut sich die mit einem Event übergebenen Nutzer-Daten einem Meta-Konto zuordnen lassen. Je mehr verlässliche, korrekt gehashte Identifier du mitschickst, etwa E-Mail, Telefonnummer und die Meta-Cookies fbp und fbc, desto höher fällt die Bewertung aus. Eine höhere Match-Quality bedeutet, dass mehr deiner Conversions tatsächlich einem Klick oder einer Anzeige zugeordnet werden können, was Reporting und Gebotssteuerung verbessert. Die Bewertung ist ein Datenqualitäts-Indikator, kein Performance-Versprechen.
Brauche ich Server-Side GTM für CAPI?
Nein, zwingend ist es nicht. Ein Server-Side-GTM-Container ist ein verbreiteter und bequemer Weg, CAPI anzubinden, weil er das Mapping der Events übernimmt und sich neben Meta auch für andere Plattformen nutzen lässt. Genauso kannst du CAPI aber direkt aus deinem Shop-Backend ansprechen, etwa über eine offizielle Integration oder einen eigenen Server-Endpoint, der die Events an die Graph-Schnittstelle sendet. Welcher Weg passt, hängt von deinem Stack, deinem Datenfluss und davon ab, ob du eine zentrale Schicht für mehrere Plattformen willst.