Event-Deduplizierung: Pixel und CAPI sauber trennen

Worum es geht, und warum ein Kauf doppelt gezählt wird

Der klassische Aufbau im Performance-Marketing kennt einen Meldeweg: den Browser-Pixel. Er feuert im Browser des Kunden und meldet den Kauf direkt an Meta oder Google. Mit Server-Side Tracking kommt ein zweiter Weg dazu: die Conversions API, kurz CAPI. Sie meldet denselben Kauf vom Server aus, unabhängig vom Browser, was robuster gegen Adblocker, ITP-Restriktionen und fehlende Cookies ist. Genau deshalb laufen beide Wege in der Praxis parallel: Der Pixel deckt ab, was er kann, die API füllt die Lücken.

Damit meldet aber für einen einzigen Kauf der Pixel ein Purchase-Event und die API noch eines. Aus Sicht der Plattform sind das zunächst zwei Ereignisse. Sie weiß nicht, dass es derselbe Vorgang ist, solange du es ihr nicht sagst. Ohne diesen Hinweis schreibt sie zwei Conversions gut, obwohl nur ein Mensch einmal gekauft hat. Das ist der Kern des Problems, und es betrifft jeden, der Pixel und API gleichzeitig betreibt, nicht nur Sonderfälle.

Die Lösung heißt Event-Deduplizierung: Du gibst beiden Meldungen ein gemeinsames Merkmal mit, an dem die Plattform sie als ein und dasselbe Event wiedererkennt und die zweite verwirft. Klingt simpel, und im Prinzip ist es das auch. Die Tücke liegt darin, dass dieses Merkmal auf beiden Wegen wirklich identisch ankommen muss, und genau hier geht in der Praxis am meisten schief.

Zurück zum Überblick: Server-Side Tracking, der Leitfaden. Im Glossar: Deduplizierung, Pixel, Conversion API.

Wie Deduplizierung über event_id funktioniert

Das gemeinsame Merkmal ist die event_id, eine eindeutige Kennung pro Vorgang. Pixel und Conversions API senden für denselben Kauf dieselbe event_id mit, dazu denselben event_name, also etwa Purchase. Treffen beide Meldungen bei der Plattform ein, vergleicht sie die Kombination aus Event-Name und event_id. Stimmt sie überein, behält sie eine Meldung und wirft die zweite als Dublette weg. Genau ein Kauf, genau eine gezählte Conversion.

Ein kurzes Beispiel

Nehmen wir eine Bestellung mit der Order-Nummer 10042. Beim Kaufabschluss erzeugt dein Setup eine event_id, oft direkt aus der Order-Nummer abgeleitet, etwa order-10042. Der Browser-Pixel sendet jetzt Purchase mit event_id = order-10042. Der Server sendet über die Conversions API für genau diese Bestellung ebenfalls Purchase mit event_id = order-10042. Meta sieht zweimal dasselbe Paar aus Event-Name und ID, erkennt die Dublette und zählt nur eine Conversion. Käme vom Server eine andere ID, zum Beispiel ein zufälliger Wert, fehlte der gemeinsame Anker, und beide Meldungen würden getrennt gezählt.

Bei Google Ads heißt es nicht event_id, aber das Prinzip ist dasselbe: Eine konsistente Transaktions- oder Order-ID je Conversion sorgt dafür, dass derselbe Abschluss aus clientseitiger und serverseitiger Meldung nicht doppelt gezählt wird. Wichtig ist überall dieselbe Eigenschaft: Die Kennung muss pro Vorgang eindeutig sein und auf jedem Meldeweg exakt gleich lauten. Eine ID, die der Pixel anders bildet als der Server, ist keine gemeinsame ID, auch wenn sie auf den ersten Blick ähnlich aussieht.

Wie du die API sauber aufsetzt, zeigt Meta Conversions API einrichten. Im Glossar: Conversion.

Was bei fehlender Deduplizierung passiert

Wenn die Deduplizierung nicht greift, zählt die Plattform jeden Kauf doppelt, einmal vom Pixel und einmal von der API. Der Schaden beginnt im Reporting und endet im Budget. Die Conversion-Zahlen sind aufgebläht, der gemeldete Umsatz zu hoch, und der ROAS sieht glänzend aus, weil er auf Verkäufen beruht, die es doppelt gar nicht gibt. Wer nur auf diese Zahlen schaut, feiert einen Erfolg, der eine Verdopplung im Tracking ist.

Ein illustratives Rechenbeispiel

Nimm an, dein Shop macht in einem Zeitraum 100 echte Käufe. Der Pixel erfasst davon nicht alle, sagen wir 80, weil Adblocker und fehlende Cookies einen Teil schlucken. Die Conversions API meldet die vollen 100 vom Server. Greift die Deduplizierung, bleiben es 100 gezählte Conversions, korrekt. Greift sie nicht, addiert die Plattform beide Ströme: 80 vom Pixel plus 100 von der API ergeben bis zu 180 gemeldete Conversions für 100 reale Käufe. Die Zahlen sind illustrativ gewählt, das Muster aber ist real: Aus 100 Verkäufen wird im Reporting fast das Doppelte.

Schlimmer als die geschönte Optik ist die Steuerung dahinter. Smart Bidding optimiert auf die gemeldeten Conversions und Werte. Sind die überhöht, lernt der Algorithmus auf falschen Signalen und verteilt das Budget entsprechend daneben. Kampagnen, die im aufgeblähten Reporting stark aussehen, bekommen mehr Geld, obwohl der reale Beitrag ein anderer ist. Du verschiebst Budget anhand von Zahlen, die es so nie gegeben hat, und merkst es oft erst, wenn der tatsächliche Umsatz nicht mithält.

Besonders heikel ist die Verzerrung, weil sie nicht gleichmäßig ist. Käufe, die der Pixel gut erfasst, werden doppelt gezählt, schlecht erfasste eher einfach. Die Doppelzählung trifft also bestimmte Zielgruppen, Geräte und Kanäle stärker als andere und verschiebt damit nicht nur die Höhe, sondern auch die Struktur deiner Daten. Eine Korrektur im Kopf, nach dem Motto teile alles durch zwei, funktioniert deshalb nicht.

Typische Fehlerquellen

Deduplizierung scheitert selten laut. Meistens läuft alles scheinbar normal, nur die Zahlen stimmen nicht. Die folgenden Ursachen stecken hinter den allermeisten Fällen.

• event_id stimmt nicht überein: Pixel und Server bilden die ID auf unterschiedliche Weise, etwa der Pixel aus der Order-Nummer und der Server aus einem internen Datensatz-Schlüssel. Beide sind für sich eindeutig, aber eben nicht gleich. Damit fehlt der gemeinsame Anker, und die Plattform sieht zwei verschiedene Events.
• event_id fehlt ganz: Eine der beiden Seiten sendet keine ID mit, häufig die serverseitige, wenn sie nachträglich dazugebaut wurde. Ohne ID auf beiden Wegen gibt es nichts abzugleichen, und es wird grundsätzlich doppelt gezählt.
• Unterschiedlicher event_name: Der Pixel meldet Purchase, der Server ein abweichend benanntes Kauf-Event. Die Plattform dedupliziert über die Kombination aus Name und ID, also reicht eine gleiche ID nicht, wenn der Name auseinanderläuft.
• Timing und Zeitfenster: Die Plattform führt Meldungen nur innerhalb eines begrenzten Fensters zusammen. Kommt die serverseitige Meldung mit großer Verzögerung, etwa weil sie aus einem Batch-Job stammt, kann sie außerhalb des Fensters liegen und wird nicht mehr als Dublette erkannt.
• Mehrere feuernde Container oder Tags: Ein doppelt eingebundener GTM-Container, ein zusätzlicher Hardcode-Pixel oder ein Plugin, das ein eigenes Purchase-Event schickt, erzeugen weitere Meldungen ohne passende ID. Dann hilft auch eine saubere event_id auf den geplanten Wegen nicht mehr.

Diagnostizieren lässt sich das bei Meta im Events Manager. Dort siehst du je Event einen Deduplizierungs-Status, der anzeigt, ob Pixel- und Server-Meldung zusammengeführt wurden oder getrennt zählen. Das verlässlichste Warnsignal ist ohnehin ein Muster: Steigen die Conversion-Zahlen kurz nach dem Aktivieren der Conversions API spürbar an, ohne dass die realen Verkäufe gestiegen sind, läuft mit hoher Wahrscheinlichkeit die Deduplizierung nicht. Dann prüfst du zuerst die zwei häufigsten Punkte: Kommt die event_id auf beiden Wegen identisch an, und ist der Event-Name gleich.

Wo dein Setup steht, zeigt das kostenlose Website-Audit. Wie serverseitiges Tagging das Fundament dafür legt: GA4 server-side.

Deduplizierung über Kanäle und Netzwerke hinweg

Die event_id löst das Problem zwischen Pixel und API innerhalb einer Plattform. Dieselbe Grundfrage stellt sich aber eine Ebene höher noch einmal, und dort ist sie schwerer zu beantworten: Was passiert, wenn denselben Verkauf nicht zwei Meldewege beanspruchen, sondern mehrere Plattformen und Netzwerke. Ein Kauf, den Meta für sich reklamiert, kann zeitgleich von Google Ads und von einem Affiliate-Netzwerk als deren Conversion gezählt werden.

Das ist die kanalübergreifende Variante derselben Doppelzählung. Jede Plattform sieht nur ihren eigenen letzten Klick und schreibt sich den Abschluss gut. Addierst du die Reports naiv, kommst du auf mehr zugeordnete Verkäufe, als real stattgefunden haben, manchmal deutlich mehr. Innerhalb von Meta hilft die event_id, plattformübergreifend hilft sie nicht, weil keine der Plattformen die ID der anderen kennt oder akzeptiert.

Im Affiliate-Bereich hat dieses Problem einen eigenen Namen und eine eigene Lösung: die Affiliate-Deduplizierung, die verhindert, dass mehrere Netzwerke oder Publisher denselben Sale doppelt vergütet bekommen. Über alle Kanäle hinweg sauber zuzuordnen ist die Aufgabe einer unabhängigen Attribution, die nicht aus der Sicht einer einzelnen Plattform rechnet, sondern die ganze Journey kennt. Erst diese Ebene macht aus vielen einseitigen Last-Click-Reports ein konsistentes Bild, in dem jeder Verkauf genau einmal vorkommt.

Die Affiliate-Variante des Problems: Affiliate-Deduplizierung. Kanalübergreifend sauber zuordnen: Multi-Channel Attribution. Die Grundlagen dazu: Multi-Touch Attribution.