Conversion API (CAPI)
Eine Conversion API (CAPI) ist eine Server-zu-Server-Schnittstelle, die Marketing-Ereignisse direkt aus Ihrem Backend an eine Werbeplattform wie Meta, TikTok oder Google sendet. Sie umgeht den Browser und liefert vollständigere, zuverlässigere Conversion-Daten.
Das Wichtigste in Kürze
- Jedes Ereignis trägt Namen, Zeitstempel, Aktionsquelle, gehashte Nutzerdaten und ergänzende Wertfelder.
- Die Authentifizierung erfolgt über ein Zugriffstoken des Werbekontos statt über den Browser.
- Jede zusätzliche gehashte Kennung und die gespeicherte Klickkennung erhöhen die Trefferquote.
- Ereignisse außerhalb des Rückdatierungsfensters werden erfasst, beeinflussen die Gebotslogik aber nicht mehr.
- Nicht zugeordnete Ereignisse scheitern lautlos, sodass defekte Integrationen gesund aussehen können.
Im Detail
Über eine Conversion API läuft eine kleine, streng geformte Nutzlast. Jedes Ereignis trägt einen Namen, einen Zeitstempel, eine Aktionsquelle, die angibt, ob es auf einer Website, in einer App, telefonisch oder im Ladengeschäft stattfand, einen Block user_data mit gehashten Kennungen sowie einen Block custom_data mit Wert, Währung und allem Weiteren, das gemeldet werden soll. Der Aufruf wird mit einem Zugriffstoken des Werbekontos authentifiziert, sodass die Plattform Ihrem Server so vertraut wie früher einem Browser-Tag. Fehlt der Token, verwirft die Plattform den Aufruf sofort.
Alles hängt daran, wie viele brauchbare Kennungen Sie mitgeben. Mit SHA-256 gehashte E-Mail-Adressen und Telefonnummern matchen am stärksten; Vorname, Ort, Postleitzahl und Land erhöhen das Gewicht; die beim Landen erfasste Klickkennung und der aus Ihrer Datenbank weitergereichte Cookie-Wert heben die Trefferquote nochmals an. Ebenso wichtig ist das Timing: Plattformen akzeptieren Ereignisse nur innerhalb eines Rückdatierungsfensters, und ein nächtlicher Stapel, der Tage später eintrifft, fällt womöglich aus dem Attributionsfenster und beeinflusst die Gebote nie. Planen Sie den Versand deshalb ereignisnah statt nach Zeitplan.
Der natürliche Einsatz ist das Melden jener Ereignisse, die der Browser nicht kennen kann. Ein CRM-Webhook feuert, sobald ein Deal auf vertrieblich angenommen wechselt, und Ihr Dienst sendet diesen Phasenwechsel mit der ursprünglich gespeicherten Klickkennung. Telefonbuchungen und Ladenverkäufe laufen mit passender Aktionsquelle denselben Weg. In einem Scorecard-Funnel entsteht die Bewertung erst nach dem Absenden, weshalb das qualifizierte Ereignis samt Stufe als Wert aus dem Backend stammt und nicht aus einer Dankeseiten-URL abgeleitet wird. Der Wert stammt dann aus derselben Quelle wie die Bewertung selbst.
Ein Ereignis mit schwachen Kennungen wird nicht laut abgelehnt, sondern angenommen, nicht zugeordnet und still aus der Berichterstattung genommen. Genau deshalb halten Teams eine Integration für funktionierend, während die Hälfte davon wirkungslos bleibt. Die Schnittstelle kann auch keine Identität erzeugen, wo keine existiert: Traffic ohne Anzeigenklick hat nichts, dem er zugeordnet werden könnte. Und ein tiefes Funnel-Ereignis, das nur wenige Male pro Woche auftritt, ist für die Optimierung der Plattform oft schlicht zu selten. Beide Grenzen lassen sich mit besseren Daten nicht wegkonfigurieren.
Beispiel aus der Praxis
So wird es gemessen
Beginnen Sie mit der Diagnose der Plattform. Jede größere Umsetzung bietet ein Testereignis-Werkzeug, das die geparsten Felder zurückspiegelt, einen Qualitätsindikator je Ereignis sowie eine Warnliste für fehlende oder fehlerhafte Parameter. Senden Sie eine Testconversion für einen Kontakt, den Sie identifizieren können, prüfen Sie die erwarteten Felder und kontrollieren Sie in der Folgewoche den Anteil der als nicht zugeordnet markierten Produktivereignisse.
Messen Sie danach das Ergebnis statt der Technik. Vergleichen Sie die von der Plattform gemeldeten Conversions mit denselben Ereignissen in Ihrer Datenbank im gleichen Zeitraum und verfolgen Sie das Verhältnis, während Sie Kennungen ergänzen. Achten Sie auch auf die Auslieferung: Nach dem Umstellen der Optimierung auf ein serverseitig gemeldetes Ereignis zeigen dessen Kosten und die Zahl akzeptierter Leads gemeinsam, ob das reichere Signal den Einkauf wirklich verbessert hat.
Häufige Fehler
Der häufigste technische Fehler ist schlechte Normalisierung vor dem Hashen. Plattformen erwarten kleingeschriebene, bereinigte Werte in einem definierten Format; eine Telefonnummer mit Leerzeichen oder uneinheitlicher Ländervorwahl ergibt einen Hash, der niemals passt. Folgen Sie den Normalisierungsregeln der Plattform exakt und testen Sie mit einem bekannten Kontakt, dessen Datensatz Sie prüfen können. Ein bereits gehashter Wert, der ein zweites Mal gehasht wird, scheitert genauso still und schleicht sich leicht bei Umbauten ein.
Der zweite Fehler ist die Wahl eines Ereignisses, das niemanden im Vertrieb interessiert. Teams bauen die Schnittstelle in einer Woche, senden jeden Seitenaufruf serverseitig und optimieren am Ende auf dieselbe flache Aktion wie zuvor, nur zuverlässiger. Entscheiden Sie, welches einzelne Ereignis den Umsatz am besten vorhersagt, senden Sie dieses mit einem Wert und behalten Sie den Rest für Berichte. Aus einer manuell gesetzten CRM-Phase gefeuerte Conversions bringen zudem Verzögerung und Verzerrung ins Signal.
Häufig gestellte Fragen
Wie unterscheidet sich CAPI von server-seitigem Tracking?
Server-seitiges Tracking ist der allgemeine Ansatz, Ereignisse auf Ihrem Server zu erfassen. CAPI ist eine konkrete Plattform-Schnittstelle, etwa von Meta oder TikTok, die diese Server-Ereignisse empfängt und somit ein Ziel des Setups ist.
Warum muss ich gehashte Kennungen an CAPI senden?
Durch das Hashen von E-Mail oder Telefonnummer kann die Plattform eine Conversion einem Nutzer zuordnen, ohne Rohdaten offenzulegen. Das verbessert die Trefferquote und schützt die Daten beim Transport.
Kann CAPI meine Conversions doppelt zählen?
Ja, wenn Pixel und CAPI dasselbe Ereignis ohne gemeinsame event_id melden. Setzen Sie immer eine konsistente event_id, damit die Plattform dedupliziert und jede Conversion nur einmal zählt.
Ist eine Conversion API dasselbe wie server-seitiges Tracking?
Nicht ganz. Server-seitiges Tracking beschreibt das Erfassen von Ereignissen auf eigener Infrastruktur, während eine Conversion API der Server-zu-Server-Endpunkt einer einzelnen Werbeplattform für deren Entgegennahme ist. Sie können eine Conversion API direkt aus Ihrer Anwendung aufrufen, ganz ohne Container, und Sie können serverseitig erfassen und an Analysewerkzeuge weiterleiten, die überhaupt keine solche Schnittstelle anbieten.
Welche Daten muss ich für eine gute Zuordnung senden?
Gehashte E-Mail-Adresse und Telefonnummer leisten den größten Beitrag, gefolgt von Vorname, Nachname, Ort, Postleitzahl und Land. Haben Sie die Klickkennung aus der Landing-URL und den Cookie-Wert der Plattform gespeichert, senden Sie beides mit, denn sie matchen ohne personenbezogene Daten. Mehr korrekt formatierte Felder ergeben verlässlich eine höhere Trefferquote.
Wie spät darf eine Conversion gesendet werden?
Jede Plattform definiert ein Rückdatierungsfenster von meist wenigen Tagen, danach wird ein Ereignis abgewiesen. Angenommen zu werden heißt aber nicht, nützlich zu sein: Ein Ereignis nach Schließen des Attributionsfensters wird der auslösenden Anzeigeninteraktion nicht mehr gutgeschrieben. Senden Sie Offline-Conversions daher sofort beim Anlegen des Datensatzes und nicht im Wochenstapel.
Brauche ich Pixel und Conversion API gleichzeitig?
Für Web-Ereignisse ist der Parallelbetrieb das empfohlene Muster. Das Browser-Tag liefert Signale, die der Server nicht sieht, die Schnittstelle deckt die vom Browser verlorenen Ereignisse ab, und die Deduplizierung über eine gemeinsame Ereignis-ID verhindert Doppelzählung. Bei echten Offline-Ereignissen wie einem Telefonverkauf gibt es keine Browserseite, dort bleibt die Schnittstelle der einzige Weg.
Verstößt die Conversion API gegen Datenschutzrecht?
Von sich aus nicht, sie befreit Sie aber auch von nichts. Sie senden personenbezogene Daten an eine Werbeplattform und benötigen dafür eine Rechtsgrundlage, transparente Information und die Beachtung widerrufener Einwilligungen. Hashing verringert die Preisgabe, macht Daten jedoch nicht anonym, da die Plattform genau auf diesen Hashes matcht. Unterdrücken Sie Ereignisse widersprechender Personen aktiv, statt auf plattformseitige Filter zu hoffen.
Warum sind meine Conversion-Zahlen nach Aktivierung gesunken?
Meist weil die Deduplizierung nun greift. Vorher meldete ein Weg, danach melden zwei, und die Plattform fasst passende Paare zu einer Conversion zusammen, was eine zuvor überhöhte Zahl korrigiert. Rückgänge entstehen auch durch strengere Zuordnungsanforderungen, denn Ereignisse ohne brauchbare Kennungen werden verworfen statt gezählt zu werden wie zuvor beim Browser-Tag.