Thema: Tracking-Qualität

Doppelte Käufe in GA4 - warum sie entstehen und wie der Auditor sie findet

Bernhard Prange · 2026-05-19 · 5 Min. Lesezeit

In den GA4-E-Commerce-Reports erscheint plötzlich der doppelte Umsatz für dieselbe Bestellung. Drei Wochen später fragt das Reporting-Team, warum die Order-Zahl nicht zum Shop-Backend passt. Doppelte purchase-Events sind ein klassischer GTM-Bug - und einer, den der Auditor in unter einer Minute auffinden kann.

Was im Code passiert

Der Check in app/queries/checks/duplicate_events.sql gruppiert Events in Sekunden-Buckets und markiert mehrfach gefeuerte Events innerhalb derselben Session:

duplicates_marked AS (
  SELECT *,
  COUNT(*) OVER (
  PARTITION BY session_id, user_pseudo_id, event_name, second_bucket
  ) AS duplicate_count,
  ROW_NUMBER() OVER (
  PARTITION BY session_id, user_pseudo_id, event_name, second_bucket
  ORDER BY event_timestamp_micros ASC
  ) AS occurrence_number
  FROM events_with_bucket
)

Die Bucket-Berechnung erfolgt vorher über TIMESTAMP_SECONDS(event_timestamp_micros / 1000000). Mehrere purchase-Events innerhalb derselben Sekunde, gleicher Session und gleicher user_pseudo_id werden als Duplikat markiert.

Schwellenwerte

Typische Ursachen

• Double-Click am Checkout-Button - Der Nutzer klickt schnell zweimal, beide Klicks lösen einen Ajax-Call innerhalb derselben Sekunde aus.
• GTM-Trigger feuert mehrfach - Der purchase-Trigger ist nicht auf Once per Page gesetzt, oder ein History-Change-Listener feuert ihn zusätzlich noch einmal.
• Plugin-Konflikt - Ein E-Commerce-Plugin (z. B. WooCommerce GA4-Plugin) sendet den Purchase parallel zu einem Custom-GTM-Tag.
• Browser-Retry - Bei Netzwerk-Latenz wiederholt der Browser den Request, der Server verarbeitet beide Calls.
• Universal-Analytics-Migration unvollständig - Das alte UA-Snippet läuft noch mit, parallel zum neuen GA4-Tag.

So zeigt's der Auditor

Die Sektion create_duplicate_transactions_section in app/components/dashboard/sections/ecommerce_transactions.py liefert:

• Warnung mit Anzahl und Umsatz-Impact - wie viele Käufe sind doppelt, wie viel Umsatz hängt daran?
• Summary-Karten für Duplikat-Anzahl und betroffene Transaction-IDs.
• Detail-Tabelle mit konkreten transaction_id, event_timestamp, purchase_revenue und der Anzahl Wiederholungen.

Damit lässt sich nicht nur das Ob, sondern auch das Wo eingrenzen - oft sind Duplikate auf wenige Trigger-Konfigurationen zurückführbar.

So verhinderst du sie

1. transaction_id als Dedup-Key in GA4 nutzen. GA4 selbst dedupliziert purchase-Events mit identischer transaction_id für eine begrenzte Zeit, aber nicht zuverlässig - daher solltest du den Bug an der Quelle beheben.
2. GTM-Trigger auf Once per Page setzen und sicherstellen, dass kein parallele History-Change-Listener mit feuert.
3. Plugin-Audit - wenn dein Shop ein dediziertes E-Commerce-Plugin hat, prüfe, ob es Purchases parallel zu deinem Custom-Tracking sendet.
4. Idempotenz im Server-Side-Tagging - wenn dein SST-Setup auf Retries reagiert, sicherstellen, dass identische transaction_id-Calls innerhalb von z. B. 60 Sekunden verworfen werden.
5. Im Auditor unter E-Commerce-Checks nach 24 h erneut prüfen.

Verwandte Themen

• Hilfeseite E-Commerce-Checks im Detail
• Hilfeseite Event-Qualität & PII-Hinweise
• Blog Wenn der gclid da ist - und Google Ads trotzdem nicht

ecommerce duplikate transaction-id gtm