CAPI (Conversions API)

Was CAPI macht

Der Meta Pixel läuft im Browser und feuert Conversion-Events an Meta. CAPI macht dasselbe, aber von deinem Server, nachdem der Browser geladen hat.

Die Pipeline:

1. Der Nutzer schließt auf deiner Website einen Kauf ab
2. Dein Server erfasst die Bestellung
3. Dein Server sendet ein CAPI-Event mit den Conversion-Daten an Meta
4. Meta nutzt die Daten, um die Conversion zuzuordnen und seinen Optimierungsalgorithmus zu füttern

Weil der Call Server-zu-Server läuft, kann er nicht von Ad-Blockern blockiert, von ITP kaputtgemacht oder dadurch unterbrochen werden, dass der Nutzer den Tab schließt, bevor der Pixel feuert. Außerdem trägt er reichere First-Party-Daten, als der Pixel es kann.

Warum CAPI 2026 zählt

Pixel-only-Conversion-Tracking hat stetig an Qualität verloren:

• Ad-Blocker-Verbreitung in DTC-Branchen liegt oft bei 30 bis 40 %
• Safari mit ITP entfernt First-Party-Cookies, die von clientseitigen Skripten gesetzt werden
• iOS App Tracking Transparency schränkt die Attribution in Mobile-Apps ein
• Consent-Ablehnungen verhindern in EU-Märkten, dass der Pixel überhaupt lädt

Der kombinierte Effekt: Pixel-only-Setups verlieren einen erheblichen Teil der Conversions. Metas Algorithmus trifft Entscheidungen auf Basis dieser unvollständigen Daten, weshalb Pixel-only-Accounts über die Zeit oft stagnieren oder zurückfallen.

CAPI stellt die fehlenden Events wieder her. Mit ausgerolltem CAPI sieht Meta nahezu alle Conversions, der Algorithmus optimiert auf ein vollständiges Bild, und der berichtete ROAS liegt viel näher an der Blended-Realität.

CAPI ohne Server-Side-Tracking ist nur die halbe Lösung

Ein häufiges Anti-Pattern: CAPI über eine „Browser-to-CAPI“-Middleware ausrollen (oft ein Google-Tag-Manager-Server-Container), die trotzdem davon abhängt, dass der Browser-Pixel feuert. Das behebt nichts, feuerte der Pixel nicht (Ad-Blocker, ITP), feuert auch CAPI nicht.

Echten CAPI-Wert bekommst du, wenn das Event serverseitig in deinem eigenen Backend erzeugt wird, mit vollem First-Party-Kontext, und an Meta weitergeleitet wird, ohne je von einem Skript im Browser abzuhängen.

Event-ID-Deduplizierung

Wenn sowohl der Pixel als auch CAPI für dieselbe Conversion feuern, muss Meta wissen, dass es Duplikate sind. Jedes Event trägt eine event_id, die über beide Kanäle identisch ist. Meta behält eines und verwirft das andere.

Das ist Pflicht, ohne Event-IDs zählst du jede Conversion doppelt, die beide Pipelines erfolgreich melden.

Andere „CAPIs“

Das CAPI-Muster hat sich über Meta hinaus verbreitet:

• Google Enhanced Conversions, dieselbe Idee, gehashte First-Party-Daten serverseitig weitergeleitet
• TikTok Events API, TikToks Entsprechung
• Pinterest Conversions API, gleicher Name, Pinterests Pipeline
• Snapchat Conversions API, wieder derselbe Name

Die meisten modernen Tracking-Stacks schicken dieselbe Conversion parallel an alle.

Häufige Fehler

• Event-IDs weglassen. Doppeltes Zählen zerstört das ROAS-Reporting.
• PII ohne Hashing senden. E-Mail und Telefonnummer müssen vor dem Weiterleiten mit SHA-256 gehasht werden.
• CAPI als das Einzige behandeln. CAPI ohne Server-Side-Tracking hängt weiterhin vom Browser-Pixel als Auslöser ab.

FAQ zu CAPI (Conversions API)

Was ist Meta CAPI?

CAPI (Conversions API) ist Metas serverseitige API, um Conversion-Events direkt von deinem Server an Meta zu senden und den Browser-Pixel zu umgehen. Sie holt Conversions zurück, die durch Ad-Blocker und ITP verloren gehen.

Brauche ich CAPI, wenn ich den Meta Pixel habe?

Ja. Der Pixel allein verpasst 2026 30 bis 40 % der Conversions. CAPI läuft parallel dazu (mit Event-ID-Deduplizierung), um die Events zu erfassen, die der Pixel nicht erreicht.

Was ist der Unterschied zwischen CAPI und Server-Side-Tracking?

CAPI ist eine bestimmte serverseitige Conversion-API (die von Meta). Server-Side-Tracking ist das breitere Architekturmuster. CAPI ohne echtes Server-Side-Tracking, also nur Browser-Events über einen Proxy weiterzuleiten, löst das Problem des Datenverlusts nicht wirklich.