Zum Inhalt springen
EARNST.
EN
Tracking & Compliance

Event-Deduplizierung: Warum Ihre Meta-Conversions doppelt zählen und wie Sie es beheben

Meta Pixel und Conversions API senden dasselbe Event zweimal. Ohne event_id-Matching zählt Meta doppelte Purchases. So funktioniert korrekte Deduplizierung.

EARNST · · 10 min Lesezeit

Das Wichtigste in Kürze

  • Ohne Deduplizierung zählt Meta 30 bis 80 % mehr Conversions als tatsächlich stattfinden
  • event_id ist der einzige verlässliche Deduplizierungsmechanismus zwischen Pixel und CAPI
  • Meta dedupliziert innerhalb eines 48-Stunden-Fensters: identische event_id + event_name = ein Event
  • Google und Meta handhaben Deduplizierung unterschiedlich: Google nutzt transaction_id, Meta nutzt event_id

Meta empfiehlt seit 2023, die Conversions API (CAPI) parallel zum Browser-Pixel einzusetzen. Die Begründung ist stichhaltig: Ad-Blocker blockieren das Pixel bei 15 bis 30 % der Nutzer, Safari ITP begrenzt Cookie-Laufzeiten, und die serverseitige CAPI liefert Daten unabhängig von Browser-Restriktionen. Die Kombination aus Pixel und CAPI maximiert die Datenabdeckung.

Aber "maximiert die Datenabdeckung" heißt auch: jedes Event wird potenziell zweimal gesendet. Einmal vom Pixel im Browser, einmal von der CAPI über den Server. Wenn Meta beide Events als separate Conversions zählt, sehen Ihre Reports 30 bis 80 % mehr Purchases als tatsächlich stattgefunden haben. Ihr ROAS sieht fantastisch aus, Ihr Budget-Planning basiert auf Phantomzahlen.

Die Lösung heißt Event-Deduplizierung. Und sie funktioniert nur, wenn Browser und Server dasselbe Event mit derselben ID senden.

Wie Doppelzählung entsteht

Drei Szenarien, die in fast jedem Setup auftreten:

Szenario 1: Pixel + CAPI ohne event_id. Ein Nutzer kauft. Das Pixel sendet ein Purchase-Event an Meta. Der GTM Server Container sendet dasselbe Purchase-Event über die CAPI an Meta. Meta empfängt zwei Events, hat aber keine Möglichkeit zu erkennen, dass es sich um denselben Kauf handelt. Ergebnis: 2 Conversions statt 1.

Szenario 2: Pixel + CAPI mit unterschiedlicher event_id. Das Pixel generiert eine zufällige event_id. Der Server generiert eine andere zufällige event_id. Meta empfängt zwei Events mit verschiedenen IDs und zählt sie als separate Conversions. Ergebnis: identisch mit Szenario 1.

Szenario 3: Pixel blockiert, CAPI aktiv. Ein Ad-Blocker blockiert das Meta Pixel. Nur die CAPI sendet das Purchase-Event. Meta empfängt ein Event. Ergebnis: korrekt, 1 Conversion. Deduplizierung ist in diesem Fall nicht nötig, aber die event_id schadet nicht.

Das Problem betrifft nur Szenario 1 und 2. Und genau diese Szenarien sind der Normalfall bei Nutzern ohne Ad-Blocker, also bei 70 bis 85 % Ihres Traffics.

Metas Deduplizierungsmechanismus

Meta dedupliziert Events anhand von zwei Feldern:

  1. event_name: Der Name des Events (z.B. Purchase, AddToCart, ViewContent)
  2. event_id: Eine eindeutige ID, die das spezifische Event identifiziert

Die Regel: Wenn Meta innerhalb von 48 Stunden zwei Events mit identischem event_name und identischer event_id empfängt, wird das zweite Event als Duplikat erkannt und verworfen. Es zählt nur das erste.

Anforderungen an die event_id

Die event_id muss:

  • Eindeutig pro Event-Instanz sein. Jeder Kauf braucht eine eigene ID. Zwei verschiedene Käufe dürfen nicht dieselbe ID haben.
  • Identisch zwischen Pixel und CAPI sein. Browser und Server müssen exakt dieselbe ID für denselben Kauf senden.
  • Stabil sein. Kein erneutes Generieren bei Seiten-Reload. Wenn der Nutzer die Danke-Seite zweimal lädt, muss die ID dieselbe bleiben.

Was als event_id taugt

Quelle Beispiel Geeignet?
Shopify Order ID #1042purchase_1042 Ja, stabil und eindeutig
Transaction ID 5312847 Ja, identisch zwischen Browser und Server
Zufällige UUID (pro Client generiert) a3f7c2d-... Nur wenn exakt dieselbe UUID an Pixel UND Server geht
Zufällige UUID (pro Request generiert) b8e1f4a-... (Pixel) vs c9d2e5b-... (Server) Nein, verschiedene IDs = keine Deduplizierung
Timestamp 1711382400 Nein, Pixel und Server haben leicht unterschiedliche Timestamps

Die sicherste Variante: die Shopify Order ID oder Transaction ID als Basis. Diese existiert in beiden Kontexten (Browser-DataLayer und Server-Request) und ist per Definition eindeutig pro Kauf.

Implementierung in Shopify

Schritt 1: event_id im DataLayer

Das purchase-Event im DataLayer enthält bereits die transaction_id. Diese wird als Basis für die event_id verwendet:

dataLayer.push({
  event: 'purchase',
  event_id: 'purchase_' + transactionId,
  ecommerce: {
    transaction_id: transactionId,
    value: orderValue,
    currency: 'EUR',
    items: [...]
  }
});

Das Präfix purchase_ verhindert Kollisionen, falls Sie dieselbe Transaction-ID auch für andere Events verwenden (z.B. refund_1042).

Schritt 2: event_id im Pixel

Das Meta Pixel im GTM liest die event_id aus dem DataLayer:

fbq('track', 'Purchase', {
  value: NaN,
  currency: NaN,
  content_ids: NaN,
  content_type: 'product'
}, {
  eventID: NaN
});

Der vierte Parameter von fbq('track', ...) akzeptiert ein Options-Objekt mit eventID. Beachten Sie die Schreibweise: eventID (camelCase) im Pixel, event_id (snake_case) in der CAPI.

Schritt 3: event_id in der CAPI

Der GTM Server Container sendet die CAPI-Request. Der Meta-CAPI-Tag im Server Container muss dieselbe event_id verwenden. In der Server-Side-Konfiguration:

  1. Der GA4-Client im Server Container empfängt den Request vom Browser
  2. Die event_id wird als Event-Parameter weitergeleitet
  3. Der Meta-CAPI-Tag liest die event_id und inkludiert sie im CAPI-Request
{
  "data": [{
    "event_name": "Purchase",
    "event_id": "purchase_1042",
    "event_time": 1711382400,
    "user_data": {
      "em": ["hashed_email"],
      "ph": ["hashed_phone"]
    },
    "custom_data": {
      "value": 149.90,
      "currency": "EUR"
    }
  }]
}

Schritt 4: Web Pixel für Checkout-Events

Im Shopify Checkout läuft das Tracking über Web Pixel. Das Web Pixel hat keinen Zugriff auf den Storefront-DataLayer, aber auf Shopifys Standard-Events (checkout_completed). Für die event_id nutzt das Web Pixel die Order-ID aus dem Event-Payload:

analytics.subscribe('checkout_completed', (event) => {
  const orderId = event.data.checkout.order.id;
  const eventId = 'purchase_' + orderId;

  // Pixel-Event mit event_id
  // CAPI erhält dieselbe event_id über den Server
});

Alle Events, die dedupliziert werden müssen

Deduplizierung betrifft nicht nur Purchase. Jedes Event, das sowohl vom Pixel als auch von der CAPI gesendet wird, braucht eine event_id.

Event event_id-Quelle Beispiel
Purchase Transaction ID / Order ID purchase_1042
AddToCart Product ID + Timestamp-Bucket (Minutengenau) atc_7829384_202603251430
InitiateCheckout Checkout Token ic_abc123def456
ViewContent Product ID + Session ID vc_7829384_sess_a3f7c2d
AddPaymentInfo Checkout Token api_abc123def456
Lead Form ID + Submission Timestamp lead_contact_202603251430

Für Events ohne natürliche eindeutige ID (wie ViewContent) ist die Kombination aus Objekt-ID und Session-ID der beste Kompromiss: eindeutig genug für Deduplizierung, aber stabil bei Seiten-Reloads innerhalb derselben Session.

Google vs. Meta: Unterschiedliche Ansätze

Google und Meta handhaben Deduplizierung unterschiedlich. Wenn Sie beide Plattformen nutzen, müssen Sie beide Ansätze implementieren.

Google: transaction_id

Google Ads und GA4 deduplizieren purchase-Events anhand der transaction_id im Ecommerce-Objekt. Die Deduplizierung passiert automatisch: GA4 erkennt, wenn derselbe transaction_id-Wert mehrfach gesendet wird, und zählt den Kauf nur einmal.

Besonderheit: Google dedupliziert nur purchase-Events. Andere Events (wie add_to_cart oder begin_checkout) werden nicht dedupliziert. Das ist in der Regel kein Problem, weil Google diese Events ohnehin nicht als Conversion zählt (außer Sie haben sie explizit als Conversion markiert).

Meta: event_id für alle Events

Meta dedupliziert jedes Event, für das eine event_id gesendet wird. Das betrifft alle Standard-Events und Custom Events. Ohne event_id findet keine Deduplizierung statt. Metas Ansatz ist expliziter: Sie müssen die Deduplizierung aktiv implementieren, bekommen dafür aber volle Kontrolle über alle Event-Typen.

Vergleich

Aspekt Google Meta
Deduplizierungs-Key transaction_id event_id
Automatisch? Ja, für Purchases Nein, muss explizit gesendet werden
Betroffene Events Nur Purchase Alle Events mit event_id
Zeitfenster Nicht dokumentiert (Stunden bis Tage) 48 Stunden
Ohne Deduplizierung Doppelte Purchases in GA4 Doppelte Conversions in Meta Ads

Debugging und Validierung

Meta Events Manager

Der Events Manager zeigt den Deduplizierungsstatus pro Event:

  1. Events Manager > Pixel > Test Events
  2. Event auswählen (z.B. Purchase)
  3. Prüfen: "Event received from" zeigt "Browser" und "Server"
  4. Prüfen: "Event ID" zeigt denselben Wert für beide Quellen
  5. Status: "Deduplicated" oder "Not deduplicated"

Häufige Fehler

event_id fehlt in einem der beiden Kanäle. Das Pixel sendet eventID, aber der CAPI-Request enthält keine event_id. Meta kann nicht deduplizieren.

Schreibweise falsch. Pixel: eventID (camelCase im Options-Objekt). CAPI: event_id (snake_case im JSON-Body). Verwechslung führt dazu, dass das Feld ignoriert wird.

event_id wird pro Request generiert statt pro Event-Instanz. Wenn Pixel und Server jeweils eine neue UUID generieren, sind die IDs verschieden. Die ID muss vom Event kommen (z.B. Order ID), nicht vom Sendemechanismus.

Zeitversatz überschreitet 48 Stunden. Wenn der CAPI-Request erst 3 Tage nach dem Pixel-Event gesendet wird, liegt er außerhalb des Deduplizierungsfensters. In Shopify-Setups mit Server-Side GTM ist der Zeitversatz normalerweise unter einer Sekunde.

Monitoring: Deduplizierungsrate messen

Um sicherzustellen, dass die Deduplizierung dauerhaft funktioniert, tracken Sie diese Metriken:

Meta Events Manager > Diagnostics: Zeigt Warnungen bei fehlender oder fehlerhafter Deduplizierung. Prüfen Sie diese Seite wöchentlich.

Conversion-Vergleich: Vergleichen Sie die Anzahl der Purchase-Events in Meta mit den tatsächlichen Bestellungen in Shopify. Das Verhältnis sollte bei 0.95 bis 1.05 liegen (leichte Abweichungen durch Consent-Lücken und Timing). Ein Verhältnis über 1.2 deutet auf Deduplizierungsprobleme hin.

GA4 Custom Dimension: Senden Sie die event_id als Custom Dimension in GA4. So können Sie in BigQuery prüfen, ob dieselbe event_id mehrfach vorkommt.

Fazit

Event-Deduplizierung ist keine optionale Optimierung. Ohne sie übertreibt Meta Ihre Conversions um 30 bis 80 %, Ihr ROAS sieht besser aus als er ist, und Ihr Budget-Planning basiert auf falschen Daten. Smart Bidding bei Meta optimiert auf überhöhte Conversion-Zahlen und allokiert Budget falsch.

Die Implementierung ist nicht komplex, aber sie erfordert Sorgfalt: eine stabile event_id aus dem DataLayer, korrekte Weitergabe an Pixel und CAPI, und regelmäßige Validierung im Events Manager.

Sie wollen sicherstellen, dass Ihre Meta-Conversions korrekt zählen? In unserem Tracking-Setup ist Event-Deduplizierung für alle Plattformen Standard.

Unsere Leistung

Tracking & Datenarchitektur

20–40 % Ihrer Conversion-Daten fehlen. Server-Side Tracking, Consent Mode v2, 18+ Events und Engagement Scoring holen sie zurück.

Details ansehen