Richtig implementiertes GA4-E-Commerce-Tracking liefert produktgenaue Umsatzdaten, einen vollständigen Kauf-Funnel und deduplizierte Transaktionen. Voraussetzung dafür sind drei Dinge: ein sauber befülltes items-Array, eine funktionierende transaction_id für die purchase-Deduplizierung und eine Prüfung über die DebugView vor dem Livegang. Standardreports zeigen die Zahlen dann mit bis zu 24 Stunden Verzögerung an, Echtzeitdaten sieht man sofort. Wer diese Basis nicht sauber setzt, bekommt verzerrte Umsatzberichte und keine belastbare Grundlage für Google Ads oder Merchant Center.

Kurz gesagt:

  • Wenn das items-Array nicht sauber befüllt ist und die transaction_id fehlt oder doppelt ist, liefert GA4 verzerrte Umsatzdaten und erkennt Doppelkäufe nicht.
  • Nur das Messen des purchase-Events reicht nicht; es ist essenziell, alle empfohlenen E-Commerce-Events zu erfassen, um den gesamten Einkaufsfunnel sichtbar zu machen.
  • Fehlerhafte DataLayer-Implementierung, insbesondere das Fehlen eines Null-Pushs vor jedem Event, führt zu falschen Umsatzzahlen durch Datenmischung aus alten und neuen Werten.
  • Die korrekte Überprüfung des Tracking läuft über die DebugView und Netzwerkanalyse, um sicherzustellen, dass alle Parameter wie currency, value und item-Details richtig übertragen werden.
  • Bei komplexen Shops, mehreren Domains oder individuellem Checkout ist die externe Betreuung bei der Implementierung und Wartung des E-Commerce-Trackings sinnvoll, um Datenqualität dauerhaft zu sichern.
Neomarketing
Sauberes GA4-Tracking für bessere Entscheidungen
Neomarketing unterstützt dich mit GA4-Expertise und Data Layer Integration bei datenbasierten E-Commerce-Entscheidungen.

GA4-Unterstützung ansehen

Inhaltsverzeichnis

Welche E-Commerce-Events sollte GA4-Tracking abdecken?

Google Analytics 4 kennt eine feste Liste empfohlener E-Commerce-Events, die den gesamten Einkaufsprozess abbilden. Jedes Event markiert einen Schritt im Funnel, von der ersten Produktliste bis zur abgeschlossenen Bestellung. Wer nur purchase misst und den Rest ignoriert, sieht am Ende nur eine Zahl, aber keinen einzigen Hinweis darauf, wo im Prozess Kunden abspringen.

Die offizielle GA4-Dokumentation listet die Events, die jeder Onlineshop einrichten sollte:

  • view_item_list: wird ausgelöst, wenn eine Liste von Produkten angezeigt wird, etwa eine Kategorieseite oder ein Suchergebnis.
  • select_item: feuert, wenn ein Nutzer aus einer solchen Liste auf ein Produkt klickt.
  • view_item: markiert den Aufruf einer einzelnen Produktdetailseite.
  • add_to_cart: das zentrale Signal für Kaufinteresse, ausgelöst beim Hinzufügen zum Warenkorb.
  • view_cart: wird beim Öffnen der Warenkorbansicht gesendet.
  • remove_from_cart: erfasst, wenn ein Artikel wieder entfernt wird, wichtig für Abbruchanalysen.
  • begin_checkout: markiert den Start des Bestellprozesses.
  • add_shipping_info: feuert, sobald Versandinformationen ausgewählt wurden.
  • add_payment_info: erfasst die Auswahl der Zahlungsmethode.
  • purchase: der Abschluss der Bestellung, das wichtigste Event im gesamten Funnel.
  • refund: bildet Rückerstattungen ab und korrigiert den Umsatz nachträglich.
  • view_promotion und select_promotion: messen Sichtkontakt und Klick auf Werbebanner oder interne Kampagnenflächen.

Jedes dieser Events braucht bestimmte Parameter, damit GA4 die Daten korrekt zuordnet. Auf Event-Ebene gehören currency und value zu den Pflichtfeldern, sobald monetäre Werte im Spiel sind. Google empfiehlt ausdrücklich, currency bei jedem Event zu setzen und nicht nur beim purchase. Ohne diesen Wert kann GA4 den Umsatz nicht korrekt in Berichte übernehmen, selbst wenn die Zahl technisch ankommt.

Auf Artikelebene liefert das items-Array die eigentliche Substanz: item_id, item_name, price und quantity sind die Kernfelder, die in praktisch jedem Event mit Produktbezug vorkommen sollten. Fehlt item_id, kann GA4 den Artikel in produktbezogenen Berichten nicht mehr eindeutig zuordnen, selbst wenn der Name stimmt.

GA4-Artikelparameter und Limits für Dimensionen

Wer mehr will als die Standardfelder, kann bis zu 27 zusätzliche item-scoped Parameter pro Artikel senden, etwa Größe, Farbe oder Lagerort. Für die Auswertung in Berichten müssen diese zusätzlichen Felder allerdings noch als eigene Custom Dimensions in GA4 angelegt werden. Standard-Properties erlauben zehn solcher Dimensionen, GA4-360-Properties bis zu 25. Wer das übersieht, sendet zwar Daten, sieht sie aber nirgends in der Oberfläche wieder.

Wie muss der DataLayer für E-Commerce-Tracking aufgebaut sein?

Die technische Grundlage jedes E-Commerce-Trackings ist der DataLayer, und genau hier passieren die meisten Fehler. Das Problem ist fast immer dasselbe: alte Daten aus einem früheren Event bleiben im DataLayer stehen und mischen sich mit den neuen Werten. TaggingDocs beschreibt genau dieses Verhalten als eine der häufigsten Fehlerquellen bei GTM-Implementierungen.

Die Lösung ist ein festes Muster, das vor jedem einzelnen Event-Push ausgeführt wird:

  1. Zuerst wird das ecommerce-Objekt geleert: window.dataLayer.push({ ecommerce: null });
  2. Direkt danach folgt der eigentliche Event-Push mit dem vollständigen ecommerce-Objekt und allen Parametern.
  3. Für jedes weitere E-Commerce-Event wiederholt sich dieser Zweischritt, ohne Ausnahme.

Ohne den Null-Push kombiniert GTM unter Umständen Felder aus zwei verschiedenen Pushes, etwa den value eines alten Warenkorbstands mit den items eines neuen. Das Ergebnis sind Umsatzzahlen, die auf den ersten Blick plausibel wirken, aber schlicht falsch sind.

Genauso wichtig ist die Typisierung der Werte. value, price und quantity müssen als Zahlen übergeben werden, nicht als Text. Ein value von "49.99" als String wird von GA4 anders verarbeitet als 49.99 als Zahl, und in manchen Fällen fällt der Wert komplett aus dem Bericht. currency folgt dem ISO-4217-Standard, also dreistellige Codes wie EUR oder USD, niemals ein Symbol wie „€“. Und transaction_id muss pro Bestellung eindeutig sein, sonst kann GA4 doppelte Käufe bei Seiten-Reloads oder Zurück-Navigation nicht erkennen und herausfiltern.

Profi-Tipp: Legen Sie sich früh eine feste Namenskonvention für item_id fest, idealerweise identisch mit der SKU aus Ihrem Warenwirtschaftssystem. Das erspart später mühsame Abgleicharbeit zwischen GA4-Berichten und Ihrem Bestellsystem.

Wie richtet man GA4-E-Commerce-Tracking in GTM ein?

Der Google Tag Manager ist für die meisten Shops der praktikabelste Weg, E-Commerce-Events an GA4 zu senden, weil Änderungen ohne Code-Deployment möglich sind. Der Support-Artikel von Google beschreibt den grundlegenden Ablauf für GA4-Event-Tags: Tag anlegen, Event-Namen definieren, Event-Parameter hinzufügen, passenden Trigger setzen, Container veröffentlichen.

Für E-Commerce-Events braucht es zusätzlich zwei Bausteine:

  • Eine Data Layer Variable, die auf das ecommerce-Objekt zeigt, etwa {{dlv - ecommerce}}, um die Werte aus dem DataLayer im Tag verfügbar zu machen.
  • Im GA4-Event-Tag die Checkbox „Send Ecommerce Data“ aktivieren. Ohne diesen Haken werden die items und Werte aus dem DataLayer schlicht nicht mitgesendet, auch wenn der Trigger korrekt feuert.

Bei der Trigger-Strategie gibt es zwei sinnvolle Wege. Der eine: ein Custom Event Trigger pro Event, also ein eigener Trigger für purchase, einer für add_to_cart und so weiter, jeweils gekoppelt an ein eigenes Tag. Der andere, wartungsärmere Weg nutzt einen Regex-Trigger, der auf alle relevanten Event-Namen gleichzeitig reagiert, kombiniert mit einem einzigen GA4-Event-Tag, dessen Event-Name aus der Variable {{Event}} übernommen wird. Das reduziert die Zahl der Tags erheblich und verringert das Risiko, dass bei einem neuen Event ein Tag vergessen wird.

Wer statt GTM direkt mit gtag.js arbeitet, platziert das Basis-Snippet im <head> jeder Seite und ruft die Events dann direkt im Code auf. Ein purchase-Aufruf sieht so aus:

gtag('event', 'purchase', {
  transaction_id: 'T12345',
  value: 59.99,
  currency: 'EUR',
  items: [{
    item_id: 'SKU123',
    item_name: 'Beispielprodukt',
    price: 59.99,
    quantity: 1
  }]
});

Für view_item gilt dasselbe Prinzip, nur ohne transaction_id und mit dem Kontext der jeweiligen Produktseite. Die technische Grundlage dafür beschreibt Google in der Dokumentation zum Einrichten von Events.

Bei gehosteten Shopplattformen lohnt sich ein genauerer Blick auf die automatischen Tracking-Funktionen. Shopify etwa liefert ein eingebautes Pixel-Tracking, das viele Standardevents bereits ohne manuelle Einrichtung abdeckt. Sobald der Checkout aber individuell angepasst wurde oder zusätzliche Parameter wie Rabattcodes im items-Array benötigt werden, reicht die Standardintegration meist nicht mehr aus, und eine eigene GA4-E-Commerce-Tracking-Konfiguration über GTM wird notwendig.

Profi-Tipp: Bauen Sie testweise ein einziges GA4-Event-Tag mit dynamischem Event-Namen, statt für jedes der zwölf Events ein separates Tag zu pflegen. Das spart bei künftigen Änderungen viel Zeit und reduziert Inkonsistenzen zwischen den Tags.

Wie prüft man, ob GA4-E-Commerce-Tracking korrekt läuft?

Bevor irgendein Event live geschaltet wird, gehört die DebugView auf den Bildschirm. Sie zeigt Events in Echtzeit an, inklusive aller Parameter, sobald der Debug-Modus aktiviert ist, etwa über die GA4-Debugger-Erweiterung oder den GTM-Vorschaumodus.

Beim Testen in der DebugView lohnt sich eine feste Prüfroutine:

  • Kontrollieren, ob value und currency bei jedem relevanten Event vorhanden sind und als Zahl beziehungsweise gültiger ISO-Code ankommen.
  • Prüfen, ob das items-Array vollständig befüllt ist, mit item_id, item_name, price und quantity pro Artikel.
  • Beim purchase-Event gezielt die transaction_id kontrollieren, denn ein fehlender oder doppelter Wert fällt hier oft erst auf, wenn man ihn ausdrücklich sucht.
  • Im GTM-Vorschaumodus den Tab für den Data Layer öffnen und prüfen, ob der Custom Event Trigger tatsächlich auf das erwartete Event reagiert und nicht auf ein ähnlich benanntes.
  • Über die Netzwerkanalyse des Browsers die collect-Requests an Google filtern und stichprobenhaft die übertragenen Parameter direkt in der Anfrage einsehen.

Wer diese Checks überspringt und direkt auf die Standardberichte schaut, verliert wertvolle Zeit. Google Analytics 4 zeigt frisch implementierte Daten in den Standardreports typischerweise erst nach bis zu 24 Stunden an. Ein Fehler, der erst am nächsten Tag im Report auffällt, kostet unnötig Zeit gegenüber einer sofortigen Prüfung in der DebugView direkt nach dem Deployment.

Wo landen die Daten und wann lohnt sich BigQuery?

Sobald die Events korrekt ankommen, verteilen sich die Daten auf mehrere Ebenen in GA4, die unterschiedliche Fragen beantworten. Der Bericht Monetarisierung → E-Commerce-Käufe ist der erste Anlaufpunkt und liefert automatisch Umsatz, Konversionen und den durchschnittlichen Bestellwert, sobald purchase-Events mit korrektem value und currency eingehen.

Für tiefere Fragen reichen die Standardberichte oft nicht aus. Genau hier setzen Explorations an: Sie erlauben freie Funnel-Analysen, etwa wie viele Nutzer von view_item über add_to_cart bis zum purchase gelangen, und lassen sich nach Produktkategorie oder Kundensegment aufschlüsseln.

Wer noch weiter gehen will, exportiert die Rohdaten über BigQuery. Das lohnt sich vor allem für zwei Zwecke:

  • Attribution über mehrere Touchpoints hinweg, wenn die GA4-Oberfläche für komplexe Customer Journeys nicht granular genug ist.
  • Cross-Plattform-Analysen, etwa wenn App- und Web-Daten zusammengeführt oder mit CRM-Daten verknüpft werden sollen. Wie eine solche Datenzusammenführung in der Praxis aussehen kann, beschreibt der Leitfaden zu Echtzeit-Datenkonsolidierung von Opptymizer.

Fehlt der Umsatz im Bericht komplett, lohnt sich zuerst der Blick auf drei Dinge: Wurde currency tatsächlich mitgesendet, ist value eine Zahl und keine Zeichenkette, und ist die „Send Ecommerce Data“-Checkbox im GTM-Tag aktiv. In den allermeisten Fällen liegt genau dort der Fehler.

Welche Fehler zerstören GA4-E-Commerce-Daten am häufigsten?

Die meisten kaputten E-Commerce-Reports lassen sich auf eine Handvoll wiederkehrender Fehler zurückführen, und praktisch alle davon sind vermeidbar, wenn man sie kennt.

  1. Fehlende oder doppelte transaction_id: Ohne eindeutige ID kann GA4 einen erneuten Seitenaufruf nach dem Kauf nicht von einem zweiten Kauf unterscheiden, und der Umsatz wird künstlich aufgeblasen.
  2. value als String statt als Zahl: Ein in Anführungszeichen übergebener Wert wird in Berichten teils falsch oder gar nicht verarbeitet.
  3. Fehlendes ecommerce: null vor dem Push: Alte Werte aus einem früheren Event bleiben stehen und mischen sich mit den neuen, was zu unerklärlichen Ausreißern in den Zahlen führt.
  4. „Send Ecommerce Data“ in GTM nicht aktiviert: Der Trigger feuert korrekt, aber die eigentlichen Produktdaten fehlen komplett im gesendeten Event.
  5. Manuelle Überschreibung der items im Tag: Wenn Entwickler versuchen, das items-Array direkt im GTM-Tag statt im DataLayer zu pflegen, entstehen schnell Abweichungen zwischen dem, was auf der Seite passiert, und dem, was gemessen wird.

Als Gegenmaßnahme hilft eine feste Systematik: eine einheitliche item_id-Strategie über alle Systeme hinweg, konsequenter Einsatz des Null-Push-Musters bei jedem Event, und eine Typenkontrolle, die vor jedem größeren Release automatisch prüft, ob value, price und quantity als Zahlen ankommen.

Profi-Tipp: Richten Sie sich eine Warnung ein, die bei ungewöhnlichen Sprüngen im Tagesumsatz automatisch anschlägt, etwa über die Anomalieerkennung in GA4 oder ein externes Monitoring. Solche Sprünge sind fast immer ein Tracking-Problem, nicht ein echtes Umsatzereignis.

Checkliste: Was vor und nach dem Go-Live zu prüfen ist

Vor dem eigentlichen Livegang sollte jeder dieser Schritte einmal vollständig durchlaufen sein, am besten in einer Staging-Umgebung und nicht erst live.

  1. Null-Push-Muster in allen relevanten Templates implementieren und im Code-Review gegenprüfen.
  2. transaction_id-Generierung testen und sicherstellen, dass sie bei jedem Reload der Bestätigungsseite stabil bleibt.
  3. Den vollständigen DataLayer-Push in der Staging-Umgebung mit der Browser-Konsole kontrollieren.
  4. Alle Events einmal komplett im GTM-Vorschaumodus durchgehen.
  5. Parallel die DebugView öffnen und einen vollständigen Testkauf durchführen, vom view_item bis zum purchase.
  6. Über die Netzwerkanalyse prüfen, ob die collect-Requests tatsächlich alle erwarteten Parameter enthalten.

In den ersten 48 Stunden nach dem Livegang lohnt sich tägliches, nicht nur einmaliges Monitoring der Monetarisierungsberichte, kombiniert mit einem Stichprobenabgleich gegen das echte Bestellsystem.

Prüfpunkt Zeitpunkt Ziel
DebugView-Testkauf Vor Go-Live Alle Event-Parameter korrekt
GTM-Vorschaumodus Vor Go-Live Trigger feuern richtig
Monetarisierungsbericht Erste 24 Stunden Umsatz erscheint plausibel
Abgleich mit Bestellsystem 24 bis 48 Stunden Transaktionsanzahl stimmt überein

Agentur-Perspektive: Wann sich die Auslagerung des Trackings lohnt

Aus meiner Sicht lohnt sich eine externe Umsetzung nicht ab einer bestimmten Shopgröße, sondern ab einer bestimmten Komplexität. Ein Shop mit einem einzigen Checkout-Flow und Standardplattform kann die Implementierung mit sorgfältiger Arbeit selbst stemmen. Sobald aber mehrere Domains im Spiel sind, der Checkout individuell angepasst wurde oder interne Ressourcen für laufende Wartung fehlen, kippt die Rechnung schnell.

Der eigentliche Aufwand liegt nämlich nicht in der Erstimplementierung, sondern im laufenden Monitoring: neue Produktkategorien, geänderte Checkout-Schritte, Plattform-Updates, die stillschweigend Felder verändern. Genau das ist der Punkt, an dem spezialisierte Teams mit Audits bestehender Implementierungen, laufendem Monitoring der Datenqualität und Reporting, das über die Standardansicht in GA4 hinausgeht, unterstützen können.

Wer unsicher ist, ob die eigene Implementierung wirklich robust ist, sollte sie nicht an der Optik der Berichte messen, sondern an der Frage: Würde ein Stichprobenabgleich mit dem Bestellsystem exakt aufgehen? Bei den meisten Shops, die wir uns ansehen, lautet die Antwort zunächst nein.

— Patrick

Neomarketing prüft und implementiert Ihr GA4-E-Commerce-Tracking

Anders als eine allgemeine Marketing-Agentur, die GA4 nebenbei mitbetreut, arbeitet Neomarketing gezielt an der technischen Schnittstelle zwischen DataLayer, Google Tag Manager und Ihrem Shopsystem, und liefert Ihnen belastbare Umsatzdaten statt geschätzter Näherungswerte.

Neomarketing

Ob Sie eine bestehende Implementierung auf stille Fehler wie fehlende item_id-Felder oder falsche Datentypen prüfen lassen wollen, oder das Tracking komplett neu aufsetzen müssen: Eine erste Analyse Ihrer Google-Tools im E-Commerce zeigt, wo genau Ihre Daten heute abweichen. Für Shops mit Bedarf an laufender Betreuung bietet das Team zusätzlich maßgeschneiderte Lösungen rund um Google Ads, Merchant Center und Reporting an. Kontaktieren Sie Neomarketing für eine unverbindliche Erstprüfung Ihres aktuellen E-Commerce-Trackings.

Quellen

Wer tiefer in die Materie einsteigen will, findet bei Google die verbindlichen Referenzen für Feldnamen und Event-Struktur, ergänzt durch praxisnahe Umsetzungsguides erfahrener Tag-Manager-Spezialisten.

Wer zusätzlich die Grundlagen von GA4-Ereignissen auffrischen möchte oder ein passendes E-Commerce-Tracking-Tool neben GA4 evaluiert, findet dort weiterführende Einordnung. Bei Shops mit mehreren Domains oder externem Checkout lohnt sich zusätzlich ein Blick auf die domainübergreifende Messung, da hier eigene Fallstricke bei der Session-Zuordnung entstehen.

Empfehlungen