Meta Event Deduplication: doppelte Events richtig vermeiden

Meta Event Deduplication sorgt dafür, dass ein Ereignis nur einmal zählt, auch wenn es auf zwei Wegen ankommt. Sendest du einen Kauf sowohl über den Meta Pixel im Browser als auch über die Meta Conversions API vom Server, braucht Meta ein Merkmal, um beide Meldungen als dasselbe Ereignis zu erkennen. Dieses Merkmal ist die Kombination aus event_id und Ereignisname. Stimmen beide überein, behält Meta eine Meldung und verwirft die andere. Fehlt die event_id auf einem Weg oder unterscheidet sie sich, zählt Meta den Kauf doppelt. Die Folgen sind ein zu hoher Umsatz im Werbeanzeigenmanager, ein geschönter ROAS und eine Kampagnensteuerung, die aus falschen Zahlen lernt.

Warum senden Pixel und Conversions API dasselbe Ereignis?

Der Meta Pixel läuft im Browser des Besuchers. Er ist schnell eingerichtet, verliert aber Ereignisse, wenn ein Adblocker ihn blockiert, der Browser Cookies einschränkt oder die Seite verlassen wird, bevor die Anfrage raus ist. Die Conversions API sendet Ereignisse direkt von deinem Server oder deinem Shopsystem an Meta. Sie ist von diesen Einschränkungen weniger betroffen. Meta empfiehlt deshalb, beide Wege parallel zu nutzen, sodass der Server die Lücken des Browsers schließt. Das bedeutet aber auch, dass jeder Kauf, den der Browser erfolgreich meldet, ein zweites Mal vom Server kommt. Ohne Deduplizierung zählst du jeden dieser Käufe doppelt.

Wie funktioniert Meta Event Deduplication?

Meta vergleicht bei eingehenden Ereignissen zwei Felder: den Ereignisnamen und die Ereignis-ID. Im Pixel wird die ID als eventID im vierten Argument von fbq übergeben, zum Beispiel fbq('track', 'Purchase', {value: 49.90, currency: 'EUR'}, {eventID: 'B-10234'}). In der Conversions API heißt das Feld event_id, der Name steht in event_name. Kommen ein Browser- und ein Serverereignis mit gleichem Namen und gleicher ID innerhalb von 48 Stunden an, führt Meta sie zusammen. Der Ereignisname muss dabei übereinstimmen. Schreib ihn deshalb auf beiden Wegen exakt gleich, auch in Groß- und Kleinschreibung.

Die ID muss für jedes einzelne Ereignis eindeutig sein und auf beiden Wegen identisch. Für Käufe ist die Bestellnummer die naheliegende Wahl, weil sie im Browser auf der Bestellbestätigung und auf dem Server bekannt ist. Für Leads oder Ereignisse ohne natürliche Nummer erzeugst du im Browser eine zufällige ID, sendest sie mit dem Pixel und übergibst sie gleichzeitig, etwa über ein verstecktes Formularfeld oder den dataLayer, an den Server. Wichtig: Die ID beschreibt das Ereignis, nicht den Nutzer. Dieselbe ID für alle Ereignisse eines Besuchers führt dazu, dass Meta echte, unterschiedliche Ereignisse verwirft.

Im Google Tag Manager setzt du das so um: Der Shop schreibt die Bestellnummer auf der Bestätigungsseite in den dataLayer, zum Beispiel als transaction_id beim Ereignis purchase. Eine Variable im Google Tag Manager liest diesen Wert aus, und der Tag für den Meta Pixel übergibt ihn als eventID. Auf der Serverseite nutzt die Conversions API dieselbe Bestellnummer als event_id. So stammen beide IDs aus derselben Quelle und können nicht auseinanderlaufen. Bei Formularen schreibst du die erzeugte ID beim Absenden in den dataLayer und in ein verstecktes Feld, damit der Server sie mit der Anfrage erhält. Teste jede Änderung in der Vorschau des Google Tag Managers, bevor du sie veröffentlichst.

Passend dazu: Cross-Domain-Tracking in GA4 richtig einrichten

Deduplizierung im Events Manager prüfen

Ob die Conversions-API-Deduplizierung funktioniert, prüfst du im Events Manager bei deiner Datenquelle. In der Übersicht zeigt Meta je Ereignis, über welche Wege es ankommt und ob Browser- und Serverereignisse zusammengeführt werden. Gibt es Probleme, erscheinen dort Hinweise, etwa zu fehlenden oder abweichenden IDs. Für einen gezielten Test öffnest du den Bereich zum Testen von Ereignissen, rufst deine Seite von dort aus auf und machst eine Testbestellung. Mit einem Testcode erscheinen auch Serverereignisse in dieser Ansicht. Du solltest für den Kauf zwei Einträge sehen, einen vom Browser und einen vom Server, mit gleicher ID, und einen Hinweis, dass sie dedupliziert wurden.

Ergänzend lohnt der Vergleich mit der Wirklichkeit. Lege für einen abgeschlossenen Zeitraum die Zahl der Käufe im Werbeanzeigenmanager neben die Bestellungen im Shop. Meta ordnet nicht jeden Kauf einer Anzeige zu, deshalb sollte die Zahl darunter liegen. Liegt sie deutlich darüber, ist Doppelzählung der wahrscheinlichste Grund.

Typische Fehler bei doppelten Events in Meta

Diese Fehler begegnen dir in der Praxis am häufigsten. Jeder davon führt dazu, dass Meta Ereignisse doppelt zählt oder echte Ereignisse verwirft:

• Unterschiedliche IDs: Der Pixel erzeugt eine zufällige ID, der Server nutzt die Bestellnummer.
• Nur eine Quelle mit ID: Der Server sendet event_id, der Pixel nicht, oder umgekehrt.
• Abweichender Name: Der Pixel sendet Purchase, der Server purchase oder einen eigenen Namen.
• Zusätzliche Quelle: Ein Plugin oder die Meta-App des Shopsystems sendet parallel einen eigenen Pixel ohne passende ID.
• Neue ID beim Neuladen: Die Bestellbestätigung erzeugt bei jedem Aufruf eine neue ID, sodass ein Neuladen als neuer Kauf zählt.
• Zu späte Serverereignisse: Der Server meldet Käufe gesammelt erst nach Tagen, außerhalb des Zeitfensters für die Zusammenführung.

Der Fall mit dem Neuladen zeigt, warum die Bestellnummer als ID besser ist als eine Zufallszahl. Mit einer neuen ID bei jedem Aufruf sieht jedes Neuladen der Bestätigungsseite für Meta wie ein neuer Kauf aus. Am sichersten ist es, das Kauf-Ereignis pro Bestellung nur einmal auszulösen, etwa indem der Shop sich merkt, dass die Bestellung schon gemeldet wurde. Prüfe außerdem, ob die Einwilligung auf beiden Wegen gleich behandelt wird. Die Conversions API sollte nur senden, wenn der Besucher auch dem Pixel zugestimmt hat. Dieser Artikel ist keine Rechtsberatung, aber ein Server, der unabhängig vom Banner sendet, ist ein Fehler, den du beheben solltest.

Passend dazu: Consent Mode: Warum nach der Zustimmung Daten fehlen

Beispiel: kleiner Onlineshop mit doppeltem Umsatz

Ein Shop für Kaffeezubehör sieht im Werbeanzeigenmanager einen ROAS, der viel zu gut wirkt. Der Umsatz aus Meta liegt sogar über dem Gesamtumsatz des Shops. Im Events Manager steht beim Ereignis Purchase ein Hinweis, dass Browser- und Serverereignisse nicht dedupliziert werden. Die Testbestellung zeigt, warum: Der Pixel im Google Tag Manager sendet als eventID eine zufällige Zeichenfolge, die Meta-App des Shopsystems sendet über die Conversions API die Bestellnummer. Dazu kommt ein zweiter Pixel aus einem älteren Plugin, der ganz ohne ID sendet. Die Lösung: Das alte Plugin wird entfernt, der Pixel im Google Tag Manager liest die Bestellnummer aus dem dataLayer und nutzt sie als eventID. Nach der Korrektur zeigt der Testbereich für jeden Kauf einen Browser- und einen Servereintrag mit derselben ID, einer davon als dedupliziert markiert, und der Umsatz im Werbeanzeigenmanager liegt wieder unter dem des Shops.

Pixel und Conversions API sauber einrichten lassen

Wenn du Pixel und Conversions API ohne Doppelzählung betreiben willst, richtet Trackum beides für dich ein. Die Meta Conversions API gibt es als Extra für 50 € zzgl. MwSt.: Ereignisse gehen zusätzlich zum Pixel vom Server an Meta, nur mit Einwilligung und ohne doppelte Zählung. Der Pixel selbst kommt als Werbeplattform ebenfalls für 50 € dazu, mit Conversion-Tracking im Google Tag Manager. Ob der Meta Pixel auf deiner Seite schon vor der Einwilligung sendet oder Seitenaufrufe doppelt zählt, zeigt dir vorher der Gratis-Check von Trackum. Käufe und Serverereignisse prüft er nicht, dafür ist die Testbestellung im Events Manager da.