GA4 „funktioniert“ im Shop fast immer: Diagramme werden angezeigt, Sitzungen laufen ein. Das Audit beginnt mit einer anderen Frage: Sagen die E-Commerce-Events die Wahrheit? Jeder Funnel, jede Analyse und jede Kampagne, die auf GA4-Conversions optimiert, ist genau so gut wie die Implementierung dahinter. Dieser Leitfaden ist eine Audit-Checkliste: vollständige Events, typische Fehler, Abdeckung gegenüber den tatsächlichen Bestellungen und eine Validierungsroutine.
Checkliste
GA4-E-Commerce-Events: das Set, das funktionieren muss
Die Customer Journey in GA4 besteht aus Standard-Events, deren Namen in der Google-Dokumentation festgelegt sind. Das Audit beginnt mit der Prüfung, ob alle gesendet werden und welche Parameter sie enthalten:
| Event | Wann es ausgelöst wird | Was es enthalten muss |
|---|---|---|
| view_item_list | Anzeige einer Produktliste / Kategorie | items mit item_id |
| view_item | Aufruf der Produktseite | items, value, currency |
| add_to_cart | Hinzufügen zum Warenkorb | items mit Menge und Preis |
| begin_checkout | Start des Bestellvorgangs | items, value |
| add_payment_info | Auswahl der Zahlungsart | items, payment_type |
| purchase | einmal pro bezahlter Bestellung | transaction_id, value, currency, items |
Zwei Regeln gelten vor allem anderen: Standardnamen (Eigenkreationen wie add_to_basket fließen weder in die E-Commerce-Berichte noch in die Conversion-Modelle ein) und einheitliche item_id, die mit den IDs im Shopsystem und im Produktfeed übereinstimmen. Ohne Letzteres lässt sich das Verhalten nicht konkreten Produkten zuordnen, und darauf baut die gesamte Funnel-Analyse auf, die im Leitfaden zur Verknüpfung von GA4-Daten mit dem Umsatz beschrieben ist.
Typische Fehler
Fünf typische Fehler bei GA4-Implementierungen in Shops
Dieselben Fehler tauchen in einem Shop nach dem anderen auf, unabhängig von der Plattform. Notizen aus Audits:
purchase nur auf der Danke-Seite
Nach einer Zahlung mit Weiterleitung kehrt ein Teil der Kunden nie dorthin zurück. Die Bestellung existiert, das Event nicht. Die Abdeckung sinkt unbemerkt und ungleichmäßig.
Fehlende oder doppelte transaction_id
Ohne ID keine Deduplizierung: Eine neu geladene Danke-Seite zählt die Bestellung ein zweites Mal. Die Anzahl der Events muss der Anzahl eindeutiger Transaktionen entsprechen.
value mal brutto, mal netto
Ein purchase-Wert, der Steuern und Versand je nach Template unterschiedlich enthält, verzerrt den Umsatz in GA4 nach oben oder unten. Legen Sie eine Definition fest und prüfen Sie sie mit einer Testbestellung.
item_id passt nicht zum Shop
GA4 sendet die SKU der Variante, der Shop meldet die Produkt-ID, der Feed wieder etwas anderes. Drei Systeme, drei Wörterbücher und keine gemeinsame Analyse pro Produkt.
Eigene Event-Namen statt Standardnamen
Die Events funktionieren, heißen aber anders. Die E-Commerce-Berichte bleiben deshalb leer, und den Conversion-Modellen fehlen die Daten.
Kernmethode
Abdeckung: purchase mit Shop-Bestellungen vergleichen
Der aussagekräftigste Test der Implementierung kommt ohne Blick in den Code aus: Stellen Sie Anzahl und Wert der purchase-Events den bezahlten Bestellungen aus dem Shopsystem gegenüber, Zeitraum für Zeitraum. Diese eine Kennzahl (die Abdeckung) zeigt, ob man den Daten trauen kann (Beispieldaten, Shop für Nahrungsergänzungsmittel):
Abdeckung: purchase in GA4 / bezahlte BestellungenShop für Nahrungsergänzungsmittel · Beispieldaten
Woche 3 liegt an der Implementierung, nicht an den Kunden: Nach dem Wechsel des Zahlungsanbieters kehrte ein Teil der Kunden nicht mehr auf die Danke-Seite zurück. Ohne Abdeckungs-Monitoring hätte diese Woche wie „schwächerer Traffic“ ausgesehen und zu falschen Budgetentscheidungen geführt.
Eine gewisse Differenz ist normal: Skriptblocker, fehlende Einwilligungen und ungewöhnliche Zahlungswege kosten immer einige Prozent. Alarmzeichen ist nicht die Zahl selbst, sondern eine Veränderung des Niveaus: Eine seit Monaten stabile Abdeckung, die plötzlich sinkt, bedeutet einen Messfehler. Dieselbe Logik gilt für Werte: Summe von value aus purchase gegenüber dem Umsatz aus bezahlten Bestellungen.
Das Shopsystem zeigt, wie viel Sie tatsächlich verkauft haben. GA4 zeigt, wie viel davon es sieht. Der Audit sorgt dafür, dass sich die zweite Zahl nicht von der ersten löst.
Routine
Validierung Schritt für Schritt: Testbestellung und DebugView
Der qualitative Audit erfolgt manuell im Live-Shop:
DebugView aktivieren und Customer Journey durchlaufen
Von der Produktliste über die Produktseite und den Warenkorb bis zur bezahlten Testbestellung. Jeder Schritt muss sein Event in Echtzeit in DebugView anzeigen.
Parameter jedes Events prüfen
Array items mit korrekter item_id, Preis und Menge; bei purchase zusätzlich transaction_id, value und currency. Vergleichen Sie value mit dem Bestellbetrag und der festgelegten Definition (brutto oder netto, mit oder ohne Versand).
Grenzfälle testen
Zahlung mit Weiterleitung, Neuladen der Danke-Seite, Rückkehr über den Browserverlauf. Genau hier entstehen Lücken und Duplikate, nicht im Idealablauf.
Dauerhaftes Abdeckungs-Monitoring einrichten
Wöchentliche Gegenüberstellung von purchase und bezahlten Bestellungen (Anzahl und Wert). Ein einmaliger Audit verliert seine Gültigkeit bei der ersten Änderung an Template, Plugin oder Zahlungsanbieter.
Reales Risiko
Eine fehlerhafte Implementierung schadet mehr als nur den Berichten. Google-Ads-Kampagnen lernen aus GA4-Events; eine Lücke bei purchase bedeutet weniger Conversion-Signale, schlechtere Optimierung und spürbar teurere Bestellungen. Wie Abweichungen zwischen Werbeplattformen und Shop entstehen, erklärt der Leitfaden zu Conversions und Attribution.
DataOrganizer
Wie DataOrganizer die GA4-Datenqualität überwacht
DataOrganizer ruft GA4-Events und parallel die Bestellungen aus dem Shopsystem ab, sodass die Abdeckung direkt aus den Daten berechnet wird, ohne manuelle Exporte: Anzahl und Wert von purchase gegenüber bezahlten Bestellungen, Tag für Tag. Zusätzlich meldet die automatische Anomalieerkennung plötzliche Veränderungen, bevor jemand einen Bericht öffnet:
Abdeckung von purchase in den letzten Wochen:
| Woche | purchase GA4 | Bezahlte Bestellungen | Abdeckung Anzahl | Abdeckung Wert |
|---|---|---|---|---|
| 18.08.–24.08. | 418 | 446 | 94% | 95% |
| 25.08.–31.08. | 289 | 401 | 72% | 70% |
| 01.09.–07.09. | 437 | 459 | 95% | 96% |
In der Woche vom 25.08. bis 31.08. fiel die Abdeckung auf 72% und normalisierte sich nach dem 01.09. wieder, während sich die Zahl der bezahlten Bestellungen im Shop nur geringfügig änderte (401 gegenüber 446 und 459 in den benachbarten Wochen). Der Verlust betrifft also die Messung. Der Rückgang fällt zeitlich mit dem Wechsel des Zahlungsanbieters zusammen; die wahrscheinlichste Ursache ist eine Zahlung mit Weiterleitung ohne Rückkehr auf die Danke-Seite (per Testbestellung zu bestätigen). Die GA4-Berichte dieser Woche weisen zu niedrige Umsätze aus; nutzen Sie für Vergleiche die Shopdaten.
Das Wichtigste
Ein GA4-Audit funktioniert nur als Routine. Qualitativ: Testbestellung mit DebugView nach jeder Änderung im Shop. Quantitativ: wöchentlich die Abdeckung von purchase gegenüber bezahlten Bestellungen. DataOrganizer übernimmt den zweiten Teil automatisch, weil beide Quellen nebeneinander vorliegen.
FAQ
Häufige Fragen zum GA4-Audit im Onlineshop
Welche E-Commerce-Events braucht ein Onlineshop in GA4?
Den Standardpfad: view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info und purchase, jeweils mit dem Array items, und purchase zusätzlich mit transaction_id, value und currency. Die Namen müssen den Standards der Google-Dokumentation entsprechen; E-Commerce-Berichte erkennen eigene Erfindungen nicht.
Warum zeigt GA4 weniger Bestellungen als der Shop?
Meist, weil purchase nur auf der Danke-Seite ausgelöst wird (ein Teil der Kunden kehrt nach einer Zahlung mit Weiterleitung nicht dorthin zurück), wegen Skriptblockern und fehlender Einwilligungen. Einige bis etwa fünfzehn Prozent Differenz sind normal; ein plötzlicher Abfall der Abdeckung ist ein Messfehler, keine Verhaltensänderung der Kunden.
Was verursacht doppelte purchase-Events?
Neuladen oder erneutes Öffnen der Danke-Seite, wenn transaction_id fehlt. Eine korrekte Implementierung sendet purchase einmal pro Bestellung mit eindeutiger ID; der Audit vergleicht die Anzahl der Events mit der Anzahl eindeutiger IDs.
Wie prüft man die Implementierung auf Korrektheit?
Qualitativ: Testbestellung mit DebugView und Kontrolle der Parameter jedes Events, inklusive Grenzfällen (Zahlungsweiterleitungen, Neuladen). Quantitativ: Abdeckung von Anzahl und Wert der purchase-Events gegenüber bezahlten Shopbestellungen, laufend statt einmalig überwacht.
Wie hilft DataOrganizer dabei?
DataOrganizer hält GA4-Events und Shopbestellungen nebeneinander, sodass die Abdeckung automatisch auf Tagesbasis berechnet wird (Anzahl und Wert von purchase gegenüber bezahlten Bestellungen), und die Anomalieerkennung meldet plötzliche Veränderungen in den Daten. Die Frage „Erfasst GA4 alle Bestellungen?“ wird in einer Minute mit Zahlen beantwortet, einschließlich des Zeitraums, in dem den Daten nicht zu trauen ist.
Spickzettel zum gesamten Leitfaden
GA4-Audit in drei Ebenen
1. Vollständige Events mit Standardnamen. Pfad von view_item bis purchase, mit items, transaction_id, value und currency. Alles andere baut darauf auf.
2. Abdeckung als dauerhafter Vertrauensindikator. Anzahl und Wert von purchase im Vergleich zu den bezahlten Bestellungen aus dem Shop, Woche für Woche. Eine Niveauverschiebung ist ein Alarmsignal für die Implementierung, bevor daraus eine falsche Budgetentscheidung wird.
3. Validierung nach jeder Änderung. Eine Testbestellung mit DebugView nach jeder Änderung am Template, an einem Plugin oder beim Zahlungsanbieter. DataOrganizer schließt den Kreis: Abdeckung und Anomalien werden automatisch berechnet, weil GA4- und Shopdaten nebeneinander liegen.
DataOrganizer · GA4 unter ständiger Kontrolle
Verbinden Sie GA4 und Ihr Shopsystem: Die täglichen purchase-Summen werden mit den bezahlten Bestellungen abgeglichen, und Anomalien in den Daten werden automatisch gemeldet. Demokonto sofort verfügbar, Sie zahlen nur für verbundene Datenquellen.
