E-Commerce-Tracking erklärt: von view_item bis purchase

Der Weg des Käufers in Ereignissen

GA4 bildet den Kaufprozess mit festen Ereignissen ab. Jedes Ereignis trägt ein items-Array, in dem jeder Artikel mit item_id, item_name, price und quantity beschrieben wird, sowie die Angaben value und currency für Wert und Währung. Das purchase-Ereignis braucht zusätzlich die transaction_id, also die Bestellnummer. Die Ereignisse im Überblick:

• view_item_list: eine Produktliste wird angezeigt.
• select_item: ein Produkt aus der Liste wird gewählt.
• view_item: die Produktdetailseite wird aufgerufen.
• add_to_cart und remove_from_cart: Artikel kommen in den Warenkorb oder werden entfernt.
• view_cart: der Warenkorb wird angesehen.
• begin_checkout, add_shipping_info, add_payment_info: die Schritte des Bezahlvorgangs.
• purchase und refund: der abgeschlossene Kauf und die Rückerstattung.

Du musst nicht alle elf Ereignisse sofort umsetzen. Die Liste beschreibt einen vollständigen Kaufweg; wie viel davon du brauchst, hängt von deinem Shop und deinen Fragen ab. Ein kleiner Shop mit wenigen Produkten kommt ohne Produktlisten-Ereignisse aus, ein großer Shop mit vielen Kategorien will vielleicht genau wissen, welche Liste zu Klicks führt.

Der dataLayer als Datenbrücke

Der Shop schreibt die Daten in den dataLayer, der Tag Manager liest sie und sendet sie an GA4. Das ist die Arbeitsteilung: Der Shop weiß, was im Warenkorb liegt, der Tag Manager weiß, wohin die Daten gehören. Fehlt dem items-Array ein Feld wie price oder quantity, sind die Auswertungen unvollständig, und GA4 kann den Umsatz nicht korrekt berechnen. Dasselbe gilt für value und currency: Ohne Währung kann ein Kaufwert nicht eingeordnet werden.

Leere vor jedem E-Commerce-Ereignis den vorherigen Inhalt mit ecommerce: null. Der dataLayer behält frühere Werte, und GA4 liest den E-Commerce-Teil sonst als Mischung aus alter und neuer Aktion. Ein Besucher, der erst ein Produkt ansieht und dann ein anderes in den Warenkorb legt, würde ohne diesen Schritt Daten aus beiden Aktionen vermischen. Der Schritt wird in der Praxis oft vergessen und gehört deshalb in jede Testliste.

Passend dazu: Server-Side oder Client-Side Tagging?

Mindestausstattung: vier Ereignisse genügen für den Start

Beginne mit view_item, add_to_cart, begin_checkout und purchase. Damit siehst du, wie viele Besucher ein Produkt ansehen, in den Warenkorb legen, den Bezahlvorgang beginnen und kaufen. Besonders aufschlussreich ist der Schritt zwischen begin_checkout und purchase: Brechen hier viele Besucher ab, liegt es oft an Versandkosten, Zahlungsarten oder einem unübersichtlichen Formular, nicht an der Werbung. Erweitere danach schrittweise, etwa um add_shipping_info und add_payment_info, wenn du die Kasse genauer analysieren willst.

Eine strikte Pflicht gibt es nicht. Wichtiger als Vollständigkeit ist, dass die wenigen Ereignisse zuverlässig und mit korrekten Werten ankommen. Ein sauberes purchase-Ereignis ist mehr wert als zehn halbfertige.

Beispiel: kleiner Shop mit Werbung

Ein kleiner Shop für Kerzen schaltet Anzeigen und will wissen, welche Kampagne Umsatz bringt. Er setzt view_item auf der Produktseite, add_to_cart beim Klick auf den Warenkorb-Button, begin_checkout beim Start der Kasse und purchase auf der Bestätigungsseite. Jedes Ereignis trägt dieselbe item_id wie im Shopsystem. Nach zwei Wochen zeigt sich, dass viele Besucher die Produktseite sehen, aber kaum jemand in den Warenkorb legt. Die Ursache liegt also vor dem Warenkorb, bei Produktbildern oder Preisangaben, und nicht in der Kasse. Ohne die Ereignisse wäre nur bekannt, dass wenig verkauft wird.

Umsetzung und Test

Die Umsetzung läuft meist über den Tag Manager. Der Shop oder ein Plugin muss die Daten im richtigen Moment in den dataLayer schreiben; manche Shopsysteme bringen das mit, andere brauchen eine Erweiterung oder individuellen Code. Teste im Vorschaumodus, ob die Tags feuern und die Parameter stimmen. Öffne dazu im Vorschaumodus bei jedem Ereignis den dataLayer-Eintrag und kontrolliere Artikel, Preise, Menge, Wert und Währung. Falsche Währungen oder Werte verfälschen deine Umsatzberichte, ohne dass es auffällt. Achte außerdem auf eine einheitliche item_id über alle Ereignisse, damit GA4 ein Produkt über den ganzen Weg zuordnen kann.

Bei purchase ist die Doppelzählung kritisch: Lädt der Besucher die Bestätigungsseite neu, darf das Ereignis nicht erneut gemeldet werden. Die transaction_id hilft dabei, weil dieselbe Bestellnummer erkennbar ist, und eine Sperre im Browser kann das erneute Senden verhindern. Mache am Ende immer eine echte Testbestellung, auch mit Gutschein und mit verschiedenen Zahlungsarten, und vergleiche Bestellnummer und Wert in GA4 mit dem Shop. Teste außerdem mit und ohne Einwilligung, denn ohne Zustimmung dürfen keine Daten fließen.

Typische Fehler und woran du sie erkennst

Ein Umsatz in GA4, der höher ist als im Shop, deutet auf doppelt gezählte Käufe hin, meist durch ein neu geladenes Bestätigungsfenster oder zwei Tags für dasselbe Ereignis. Ein Umsatz von null trotz gezählter Käufe deutet auf fehlende value- oder price-Angaben hin. Produkte, die in den Berichten mit leerem Namen auftauchen, haben kein item_name im items-Array. Und wenn add_to_cart plötzlich Werte aus einer früheren Aktion trägt, wurde der ecommerce-Inhalt nicht geleert. Diese Muster zeigen dir, wo du suchen musst, bevor du Berichte anzweifelst.

Prüfe zusätzlich Zahlungsarten mit Weiterleitung. Zahlt ein Kunde über einen externen Dienst und kehrt nicht zur Bestätigungsseite zurück, fehlt das purchase-Ereignis. Dann hilft ein Abgleich der Bestellungen im Shop mit den gezählten Käufen in GA4, um die Lücke zu erkennen und die Zahlungsart gezielt zu testen.

Wann sich Hilfe lohnt

Das Zusammenspiel aus Shopsystem, dataLayer und Tag Manager ist die häufigste Hürde. Läuft der Shop auf einem System, das den dataLayer nicht von selbst füllt, wird aus der Konfiguration eine Entwicklungsaufgabe. Trackum richtet E-Commerce-Tracking mit GA4 und Consent Mode v2 ein.