Du schaust in den Events Manager und die Zahlen passen nicht zusammen. Meta meldet 340 Leads. Dein CRM sagt 190. Der Kampagnen-Report sieht super aus, dein Kontostand nicht. Und irgendwo dazwischen steht ein grünes Häkchen bei der Conversions API, das dir signalisiert: alles in Ordnung.
Ist es nicht. In den meisten Konten, die wir übernehmen, läuft die CAPI technisch, aber die Deduplizierung ist kaputt. Das Konto zählt Conversions doppelt, der Algorithmus lernt auf Basis von Phantom-Daten und du zahlst am Ende mehr pro echtem Lead. Das grüne Häkchen sagt nur, dass Events ankommen. Es sagt nichts darüber, ob sie richtig ankommen.
Was die Conversions API eigentlich macht
Kurz, weil du das wahrscheinlich schon weißt: Das Browser-Pixel sitzt im Frontend deines Nutzers. Adblocker, ITP in Safari, abgelehnte Cookies, alte Geräte. Jede dieser Hürden frisst dir Events weg. Die Conversions API schickt dasselbe Ereignis stattdessen von deinem Server oder aus einem Server-Side-GTM-Container direkt an Meta. Kein Browser dazwischen, der etwas blockieren kann.
Der Punkt: Du sollst beides parallel laufen lassen. Meta empfiehlt ausdrücklich die redundante Einrichtung, also Pixel und Server. Der Browser liefert Signale, die der Server nicht hat. Der Server liefert die Conversions, die der Browser verloren hat. Zusammen ergibt das ein vollständigeres Bild.
Und genau da fängt das Problem an. Wenn zwei Systeme dasselbe Ereignis melden, muss Meta erkennen, dass es dasselbe Ereignis ist. Das ist die Deduplizierung. Und die funktioniert nicht automatisch, nur weil du beides aktiviert hast.
Der Fehler Nummer eins: doppelt gezählte Events
Meta erkennt zwei Kopien desselben Ereignisses an zwei Feldern: event_id und event_name. Beide müssen bei der Browser-Version und der Server-Version identisch sein. Beide. Stimmt nur eines nicht, behandelt Meta die zweite Kopie als eigenständige Conversion und zählt sie zusätzlich.
Der Klassiker: Das Pixel feuert Lead, der Server schickt lead oder Lead_Server. Für dich ist das dasselbe Ereignis. Für Meta sind das zwei verschiedene Events, die nie dedupliziert werden. Genauso häufig: Die event_id wird in Browser und Server unabhängig voneinander generiert, jeweils als frischer Zufallswert. Dann gibt es überhaupt keine gemeinsame Klammer.
Dazu kommt ein Zeitfenster, das kaum jemand auf dem Schirm hat. Meta dedupliziert innerhalb von 48 Stunden. Trifft die zweite Kopie später ein, zählt sie als eigenes Event, auch wenn event_id und event_name perfekt übereinstimmen. Relevant wird das bei Batch-Uploads, bei nächtlichen CRM-Syncs, bei Offline-Conversions, die erst am Wochenende verarbeitet werden. Wenn dein Server-Job einmal drei Tage hängt, produzierst du Duplikate.
Doppelt gezählte Conversions verzerren nicht nur den Report. Der Algorithmus optimiert auf das, was er als Erfolg gemeldet bekommt. Zählt er Conversions doppelt, bewertet er Zielgruppen und Platzierungen falsch. Dein ausgewiesener Lead-Preis sinkt, dein echter Lead-Preis steigt.
So erkennst du im Events Manager, ob die Deduplizierung läuft
Das kannst du in zehn Minuten selbst prüfen. Geh in den Events Manager, wähle dein Dataset, dann die Übersicht der einzelnen Events. Dort siehst du pro Event, aus welcher Quelle es kam: Browser, Server oder beides.
Zwei Regeln reichen für die Diagnose:
- Server-Volumen deutlich niedriger als Browser-Volumen: Deine CAPI feuert nicht für alle Conversions. Irgendein Pfad ist nicht abgedeckt, zum Beispiel Zahlungen über einen externen Anbieter, ein zweites Formular oder Bestellungen, die über einen anderen Flow laufen.
- Gesamtzahl der Events höher als Browser plus Server nach Deduplizierung: Die Deduplizierung greift nicht. Du zählst doppelt.
Nimm ein einzelnes wichtiges Event, zum Beispiel Lead oder Purchase, und schau dir den Anteil an, den Meta als dedupliziert ausweist. Wenn dort quasi nichts als Duplikat erkannt wird, obwohl du beide Kanäle aktiv hast, ist der Fall klar.
Danach gehst du in den Test Events Tab, löst die Conversion auf deiner Website einmal selbst aus und schaust dir die beiden eintreffenden Events nebeneinander an. Vergleiche Zeichen für Zeichen: gleicher event_name, gleiche event_id. Wenn die IDs auch nur in der Groß- und Kleinschreibung abweichen, matchen sie nicht.
Event Match Quality: die Zahl, die deinen Lead-Preis mitbestimmt
Neben der Deduplizierung gibt es eine zweite Zahl, die im Alltag mehr Geld bewegt als die meisten Kampagnen-Einstellungen. Die Event Match Quality, kurz EMQ. Sie sagt dir, wie gut Meta die von dir gesendeten Kundendaten einem echten Nutzerprofil zuordnen kann. Skala 0 bis 10, pro Event einsehbar im Events Manager.
| EMQ-Wert | Was das bedeutet |
|---|---|
| Unter 5 | Schlechtere Auslieferung, schwächere Lookalikes, höherer Lead-Preis. Meta kann die Events kaum zuordnen. |
| 5 bis 7 | Funktional, aber suboptimal. Läuft, verschenkt aber Potenzial bei Matching und Attribution. |
| Über 7 | Meta behandelt das Konto als vertrauenswürdige Signalquelle. |
| 8 oder höher | Zielwert für Purchase-Events. Hier arbeitet die Optimierung mit sauberer Datenbasis. |
Unbequeme Wahrheit: Viele Konten fahren jahrelang mit einer EMQ um die 4 und suchen den Fehler in der Creative-Strategie. Das Creative ist selten das Problem, wenn die Maschine nicht weiß, wen sie da eigentlich erreicht hat.
Du willst wissen, was in deinem Konto wirklich läuft?
Wir schauen uns Deduplizierung, EMQ und Event-Setup an und sagen dir konkret, wo dein Tracking Geld verliert. Ohne Folien, mit Screenshots aus deinem Konto.
Die Parameter, die die EMQ wirklich heben
Wenn du nur die gehashte E-Mail-Adresse mitschickst, landest du typischerweise bei einer EMQ von 5 bis 6. Das ist der Standard-Zustand der meisten Setups. Kommen Telefonnummer, Vorname, Nachname, Ort, Postleitzahl, Land und eine external_id dazu, sind 7 bis 9 erreichbar.
Der stärkste Einzelhebel bleibt trotzdem die gehashte E-Mail bei jedem Event. Nicht nur beim Kauf. Auch beim ViewContent, beim AddToCart, beim Lead. Sobald du die Adresse kennst, gehört sie in jedes folgende Event.
Und jetzt der Teil, an dem die meisten Implementierungen scheitern: die Normalisierung vor dem Hashing. Du musst die Werte trimmen und in Kleinbuchstaben umwandeln, bevor du SHA-256 darüberlaufen lässt. Ein einziges Leerzeichen am Ende erzeugt einen komplett anderen Hash. "user@email.com " und "user@email.com" ergeben zwei verschiedene Werte, und der eine matcht auf gar nichts.
Dasselbe gilt für Telefonnummern. Die gehören ins internationale Format, ohne Leerzeichen, ohne Klammern, ohne Bindestriche, ohne führende Null nach der Ländervorwahl. Bei Ort und Land dasselbe Spiel: klein, ohne Sonderzeichen, Land als zweistelliger Code.
Nimm einen Hash aus deinem Server-Payload und generiere denselben Wert manuell aus der normalisierten Klartext-Adresse. Wenn die beiden Strings nicht identisch sind, hashst du falsch normalisierte Daten und wunderst dich seit Monaten über deine EMQ.
Drei Fallen, die wir regelmäßig sehen
1. Der nopid-Bug beim PageView
Ein Bug, der in vielen Setups steckt und den kaum jemand findet. Das PageView-Event der CAPI erzeugt seine event_id, bevor das Meta-Pixel-Base-Tag den Wert _fbPageId gesetzt hat. Ergebnis: In der event_id steht ein nopid, weil der Wert schlicht noch nicht existierte. Die Browser-Kopie bekommt die richtige ID, die Server-Kopie eine kaputte. Deduplizierung schlägt fehl, still und leise.
Die Lösung ist unspektakulär: ein kurzer Delay vor der Generierung der event_id, damit das Base-Tag vorher fertig ist. Prüf in deinen Test Events einfach mal, ob irgendwo nopid in den IDs auftaucht.
2. Pixel ID und Dataset ID verwechselt
Passiert öfter, als man glaubt, vor allem bei Setups, die über die Jahre gewachsen sind. Die beiden IDs sehen ähnlich aus und stehen an unterschiedlichen Stellen im Interface. Landen deine Server-Events in einem anderen Dataset als deine Pixel-Events, kann Meta gar nicht deduplizieren. Die zwei Kopien treffen sich nie. Kontrollier die ID in deiner Server-Konfiguration gegen die ID, die im Events Manager oben beim aktiven Dataset steht.
3. Die TikTok-Regel auf Meta übertragen
Wer parallel auf TikTok wirbt, baut oft ein gemeinsames Tracking-Setup und übernimmt eine Logik von der einen Plattform auf die andere. Das geht schief. Meta dedupliziert über event_id plus event_name innerhalb von 48 Stunden, mehr braucht es nicht. TikTok verlangt zusätzlich mindestens fünf Minuten Abstand zwischen der Pixel-Kopie und der Server-Kopie. Wer beide Systeme identisch konfiguriert, hat entweder auf TikTok Duplikate oder baut sich auf Meta unnötige Verzögerungen ein.
Am Rande, falls du Filialen oder stationären Verkauf trackst: Meta hat die Offline Conversions API im Mai 2025 abgeschaltet. Offline-Events laufen jetzt über den normalen CAPI-Endpoint mit action_source: physical_store. Wenn dein Setup älter ist und nie angefasst wurde, lohnt sich ein Blick.
Was serverseitiges Tracking nicht löst
Hier wird viel Unsinn erzählt, also im Klartext: Serverseitiges Tracking ersetzt keine Einwilligung. Es verlagert nur den Ort der Verarbeitung, vom Browser deines Nutzers auf deinen Server. Rechtlich ändert das an der Zustimmungspflicht nichts.
In Österreich gilt Paragraf 165 Absatz 3 TKG 2021. Ohne Einwilligung dürfen nur unbedingt erforderliche Cookies gesetzt und ausgelesen werden. Tracking für Werbezwecke ist nicht unbedingt erforderlich, egal ob das Event vom Browser oder vom Server rausgeht. Dazu kommt die DSGVO für die Verarbeitung der personenbezogenen Daten selbst, und gehashte E-Mail-Adressen sind personenbezogene Daten.
Wer dir serverseitiges Tracking als Consent-Umgehung verkauft, verkauft dir ein Risiko. Der echte Nutzen liegt woanders: bessere Datenqualität für die Nutzer, die eingewilligt haben. Das ist schon viel wert. Du brauchst also weiterhin ein sauberes Consent-Management, und dein Server-Container muss den Consent-Status respektieren.
Selbstcheck in 6 Punkten
- Event-Namen vergleichen. Browser und Server müssen exakt denselben
event_namesenden, inklusive Groß- und Kleinschreibung. - event_id vergleichen. Eine Conversion auslösen, in den Test Events beide Kopien nebeneinander legen, IDs Zeichen für Zeichen prüfen. Nach
nopidsuchen. - Volumenvergleich fahren. Ist das Server-Volumen deutlich niedriger als das Browser-Volumen, deckt die CAPI nicht alle Conversion-Pfade ab.
- Auf Doppelzählung prüfen. Liegt die Gesamtzahl der Events über Browser plus Server, ist die Deduplizierung defekt.
- EMQ pro Event ablesen. Alles unter 7 heißt: Parameter nachrüsten. Telefonnummer, Vor- und Nachname, Ort, PLZ, Land,
external_id. E-Mail bei jedem Event. - Hashing kontrollieren. Werte getrimmt und in Kleinbuchstaben, erst dann SHA-256. Einen Hash gegenprüfen, nicht dem Code vertrauen.
Wenn du diese sechs Punkte durchgehst, weißt du in unter einer Stunde, ob dein Tracking sauber ist. Und die meisten stellen dabei fest, dass ihr Konto seit Monaten auf Basis von falschen Zahlen optimiert. Das Unangenehme daran ist nicht der Fehler. Das Unangenehme ist, dass er die ganze Zeit über sichtbar im Events Manager stand und niemand hingeschaut hat.