Event-Deduplizierung: Wann Browser und Server doppelt zählen

Nach der Umstellung auf Server-Side Tracking sieht das Werbekonto plötzlich besser aus als der Shop: 120 Käufe in Meta, 80 Bestellungen im Backend. Was nach Erfolg aussieht, ist meist ein Konfigurationsfehler. Ein Kauf wurde zweimal gemeldet – einmal aus dem Browser, einmal vom Server – und die Plattform hat beide Meldungen gezählt.

Ob das passiert, hängt von zwei Dingen ab: ob die Plattform überhaupt zwei Quellen erwartet, und ob beide Meldungen eine gemeinsame Kennung tragen. Beides ist von Plattform zu Plattform verschieden. Wer das Vorgehen von Meta auf alle anderen Kanäle überträgt, baut sich Doppelzählungen ein.

Was Deduplizierung eigentlich macht

Bei vielen Plattformen ist das empfohlene Setup ein Parallelbetrieb: Das Browser-Tag (Pixel, Insight Tag, UET) bleibt aktiv, zusätzlich sendet der Server-Container dasselbe Ereignis über die jeweilige Conversions-API. Der Gedanke dahinter: Was der Browser verliert – durch Werbeblocker, Safari-Einschränkungen oder abgebrochene Seitenaufrufe –, liefert der Server nach.

Damit daraus keine doppelten Conversions werden, braucht jede Meldung einen Deduplizierungsschlüssel. Das ist ein Wert, der für genau dieses eine Ereignis erzeugt und sowohl an das Browser-Tag als auch an das Server-Tag übergeben wird. Erkennt die Plattform denselben Schlüssel (oft in Kombination mit dem Ereignisnamen) aus beiden Quellen, behält sie eine Meldung und verwirft die andere.

Drei Punkte entscheiden, ob das funktioniert:

• Der Schlüssel muss identisch sein. Ein abweichendes Präfix, ein anderer Datentyp oder ein leerer Wert auf einer Seite – und die Plattform sieht zwei verschiedene Ereignisse.
• Der Ereignisname muss übereinstimmen, wo die Plattform ihn mitprüft. Purchase im Browser und purchase vom Server sind für Meta nicht dasselbe.
• Das Zeitfenster muss passen. Jede Plattform gleicht nur innerhalb eines bestimmten Zeitraums ab. Kommt die Server-Meldung deutlich später, greift die Deduplizierung womöglich nicht mehr.

Die Plattformen im Überblick

Die folgende Tabelle zeigt, wie die gängigen Werbeplattformen mit Browser- und Server-Ereignissen umgehen. Für Shops im DACH-Raum sind vor allem Meta, Google Ads, Pinterest und Microsoft Ads relevant; die übrigen Kanäle der Vollständigkeit halber.

Plattform	Deduplizierung?	Schlüssel	Browser-Tag behalten?
Meta (Facebook, Instagram)	Ja	event_id + event_name	Ja
Google Ads	Nein	–	Nein, pausieren
Pinterest	Ja	event_id + event_name	Ja
Microsoft Ads (Bing)	Ja	eventId	Ja
LinkedIn	Ja	event_id	Ja
Snapchat	Ja	client_dedup_id oder transaction_id	Ja
Reddit	Ja	conversion_id	Ja

Die Bezeichnungen der Felder unterscheiden sich, das Prinzip ist meist gleich. Die eine große Ausnahme ist Google Ads.

Meta, Pinterest, Microsoft & Co.

• Browser-Tag bleibt aktiv
• Server-Tag sendet zusätzlich
• Gemeinsame Ereignis-ID gleicht ab

Google Ads

• Keine Deduplizierung
• Web-Tag pausieren
• Genau eine Quelle

Meta: der bekannteste Fall

Meta ist die Plattform, bei der Deduplizierung am häufigsten Thema ist. Pixel und Conversions API laufen parallel, abgeglichen wird über event_id und event_name. Meta bietet zwar auch einen Abgleich über Browser-ID (fbp) und external_id an, empfohlen ist aber der Weg über die Ereignis-ID.

Wichtig für die Auswertung: Erkennt Meta ein Duplikat, behält es in der Regel die Browser-Meldung. Der Server liefert dann vor allem dort Mehrwert, wo der Browser nichts gemeldet hat. Wie Sie das Setup im Shop konkret aufbauen, beschreibt der Beitrag Meta Conversions API für Shopify einrichten; ob die Abgleiche funktionieren, zeigt der Events Manager.

Google Ads: abschalten statt abgleichen

Google Ads dedupliziert Browser- und Server-Meldungen nicht auf diese Weise. Wer Conversions über den Server-Container sendet, pausiert die entsprechenden Conversion-Tags im Web-Container – oder richtet sie dort gar nicht erst ein.

Das klingt banal, ist aber eine der häufigsten Ursachen für doppelt gezählte Conversions nach einer Migration: Das neue Server-Tag läuft, das alte Web-Tag wurde nie deaktiviert. Gleiches gilt für Conversions, die zusätzlich noch über ein Plugin, eine Shop-App oder einen GA4-Import entstehen. Prüfen Sie in den Conversion-Aktionen, aus welchen Quellen Käufe gezählt werden und welche davon als primär gelten. Mehr zur Datenqualität in Google Ads auf der Seite zu Enhanced Conversions.

Pinterest und Microsoft Ads

Beide orientieren sich am Modell von Meta: Browser-Tag bleibt, Server-Tag kommt dazu, abgeglichen wird über eine gemeinsame Ereignis-ID.

• Pinterest nutzt event_id und event_name. Laut Pinterest werden Duplikate innerhalb von 48 Stunden entfernt – die Bereinigung ist also nicht unbedingt sofort im Reporting sichtbar.
• Microsoft Ads hat die serverseitige Schnittstelle mit Deduplizierung über eventId erst vergleichsweise spät eingeführt. Haben Sie Server-Side Tracking schon länger im Einsatz, lohnt ein Blick, ob Microsoft Ads bislang nur über das UET-Tag im Browser läuft und sich jetzt ergänzen lässt.

LinkedIn, Snapchat und Reddit

Für B2C-Shops seltener, aber mit Eigenheiten, die man kennen sollte:

• LinkedIn verlangt für Insight Tag und Conversions API jeweils eine eigene Conversion-Regel. Im Kampagnen-Manager stehen dann zwei Conversions nebeneinander. Abgeglichen wird über event_id; bei Duplikaten bevorzugt LinkedIn die Browser-Meldung und zieht sie von der API-Zahl ab. Sinkt diese Zahl, ist das kein Fehler, sondern die Deduplizierung bei der Arbeit. Nicht verwechseln: Die Conversion-ID ordnet das Ereignis einer Regel zu, die event_id identifiziert das einzelne Ereignis.
• Snapchat bietet zwei Schlüssel mit unterschiedlichen Zeitfenstern: client_dedup_id gleicht innerhalb von 48 Stunden ab, transaction_id innerhalb von 30 Tagen. Welcher passt, hängt davon ab, wie viel Zeit zwischen Browser- und Server-Meldung liegen kann.
• Reddit empfiehlt eine conversion_id, die in Browser- und Server-Tag gleich gesetzt wird. Bei Duplikaten verwirft Reddit die Meldung mit weniger Zusatzdaten oder die spätere.

Woher die Ereignis-ID im Shop kommt

Die Plattformen schreiben vor, dass ein Schlüssel übereinstimmen muss – nicht, woher er kommt. Bewährt haben sich zwei Ansätze:

1. Für Käufe die Bestellnummer aus Shopify oder WooCommerce. Sie ist im Browser auf der Bestätigungsseite und im Backend gleichermaßen verfügbar und eindeutig.
2. Für alle anderen Ereignisse eine erzeugte ID, die im dataLayer entsteht und von dort an das Web-Tag und über den Server-Container weitergereicht wird.

Problematisch wird es, wenn mehrere Systeme parallel senden: etwa die offizielle Meta-App von Shopify oder ein WooCommerce-Plugin mit eigener CAPI-Anbindung, und zusätzlich der eigene Server-Container. Erzeugen beide ihre IDs unabhängig voneinander, kann keine Plattform sie zusammenführen. Entscheiden Sie sich pro Plattform für genau einen serverseitigen Weg. Bei Shopify kommt hinzu, dass Customer Events in einer abgeschotteten Umgebung laufen – Details dazu im Beitrag zu Shopify Web Pixels und Customer Events.

So prüfen Sie Ihr Setup

Ein kurzer Check pro Plattform genügt, um die gröbsten Fehler zu finden:

• Zahlen abgleichen. Käufe in der Plattform gegen Bestellungen im Backend. Liegt die Plattform deutlich darüber, ist doppelte Zählung die erste Vermutung.
• Vorschaumodus nutzen. Im Web- und im Server-Container prüfen, ob beide Meldungen denselben Schlüssel und denselben Ereignisnamen tragen.
• Diagnosen der Plattform lesen. Meta weist deduplizierte Ereignisse im Events Manager aus; andere Plattformen zeigen zumindest, aus welcher Quelle Conversions stammen.
• Altlasten suchen. Gibt es noch Web-Tags, Plugins oder Apps, die dieselben Conversions senden?

Eine ausführlichere Prüfliste für den gesamten Tracking-Stack finden Sie in der Tracking-Audit-Checkliste.

Ein Hinweis zum Consent: Deduplizierung ist eine technische Frage. Ob ein Ereignis überhaupt aus Browser oder Server gesendet werden darf, hängt von der Einwilligung ab und erfordert eine rechtliche Einschätzung für Ihren Shop.

Fazit

Die wichtigste Regel lautet: Schließen Sie nicht von Meta auf alle anderen Plattformen. Die meisten Kanäle wollen Browser und Server parallel und einen gemeinsamen Schlüssel, Google Ads will genau eine Quelle. Wer das pro Plattform sauber festlegt und die Ereignis-ID an einer Stelle im Shop erzeugt, bekommt Zahlen, die zum Backend passen – und Kampagnen, die nicht auf Phantom-Conversions optimieren.

Wie wir das für Shopify-Shops umsetzen, lesen Sie unter Shopify Server-Side Tracking; Begriffe wie CAPI oder sGTM erklärt das Glossar. Für Ihr Setup: Erstgespräch anfragen.