Ein Online-Shop schaltet Meta-Anzeigen und sieht im Werbeanzeigenmanager deutlich weniger Käufe, als tatsächlich über die eigene Website abgeschlossen wurden. Auf der Suche nach einer Erklärung stößt das Marketing-Team auf den Begriff „Conversions API“, findet in Metas eigener Dokumentation aber vor allem Setup-Anleitungen für Entwickler und wenig verständliche Erklärung dafür, was im Hintergrund eigentlich passiert. Genau diese Lücke schließt dieser Beitrag mit einer technischen Erklärung: wie die Meta Conversions API (CAPI) tatsächlich funktioniert, welche Rolle sie neben dem Meta-Pixel übernimmt, und wo ihre Grenzen liegen.
Was die Meta Conversions API technisch macht
Der Meta-Pixel misst ein Ereignis wie einen Kauf im Browser des Besuchers und sendet es von dort direkt an Meta. Die Conversions API verlagert diesen Versand auf einen Server: Statt dass der Browser das Ereignis meldet, sendet das eigene Backend, ein Server-Side-Tracking-Container oder eine andere serverseitige Instanz dieselbe Information als sogenanntes Server-Event direkt an Metas API-Endpunkt. Laut Metas eigener Dokumentation für Entwickler werden Server-Events dabei keineswegs als exotischer Sonderfall behandelt: „Server events are linked to a dataset ID and are processed like events sent using the Meta Pixel, Facebook SDK for iOS or Android, mobile measurement partner SDK, offline event set, or .csv upload.“ Ein Server-Event landet also in derselben Verarbeitungspipeline und im selben Werbekonto wie ein Pixel-Event, eine App-Messung oder ein hochgeladener Offline-Datensatz.
Der Vorteil dieser Verlagerung liegt darin, wo die Übertragung stattfindet: Ein Browser-Ereignis kann durch Werbeblocker, das Schließen des Tabs vor dem Laden des Pixel-Skripts oder Cookie-Restriktionen von Safari und Firefox unterwegs verloren gehen. Ein Server-Event verlässt dagegen die eigene Infrastruktur, bevor eine dieser Hürden überhaupt greifen kann. Die Conversions API ist damit kein Ersatzsystem für den Pixel, sondern ein zweiter, robusterer Übertragungsweg für dieselben Ereignisse, der in aller Regel parallel zum Pixel läuft, nicht anstelle davon.
Warum Pixel und Server-Events dasselbe Ereignis doppelt melden können
Laufen Pixel und Conversions API parallel, entsteht ein neues Problem: Ein einzelner Kauf kann als Browser-Ereignis vom Pixel und zusätzlich als Server-Event von der Conversions API bei Meta ankommen, im schlimmsten Fall gezählt als zwei getrennte Conversions statt einer. Meta selbst benennt dieses Risiko unmissverständlich, Unternehmen mit redundantem Setup müssten „eine Deduplizierungsmethode einrichten, um sicherzustellen, dass das Anzeigenauslieferungssystem zwischen unterschiedlichen und überlappenden Ereignissen differenzieren kann“.
Die von Meta empfohlene und in der Praxis übliche Lösung setzt an zwei Feldern an, die Pixel und Conversions API für dasselbe Ereignis identisch mitschicken: „Die eventID des Meta Pixel muss der event_id der Conversions API entsprechen“ und „Das event des Meta Pixel muss dem event_name der Conversions API entsprechen“, wie Meta die Regel selbst formuliert. Erst wenn beide Werte auf beiden Wegen übereinstimmen, erkennt das System zwei Meldungen als ein und dasselbe Ereignis. Diese Prüfung läuft dabei nicht unbegrenzt: „Ereignisse werden nur dedupliziert, wenn sie innerhalb von 48 Stunden nach Erhalt des ersten Ereignisses mit einer bestimmten event_id empfangen werden.“ Kommt das Server-Event mehr als zwei Tage nach dem Pixel-Event an, greift die Deduplizierung nicht mehr. Unterscheiden sich die beiden Meldungen inhaltlich kaum, gilt außerdem eine klare Reihenfolge: „Wenn Server- und Browser-Ereignisse sich inhaltlich nicht wesentlich unterscheiden, bevorzugen wir im Allgemeinen das zuerst empfangene Ereignis.“ In der Praxis heißt das: Wer eine Conversions API einrichtet, ohne beim Pixel-Event dieselbe event_id zu erzeugen und mitzusenden, riskiert doppelt gezählte Conversions statt zusätzlich gesicherter Daten.
Welche Nutzerdaten übertragen werden und warum nicht alles gehasht wird
Damit Meta ein Server-Event überhaupt einer Person im eigenen System zuordnen kann, enthält jedes Ereignis ein user_data-Objekt mit Identifikatoren wie E-Mail-Adresse, Telefonnummer, Vor- und Nachname oder einer externen Kunden-ID. Ein verbreitetes Missverständnis lautet, dabei würde grundsätzlich „alles gehasht“. Tatsächlich gilt laut Metas Parameter-Dokumentation eine feldspezifische Regel, bei der jedes Datenfeld zunächst nach eigener Vorschrift normalisiert wird, bevor der SHA-256-Hash gebildet wird. Bei der E-Mail-Adresse etwa gilt: „Trim any leading and trailing spaces. Convert all characters to lowercase.“ Bei der Telefonnummer lautet die Vorschrift „Remove symbols, letters, and any leading zeros“, bei Vor- und Nachname schlicht „Lowercase only with no punctuation“. Erst nach dieser Normalisierung wird gehasht, nicht der Rohwert direkt, denn zwei unterschiedlich geschriebene, aber inhaltlich identische E-Mail-Adressen müssen denselben Hash ergeben, sonst würde Meta sie fälschlich als zwei verschiedene Personen behandeln. Dieselbe Logik aus Normalisierung plus SHA-256-Hash gilt auch für weitere personenbezogene Felder wie Geburtsdatum, Ort, Bundesland, Postleitzahl oder Land, jeweils mit eigener Formatvorschrift.
Nicht gehasht werden dagegen technische Kennungen, die ohnehin keine direkt identifizierenden Klartextdaten wie einen Namen enthalten, sondern Meta in unveränderter Form vorliegen müssen, um sie mit einem Anzeigenklick oder einer Browser-Sitzung abzugleichen. Für die IP-Adresse des Nutzers ist das ausdrücklich festgelegt: „must never be hashed“. Dieselbe Regel „Do not hash“ gilt laut Meta für den User-Agent des Browsers sowie für die beiden Meta-eigenen Cookie-Werte fbc (Klick-ID aus einem Anzeigenklick) und fbp (Browser-ID). Diese Unterscheidung folgt einer klaren Logik, die sich daraus ergibt, wofür beide Kategorien jeweils gebraucht werden: Identifizierende Klartextfelder wie E-Mail oder Telefonnummer werden gehasht, weil sie Meta nur zum serverseitigen Abgleich mit bereits vorhandenen, ebenfalls gehashten Kontodaten dienen sollen. Technische Sitzungs- und Klick-Kennungen wie fbc und fbp dagegen funktionieren nur im Klartext, weil sie exakt mit dem Wert übereinstimmen müssen, den derselbe Browser beim Anzeigenklick oder Seitenbesuch bereits gesetzt hat.
Event Match Quality: die Kennzahl, an der sich eine Implementierung messen lässt
Ob eine Conversions-API-Einrichtung tatsächlich sauber funktioniert, muss kein Ratespiel bleiben. Meta liefert dafür eine eigene, laufend aktualisierte Kennzahl, den Event Match Quality Score, kurz EMQ. Laut Metas Entwicklerdokumentation gilt: „Event match quality (EMQ) is a score (out of 10)“, das heißt, EMQ bewegt sich auf einer Skala von null bis zehn. Der Wert zeigt an, wie zuverlässig die übermittelten Kundendaten ein Server-Event tatsächlich einem bestehenden Meta-Konto zuordnen lassen: Er „indicates how effective the customer information sent from your server may be at matching event instances to a Meta account. High quality event matching may improve ads attribution and performance.“
EMQ ist dabei keine einmalige Momentaufnahme beim Setup, sondern eine fortlaufend neu berechnete Größe. Meta beschreibt die Berechnungsgrundlage so: Der Wert wird kalkuliert, „by looking at which customer information parameters are received from your server using a Conversions API integration, the quality of the information received and the percent of event instances that are matched to a Meta account“, und zwar „in real time“. Zwei Faktoren fließen also zusammen: welche und wie viele werthaltige Identifikatoren (E-Mail, Telefonnummer, Klick- und Browser-ID) ein Event überhaupt mitbringt, und wie hoch der Anteil der Events ist, die sich damit tatsächlich einer Person zuordnen lassen. Für die Praxis macht das aus einer vagen Frage wie „läuft unsere Conversions API?“ eine konkrete, im Zeitverlauf beobachtbare Zahl im Events Manager, an der sich messen lässt, ob eine technische Änderung am Setup die Datenqualität tatsächlich verbessert oder verschlechtert hat.
Was die Conversions API nicht ersetzt: Einwilligung und Rechtsgrundlage
Die Conversions API löst ein technisches Problem, den Datenverlust durch Browser-Restriktionen und Werbeblocker, kein rechtliches. Meta selbst stellt in der eigenen Implementierungsanleitung klar, dass für serverseitig übertragene Daten dieselbe Einwilligungslogik gilt wie für den Pixel: „If you have logic for controlling consent with respect to sharing Pixel data, use the same logic with respect to sharing data via Conversions API.“ Ein Server-Event darf mit anderen Worten nur dann an Meta übertragen werden, wenn für die betroffene Person zuvor eine wirksame Einwilligung vorliegt, genau wie beim Pixel. Das Hashing von E-Mail-Adresse oder Telefonnummer verändert daran nichts: Ein SHA-256-Hash ist eine Pseudonymisierung, keine Anonymisierung, und ersetzt keine Rechtsgrundlage nach der Datenschutz-Grundverordnung.
Wie ernst deutsche Gerichte diese Trennung zwischen technischer Umsetzung und rechtlicher Grundlage inzwischen nehmen, zeigt die aktuelle Rechtsprechung: Deutsche Gerichte haben in den vergangenen Jahren wiederholt bestätigt, dass die Einbindung von Meta Business Tools ohne wirksame vorherige Einwilligung gegen die DSGVO verstößt und Schadensersatzansprüche nach Artikel 82 der Datenschutz-Grundverordnung auslösen kann. Diese Rechtsprechung betrifft die Meta Business Tools im Allgemeinen, zu denen neben dem Pixel auch serverseitig übertragene Daten zählen, wenn dieselbe fehlende Einwilligung zugrunde liegt. Für die Praxis folgt daraus ein einfacher, aber oft übersehener Grundsatz: Eine technisch einwandfreie Conversions-API-Integration mit hohem EMQ-Wert sagt nichts darüber aus, ob die zugrunde liegende Einwilligung rechtlich wirksam eingeholt wurde. Beide Fragen gehören zusammen geprüft, aber sie sind nicht dieselbe Frage.
Wie Unternehmen den Einstieg angehen
Der erste sinnvolle Schritt ist nicht die Einrichtung selbst, sondern eine ehrliche Bestandsaufnahme des vorhandenen Pixel-Setups: Feuert der Pixel zuverlässig, mit welchen event_name-Werten, und existiert bereits eine event_id-Logik, auf der eine spätere Deduplizierung aufbauen kann? Erst danach stellt sich die technische Wegfrage, ob die Conversions API direkt serverseitig an das eigene Backend angebunden wird oder über einen bestehenden beziehungsweise neu aufzusetzenden Server-Side-Tracking-Container läuft, über den sich neben Meta oft gleich mehrere Plattformen bündeln lassen. Wie ein solches Server-Side-Tracking-Setup grundsätzlich aussieht und welcher Aufwand dafür realistisch einzuplanen ist, haben wir in einem eigenen Beitrag zu den Kosten von Server-Side Tracking zusammengefasst; der konkrete Aufwand variiert dabei je nach vorhandenem Tracking-Zustand und Zahl der anzubindenden Plattformen. Nach der Einrichtung lohnt sich vor dem vollständigen Go-Live ein Blick in den Events Manager: Der EMQ-Wert zeigt dort in Echtzeit, ob die übertragenen Kundendaten tatsächlich ausreichen, um Server-Events zuverlässig zuzuordnen, und ob die Deduplizierung mit dem Pixel wie vorgesehen greift, bevor eine mögliche doppelte Zählung unbemerkt in die Kampagnensteuerung einfließt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Meta-Pixel und Conversions API?
Der Meta-Pixel misst ein Ereignis im Browser des Besuchers und sendet es von dort an Meta, die Conversions API sendet dasselbe Ereignis als Server-Event direkt von einem eigenen Server aus. Beide Wege werden bei Meta identisch verarbeitet und ergänzen sich in der Praxis meist, statt sich gegenseitig zu ersetzen.
Muss ich alle Nutzerdaten hashen, bevor ich sie an Meta sende?
Nein. Identifizierende Klartextfelder wie E-Mail-Adresse, Telefonnummer oder Name müssen nach Normalisierung mit SHA-256 gehasht werden. Technische Kennungen wie IP-Adresse, User-Agent sowie die Meta-Cookies fbc und fbp dürfen laut Meta dagegen ausdrücklich nicht gehasht werden, weil sie im Klartext mit vorhandenen Sitzungsdaten abgeglichen werden müssen.
Was passiert, wenn Pixel und Conversions API dasselbe Ereignis melden?
Stimmen event_id und event_name beider Meldungen überein, erkennt Meta innerhalb eines 48-Stunden-Fensters, dass es sich um ein einziges Ereignis handelt, und zählt es nur einmal. Ohne übereinstimmende event_id kann dasselbe Ereignis dagegen doppelt in die Auswertung einfließen.
Was ist ein guter Event-Match-Quality-Wert?
Event Match Quality wird von Meta auf einer Skala von null bis zehn angegeben und in Echtzeit aus der Qualität der übertragenen Kundendaten sowie dem Anteil erfolgreich zugeordneter Ereignisse berechnet. Je mehr werthaltige Identifikatoren wie E-Mail, Telefonnummer und Klick-ID ein Event mitbringt, desto höher fällt der Wert aus.
Ersetzt die Conversions API die Einwilligung der Nutzer?
Nein. Meta verlangt für Server-Events ausdrücklich dieselbe Einwilligungslogik wie für den Pixel. Deutsche Gerichte haben die Einbindung der Meta Business Tools ohne wirksame Einwilligung wiederholt als rechtswidrige Datenverarbeitung eingestuft, unabhängig davon, wie sauber die technische Übertragung selbst umgesetzt ist.
Fazit
Technisch bringt die Meta Conversions API vor allem eines: ein zusätzliches, serverseitiges Standbein für dieselben Kauf- und Lead-Ereignisse, die der Pixel im Browser längst erfasst, mit dem Ziel, Datenverluste durch Werbeblocker und Browser-Restriktionen abzufedern. Ihr Nutzen entscheidet sich an drei technischen Details, die in Marketing-Erklärungen oft untergehen: einer sauberen Deduplizierung über identische event_id- und event_name-Werte, einer feldspezifischen statt pauschalen Hashing-Logik für Kundendaten und einem laufend beobachteten Event-Match-Quality-Wert statt einer einmaligen Einrichtung nach dem Prinzip Fire-and-Forget. Was die Conversions API dagegen nicht mitliefert, ist eine Rechtsgrundlage: Die entscheidet sich weiterhin an der Einwilligung, unabhängig davon, wie sauber die Technik dahinter arbeitet. Wer die eigene Ausgangslage einschätzen lassen möchte, kann sich bei uns für ein unverbindliches Erstgespräch melden, mehr zu unserem Leistungsumfang rund um serverseitiges Tracking steht auf unserer Server-Side-Tracking-Seite.
Quellen
Meta for Developers: Conversions API, Überblick zu Server-Events
Meta for Developers: Deduplicate Pixel and Server Events
Meta for Developers: Customer Information Parameters, Hashing- und Normalisierungsregeln
Meta for Developers: Dataset Quality API, Definition und Berechnung von Event Match Quality
Meta for Developers: End-to-End Implementation Guide, Hinweis zur Consent-Logik
datenschutzticker.de: DSGVO-Verstoß durch Meta Business Tools, Berichterstattung zu Gerichtsentscheidungen gegen den Einsatz von Meta Business Tools ohne wirksame Einwilligung
Beyond Media: Was kostet Server-Side Tracking?
