Meta Ads
Meta Conversions API und Einwilligung sauber einrichten
Pixel und Conversions API ergänzen sich, wenn sie richtig verzahnt sind: mit gemeinsamer event_id gegen Doppelzählung und mit Einwilligung, die auch auf dem Server gilt.
Auf einen Blick
- Autor
- Ciyan Gültoplayan
- Thema
- Pixel und CAPI
- Kern
- event_id und Einwilligung
- Quellen
- Stand 24.10.2026
Warum der Pixel allein nicht reicht
Der Meta Pixel läuft im Browser Ihrer Besucher. Er hängt von JavaScript und Cookies ab und davon, dass kein Blocker oder restriktiver Browser dazwischenfunkt. Wenn Ihr Pixel weniger Abschlüsse zählt, als Ihr Shop oder Ihr CRM verzeichnet, liegt das oft daran.
Die Conversions API (CAPI) geht den anderen Weg: Ihr Server schickt das Ereignis direkt an Meta. Der Browser spielt dabei keine Rolle. Pixel und CAPI ersetzen sich nicht, sondern ergänzen sich. Der Pixel liefert Browser-Signale, die CAPI Server-Signale wie die E-Mail-Adresse in gehashter Form. Wie viele zusätzliche Ereignisse bei Ihnen ankommen, hängt von Ihrer Datenlage ab; eine pauschale Zahl nennen wir nicht.
Ein zweiter Kanal allein verbessert nichts. Falsch verbunden zählen Sie Abschlüsse doppelt oder senden Daten ohne Einwilligung. Dieser Artikel zeigt den Meta-spezifischen Teil. Grundlagen zur Einwilligung und zum Tag Manager finden Sie in GA4 richtig einrichten. Zur Meta-Werbung selbst siehe Meta Ads.
Pixel und Conversions API im Vergleich
Beide Wege schreiben in dieselbe Datenquelle bei Meta, unterscheiden sich aber im Ursprung der Signale.
Meta Pixel
Läuft im Browser. Liefert Browser-Signale wie die Cookies fbp und fbc. Abhängig von Cookies, JavaScript und Blockern.
Conversions API
Läuft auf Ihrem Server oder Server-Container. Liefert Server-Signale wie gehashte E-Mail, IP-Adresse und User-Agent. Unabhängig vom Browser.
Zusammen
Beide senden dasselbe Ereignis mit derselben event_id. Meta behält ein Ereignis und verwirft das Duplikat.
Die Architektur: Einwilligung, Server-Container, Meta
Der Datenfluss in einem Satz: Die Einwilligungsabfrage entscheidet, ob getrackt werden darf, der Server-Container leitet die Ereignisse weiter, Pixel und CAPI senden sie mit gemeinsamer ID.
- 01
Einwilligung
Ihre Einwilligungsabfrage legt fest, ob Marketing-Ereignisse erlaubt sind.
- 02
Server-Container
Der Server-Side-GTM empfängt Ereignisse auf Ihrer Domain, prüft die Einwilligung und leitet weiter.
- 03
Pixel und CAPI
Beide Kanäle schreiben in dasselbe Dataset, mit gleicher event_id und gleichem Ereignisnamen.
Server-Side-Tagging ist ein eigenes Thema, das wir hier nur streifen. Eine Einführung steht im Lexikon unter Server-Side-Tracking; unser Angebot beschreibt Tracking und Analytics.
Schritt für Schritt einrichten
Voraussetzung ist ein laufendes Pixel-Grundsetup und ein Server-Container. Dann gehen Sie so vor:
- 01
Dataset und Token
Dataset-ID aus Meta notieren, Zugriffstoken für die Conversions API erzeugen. Das Token ist ein Geheimnis: nur im Server-Container oder in einer Umgebungsvariable, nie im Browser-Code oder im Repository.
- 02
Endpunkt auf eigener Domain
Der Server-Container braucht eine eigene Adresse, idealerweise unter Ihrer Domain. Der Browser-Container schickt seine Ereignisse dorthin.
- 03
CAPI-Tag anlegen
Im Server-Container das Tag für die Conversions API einrichten, Dataset-ID und Token eintragen.
- 04
Ereignisse zuordnen
Standardereignisse wie Purchase oder Lead mit denselben Namen wie im Pixel senden, Wert und Währung mitgeben.
- 05
Einwilligung verankern
Das Tag feuert nur, wenn die Einwilligung für Marketing vorliegt. Die Prüfung gehört in den Server-Container, nicht nur in den Browser.
- 06
Testen
In den Testereignissen von Meta prüfen, ob Browser- und Server-Ereignis ankommen und als ein Ereignis zählen. Dann den negativen Test: Bei Ablehnung darf nichts gesendet werden.
Deduplizierung: die gemeinsame event_id
Sendet derselbe Abschluss einmal über den Pixel und einmal über die CAPI, würde Meta ihn ohne Gegenmaßnahme doppelt zählen. Das verfälscht Auswertung und Optimierung. Die Lösung ist eine gemeinsame event_id.
Nach der Meta-Dokumentation muss die eventID des Pixels der event_id der CAPI entsprechen und der Ereignisname dem event_name, und beide Ereignisse müssen an dieselbe Pixel-ID gehen. Meta verwirft Duplikate nur, wenn sie innerhalb von 48 Stunden nach dem ersten Ereignis mit dieser ID eintreffen. Sind die Ereignisse nicht deutlich verschieden, bleibt in der Regel das zuerst empfangene erhalten.
Praktisch erzeugen Sie die ID einmal im Browser, geben sie an den Pixel und legen sie in den dataLayer, damit der Server-Container sie für die CAPI wiederverwendet. Schon eine abweichende Schreibweise des Ereignisnamens (Purchase statt purchase) verhindert die Deduplizierung.
Quelle: Meta-Entwicklerdokumentation zur Conversions API (developers.facebook.com), abgerufen am 24.10.2026. Sinngemäß wiedergegeben; Funktionen und Bezeichnungen können sich ändern.
Kundenparameter richtig übergeben
Je besser Meta ein Ereignis einer Person zuordnen kann, desto brauchbarer sind die Daten. Mehr Parameter helfen aber nur, wenn die Einwilligung sie deckt.
E-Mail (em)
Muss gehasht werden. Vorher Leerzeichen am Anfang und Ende entfernen und alles kleinschreiben.
Telefon (ph)
Muss gehasht werden. Vorher Symbole, Buchstaben und führende Nullen entfernen und die Landesvorwahl ergänzen.
fbp und fbc
Browser-Kennungen aus den Cookies _fbp und _fbc. Nicht hashen, unverändert weiterreichen.
IP-Adresse und User-Agent
Nicht hashen. Der User-Agent ist für Website-Ereignisse über die CAPI erforderlich.
Externe ID
Eine eigene Kennung, zum Beispiel eine Kundennummer. Hashen wird empfohlen, ist aber nicht vorgeschrieben.
Klartext vermeiden
Personenbezogene Angaben wie E-Mail und Telefon gehen nie ungehasht an Meta. Das Hashing gehört zuverlässig vor den Versand.
Quelle: Meta-Entwicklerdokumentation zur Conversions API (developers.facebook.com), abgerufen am 24.10.2026. Sinngemäß wiedergegeben; Funktionen und Bezeichnungen können sich ändern.
Vier häufige Fehler
Liefert ein Dual-Setup nicht, liegt es selten an Meta und meist an einem dieser Punkte.
Keine oder uneinheitliche event_id
Der Klassiker. Ohne identische ID zählt Meta doppelt, Ihre Zahlen sehen besser aus, als sie sind. Prüfen Sie das zuerst in den Testereignissen.
Einwilligung nur im Browser geprüft
Der Pixel wird sauber gesperrt, die CAPI feuert serverseitig trotzdem. Das fällt in der Browser-Konsole nicht auf, ist aber der gravierendste Fehler.
Klartext statt Hash
E-Mail oder Telefon ungehasht zu übertragen ist ein Fehler. Das Hashing muss zuverlässig greifen, am besten im Server-Container.
Keine Normalisierung vor dem Hashen
Großschreibung oder Leerzeichen ergeben einen anderen Hash, und es entsteht kein Treffer, obwohl viele Parameter übergeben wurden.
Was bei abgelehnter Einwilligung passiert
Lehnt ein Besucher ab oder ignoriert er die Abfrage, dürfen weder Pixel noch CAPI Marketing-Ereignisse senden. Das gilt auch für den Server: Serverseitiges Tracking entbindet nicht von der Einwilligungsfrage, und die Prüfung muss im Server-Container ankommen, nicht nur im Browser. Wir bewerten die rechtliche Lage nicht; stimmen Sie Ihr Vorgehen mit Ihrer Datenschutzstelle ab.
Realistisch bedeutet eine Ablehnung weniger Daten. Es gibt kein Werkzeug, das den vollen Umfang ohne Einwilligung wiederherstellt. Seriös ist, die Zustimmung durch eine verständliche Abfrage zu verbessern und mit dem zu arbeiten, was rechtmäßig erhoben werden darf.
Mit der CAPI sind Sie für die Übermittlung der Daten an Meta verantwortlich. Dokumentieren Sie, welche Daten Sie senden, auf welcher Grundlage und an wen, und bilden Sie das in Datenschutzerklärung und Verzeichnis der Verarbeitungstätigkeiten ab. Senden Sie nur die Parameter, die Sie brauchen und die durch die Einwilligung gedeckt sind.
Checkliste vor dem Livegang
Diese Punkte sollten Sie vor dem Start abhaken:
- Pixel feuert im Browser, zum Beispiel geprüft mit dem Meta Pixel Helper.
- Das CAPI-Ereignis kommt am Server an und erscheint in den Testereignissen.
- event_id und Ereignisname sind in Browser und Server identisch.
- Meta zählt die Ereignisse als eines, nicht als zwei.
- Das Tag feuert nur bei erteilter Einwilligung, auch serverseitig.
- Personenbezogene Parameter werden normalisiert und gehasht.
- Negativtest: Bei Ablehnung wird nichts gesendet.
Häufige Fragen
Ihre Frage ist nicht dabei? Rufen Sie an oder schreiben Sie uns, wir antworten persönlich.
Brauche ich die Conversions API, wenn der Pixel läuft?
Nötig ist sie nicht, aber sinnvoll, wenn Ihr Pixel weniger Abschlüsse zählt, als Ihr System verzeichnet. Die CAPI liefert Signale vom Server, die kein Blocker im Browser stoppt. Beide ergänzen sich: Der Pixel bringt Browser-Kennungen, die CAPI Server-Daten. Wie viele Ereignisse zusätzlich ankommen, hängt von Ihrer Datenqualität ab, eine Zusage dazu geben wir nicht.
Zähle ich doppelt, wenn Pixel und CAPI parallel laufen?
Nur ohne Deduplizierung. Geben Sie auf beiden Kanälen denselben Ereignisnamen und dieselbe event_id mit und senden Sie beide an dieselbe Pixel-ID, verwirft Meta das spätere Duplikat. Das gilt nur, wenn es innerhalb von 48 Stunden nach dem ersten Ereignis mit dieser ID eintrifft. Prüfen Sie es in den Testereignissen.
Welche Daten muss ich hashen?
E-Mail-Adresse und Telefonnummer müssen gehasht werden, vorher normalisiert: E-Mail ohne Leerzeichen am Rand und kleingeschrieben, Telefonnummer ohne Symbole, Buchstaben und führende Nullen, mit Landesvorwahl. Die externe ID sollten Sie hashen. fbp, fbc, IP-Adresse und User-Agent werden nicht gehasht.
Darf die CAPI senden, wenn ein Besucher ablehnt?
Wir empfehlen, dann kein Marketing-Ereignis zu senden, weder über den Pixel noch über die CAPI. Die Prüfung der Einwilligung muss serverseitig greifen, nicht nur im Browser. Die rechtliche Bewertung im Einzelfall nehmen wir nicht vor; klären Sie sie mit Ihrer Datenschutzstelle oder Ihrem Rechtsbeistand.
Wo gehört das Zugriffstoken hin?
Das Token der Conversions API ist ein Geheimnis. Es gehört in den Server-Container oder eine Umgebungsvariable, niemals in den Code, der an den Browser ausgeliefert wird, und nicht in ein Repository. Wer das Token kennt, kann Ereignisse in Ihrem Namen an Meta senden, deshalb behandeln Sie es wie ein Passwort.
