Markus Baersch

Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol. Der Artikel zeigt auf, wie man bereits in der Webanalyse vermerkte Transaktionen sauber rückgängig macht und was genau dabei mit den Daten in Analytics passiert.

Updates 2021:

• Für das Google Analytics 4 Measurement Protocol wurde ein neuer Abschnitt hinzugefügt.
• Hinweise zur vollständigen Löschung von Transaktionen über den Nutzer

Alle Teile dieser Serie

• Überblick und Anwendung
• Praxistipps und Einsatzmöglichkeiten
• LifeLogging mit IFTTT
• Transaktionen richtig stornieren
• Serverseitiges Tracking: Dem Googlebot zuschauen

Transaktionen in Google Analytics

Alle möglichen Quellen beschießen Google Analytics mit Transaktionsdaten. Ein Großteil davon sind Abschlussseiten von Checkout-Prozessen in Onlineshops. Jeder Verkauf wird als Transaktion inkl. einer eindeutigen Nummer und den im Warenkorb enthaltenen Artikeln nebst Mengen und Preisen in Analytics vermerkt und kann dort ausgewertet werden.

Davon abgesehen, dass der einzig richtige Platz zur Auswertung zuverlässiger Zahlen zu Online-Umsätzen nicht die Webanalyse, sondern die eigene Warenwirtschaft bzw. Buchhaltung ist, hat jeder Shopbetreiber trotzdem ein großes Interesse an möglichst sauberen Daten in Analytics. Nur so lassen sich Umsatz nach Kanal und Rentabilität von Kampagnen vernünftig auswerten und zur Steuerung von Budgets einsetzen.

Spielverderber Realität: Retouren und Stornos

Leider hat nicht jeder der erfassten Umsätze Bestand. Hohe Retouren- bzw. Stornoquoten können die Verhältnisse enorm verschieben. Da üblicherweise nicht alle Besucher aus allen Kanälen das gleiche Stornoverhalten aufzeigen, ist eine Korrektur von "gebuchten" Umsätzen parallel zu den eigenen ERP-Systemen auch in Analytics ein häufiger Wunsch.

Dazu liefert Google schon seit der Geburt des E-Commerce-Trackings Hinweise zu Stornomöglichkeiten. Die Hilfe erklärt genau, was zu tun ist. Auf dieser Basis existieren zahlreiche Systeme, die entweder von Haus aus oder per "angestrickter" Erweiterung in der Lage sind, Umsätze zu erkennen, welche aus einem Shopsystem stammen und gesondert zu behandeln. Die komfortabelste Lösung ist dabei bisher der Aufruf eines Links oder ein vom System automatisch geöffnetes Browserfensters. Geöffnet wird eine Seite, der als Parameter die erforderlichen Infos übergeben werden, um eine Stornotransaktion an Analytics zu übertragen. Dabei nimmt die "Gegentransaktion" den gleichen Weg wie der ursprünglich gebuchte Umsatz - über das Standard-Tracking von Google Analytics.

Auftritt Measurement Protocol

Seitdem es Universal Analytics und das Measurement Protocol gibt, besteht kein Bedarf mehr für Links und geöffnete Browserfenster. Jeder Client kann unter den gleichen Bedingungen entsprechende Hits direkt an den Analytics-Server senden.

GA MP FTW!

Dass ein System in der Lage ist, ohne Interaktion des Erfassers eines Stornovorgangs oder störender Eingriffe im Browser auszukommen, ist für sich genommen schon ein ausreichender Vorteil, um eine Umsetzung zu rechtfertigen. Man kann die Übertragung an Analytics zudem komplett entkoppeln und zu einem späteren Zeitpunkt erledigen. Das ist nicht nur, aber besonders bei mobilen Anwendungsfällen oder offline erfolgender Datenerfassung ggf. sogar der einzige Weg.

Unmittelbar in der Anwendung oder basierend auf Stornologs bzw. direktem Zugriff auf die Datenbank der ERP-Anwendung kann zentral (und bei zuverlässiger Internetverbindung) zu definierten Zeitpunkten der Abruf aller Stornodaten erfolgen, die dann im Batch an Analytics gesendet werden. Untersucht man dabei die Pakete auf Einhaltung der in den Praxistipps beschriebenen Limits, hat man einen sicheren und komfortablen Weg zur komplett automatisierten Abwicklung des Vorgangs. Dabei muss - lesenden Datenzugriff vorausgesetzt - noch nicht einmal das System selbst dazu in der Lage sein. Die Übergabe kann vollständig extern gelöst und angebunden sein - ein Zurückspielen von Informationen in die Datenbank ist nicht erforderlich (dort ist alles bereits passiert). Solche Lösungen sind zwar unter entsprechendem Aufwand auch auf dem klassischen Tracking-Weg umsetzbar... mit dem Measurement Protocol ist dieser Part aber ein Fünfzeiler und man kann sich voll auf den Datenzugriff und die Verarbeitungslogik konzentrieren. Das spart reichlich Code, Aufwand (ebenso in der Wartung), Zeit, Implementierungskosten. Und sorgt für weitestgehende Unabhängigkeit vom System sowie dessen Updatezyklen, solange sich in der Datenbank nicht zu viel ändert. Win Win Win Win!

So sehen Transaktionen und Stornos als MP-Hits aus

Da das Senden von Transaktionen und nicht nur deren Stornos über das Measurement Protocol interessante Anwendungsfälle (wie z. B. paralleles Tracking von Warenkörben mehrerer Shops an zentraler Stelle) erlaubt, fangen wir mit einer "normalen" (aber sehr simplen) Transaktion an:

Die Transaktion mit der Nummer TRANS123 übergibt einen Umsatz von 300,-- Euro an die Webanalyse. Der einzige Artikel (ein Stück) ist "Artikelname hier" (Nummer ART321) in grün. Normalerweise wird eine solche Transaktion nicht auf dem Weg des Measurement Protocols, sondern über das klassische Tracking übertragen. Will man sie wieder loswerden, können zwei passende Hits per Measurement Protocol den Vorgang rückgängig machen (wie spurlos das passiert, sehen wir noch). Zwei Hits bedeutet etwas, das vielleicht nicht für jeden offensichtlich ist: Artikel eines Auftrags verschwinden nicht automatisch, wenn die zugehörige Transaktion storniert wird. Es ist stets ein separater Hit des Artikels erforderlich - bzw. mehrere Hits, wenn beim Kauf mehr als nur ein Produkt im Warenkorb lag. Bleiben wir beim obigen Beispiel mit nur einem übergebenen Artikel. So sehen die beiden Hits zum kompletten Stornieren aus:

Bei Transaktionen erhält der Umsatz ein neues Vorzeichen, bei Artikeln die jeweilige Menge. Nicht der Betrag. Obwohl das - zumindest "ein wenig" - funktioniert. Was das bedeutet, zeigt der nächste Absatz. Wird der Artikel aber sauber storniert, gibt es zwar zwei Vorgänge in Form einzelner Käufe in Analytics dazu, aber Nullen beim Umsatz der resultierenden Menge.

Ein korrekt stornierter Artikel erlaubt saubere Auswertung von Stückzahlen und Umsätzen

Korrektes Stornieren... und wie es danach in Analytics wirklich aussieht

Vorbemerkung: Das obige Beispiel ist absichtlich stark vereinfacht. Sind Versandkosten und Steuern im Spiel, müssen diese bei der Transaktion entsprechend behandelt und deren Vorzeichen umgekehrt werden, wenn sie "ausgebucht" werden sollen. Außerdem ist es bei Stornos nicht immer erforderlich, die ganze Transaktion zu stornieren, sondern ggf. nur einzelne Positionen. Das Prinzip bleibt jedoch das Gleiche: Die Produkte werden je nach Umfang als komplette Position oder nur als negative Teilmenge storniert, Umsätze und Steuerbeträge der Transaktion um die Umsätze der stornierten Posten verringert.

Das beinhaltet, dass alle übrigen Umsätze der Transaktion und die verbleibenden Artikel in Analytics erhalten bleiben. Aber was bedeutet ein "Vollstorno"? Ist dann wirklich alles "weg"? Nein.

Stornieren ist nicht "Löschen"

Unterstellen wir eine Transaktion mit der schönen Nummer REINRAUS, deren "Storno-Hit" bereits verarbeitet wurde, deren Artikel aber noch im Datenbestand sind. Solange nicht alle Artikel einer Transaktion storniert werden, bleibt diese erwartungsgemäß bestehen.

Nach dem Storno aller Artikel ist die Transaktion offenbar verschwunden, obschon man in der Grafik noch erkennen kann, dass es einen Hit mit negativem Umsatz gegeben haben muss. Die Summen, Durchschnitte etc. wurden aber erwartungsgemäß komplett korrigiert.

Was genau passiert sieht man genauer, wenn man wie gerade gezeigt einen Artikel erst einen Tag später als die Transaktion selbst storniert und sich die E-Commerce-Daten auf Tagesbasis ansieht. An Tag 1 sind Transaktion und Artikel zu sehen, der Umsatz ist frisch gebucht. An Tag 2 wird die Transaktion storniert, bleibt aber wegen der verbleibenden Artikel (bzw. deren Menge) noch in der Auswertung.

Storniert man nun an Tag 3 auch den Artikel (mit korrekten Vorzeichen), gibt es keine Menge mehr zur Transaktion auszuweisen, so dass jede Auswertung, die Tag 2 und Tag 3 umfasst, keine Spuren der Transaktion aufweist.

Auswertungen einzelner Tage oder Perioden, die an Tag 2 enden oder Tag 3 beginnen, werden immer Spuren der Transaktion und / oder des Produkts aufweisen. Es verschwindet also nichts, sondern wird ggf. nur nicht mehr ausgewiesen, wenn Umsätze und Mengen komplett neutralisiert wurden.

Das bedeutet auch, dass Auswertungen auf Monatsbasis sich nach Stornierungen, die erst im Folgemonat passiert sind, nicht rückwirkend verändern. Der negative Umsatz ist vielmehr (der Realität entsprechend) im Folgemonat zu finden.

Negative Beträge bei stornierten Artikeln? Nein.

Man liest gelegentlich den Hinweis, dass für ein Storno negative Preise statt negativer Stückzahlen (oder beides negativ) übergeben werden soll. Das sorgt leider dafür, dass ggf. zwar Umsätze korrigiert sind, aber falsche Stückzahlen im System zurückbleiben. Das Ergebnis sind unzuverlässige Zahlen trotz erfolgter Stornierung. Auch bestehende Implementierungen sollten daher ggf. noch einmal überprüft werden, weil vermutlich viele auf den gleichen Quellen basieren, welche es beim Negieren etwas übertrieben haben.

Pfui: Storno mit positiver Menge und negativem Vorzeichen. Das kommt davon!

Das Ergebnis würde auf die Realität übertragen bedeuten, dass dem stornierten (weil z. B. defekten) Produkt ein kostenfreier Ersatz hintergergeschickt wurde - nebst einem Scheck über den Kaufbetrag als Entschädigung. Das ist kundenfreundlich, aber fatal für das Unternehmen. Deshalb macht sowas auch niemand - also bitte nicht in der Form in Analytics abbilden 😉

Ein Tipp für mehr Übersicht

Wer einen einfachen Überblick über Stornovorgänge haben will, sollte sich dazu entweder eine eigene Datenansicht oder ein Segment für separate Auswertungen anlegen. Damit Stornos exklusiv darin betrachtet werden können, hängt man an die Storno-Aufrufe per zusätzlichem Parameter eine eindeutige Kennung an. Als Datenfeld bieten sich Benutzerdefinierte Dimensionen an. Oder die "Datenquelle", die üblicherweise bei Analytics mit "Web" oder "App" belegt ist. Es ist erlaubt, diesen Wert zu überschreiben und sich eine beliebige Kennung dort zu hinterlegen. Um die Datenquelle z. B. mit "ERPSys" zu belegen, hängt man &ds=ERPsys an die o. a. Hits an. So kann es aussehen, wenn eine benutzerdefinierte Dimension belegt und als sekundäre Dimension eingeblendet wird:

Stornierte Artikel unter der Lupe - in einer gefilterten "Storno-Only" Datenansicht

In diesen separaten Segmenten oder Profilen kann so sehr einfach ein gezielter Blick auf stornierte Umsätze nach Monaten geworfen oder eine Hitliste der meiststornierten Produkte erstellt werden. Damit hat man den bestmöglichen Überblick über Metriken zu Stornos in einem eigenen Profil / Segment und realistischere Umsatzzahlen im Arbeitsprofil, die bessere Entscheidungen bei der Zuordnung von Umsatz zu Kanälen erlauben. Was will man mehr?

Update: Stornos für Google Analytics 4 Properties

Mit Google Analytics 4 ist ein neues Measurement Protocol gekommen. Die gute Nachricht: Auch hier ist auf gleiche Weise das Stornieren einer Transaktion möglich. Dabei wird - im passenden Format - eine Transaktion abgesetzt, die die gleichen Produkte enthält und entsprechend bei einem Storno mit negativer Menge bei den Produkten und negativen Werten bei den Werten für Umsatz, Steuer und Versandkosten ein kompletter Ausgleich generiert.

Es reicht der Versand eines einzelnen Hits, weil Transaktion und Produkte in diesem Format (wie beim Erweiterten E-Commerce in Universal Analytics) zusammengehören. Weil das GA4 Measurement Protocol aber erfordert, dass der Request per POST an den Analytics Server gesendet wird, empfiehlt sich hier z. B. die Verwendung des Event Builders für das neue Measurement Protocol. Hier im Blog wird der Einstieg in das "GA4MP" in einem eigenen Beitrag erläutert - dort findet sich ein Link zu besagtem Event-Builder.

Genau wie im obigen Beispiel kann man bei einem Storno bei einem Produkt (hier im Beispiel für 129,99 Einzelpreis) sehen, wie der Umsatz entsprechend ausgeglichen wird, wenn eine "Stornotransaktion" per GA4MP übertragen wird. In diesem Setup wurde das Produkt am 1. des Monats zweimal gekauft und am Folgetag einmal komplett storniert. Die Versandkosten betrugen jeweils 10,-- . Bei der Produkt-Übersicht sieht das Ergebnis am dritten Tag im Rückblick so aus:

Drei Transaktionen, aber nur einmal der Einzelpreis als Umsatz. Also wie gewünscht.

Auch bei den Werten nach Transaktions-Id sieht man, dass die zweite Id eine weitere Transaktion hatte und der Wert ist entsprechend ausgeglichen. Aber nur dann, wenn man beide Tage in der Auswertungsperiode hat. Am Tag 1 ist der Umsatz noch da und entsprechend am zweiten als negativer Umsatz zu sehen.

[Ende des Updates zu GA4]

Update: Alternative Löschung des kompletten Nutzers

Gerade wenn die Transaktion nicht aus dem Echtbetrieb, sondern versehentlich durch einen Test ausgelöst wurde, kann davon ausgegangen werden, dass unter der Client Id des sendenden Users keine Daten zu finden sind, an denen das eigene Herz und Wohl hängt. Da aber offenbar keine Filter verhindert haben, dass dieser eigentlich "interne" Hit in die Arbeitsdaten gelangt ist (warum sollte man sich sonst mit der Stornierung herumschlagen), ist eine nachträgliche Löschung aller Daten des betreffenden Besuchers anhand seiner Client Id ggf. eine valide Option.

Sucht man dazu im Nutzer-Explorer anhand der Transaktions-Id in den Daten des betreffenden Tags die Historie des Users und klickt dort auf den Schalter zum Löschen seiner Daten, ist nach einiger Wartezeit auch seine Transaktion zusammen mit dem Rest verschwunden und nicht mehr in den Daten zu finden.

[Ende des Updates zur Löschoption]

Im nächsten und vorläufig (aber nicht zwingend endgültig) letzten Beitrag der Serie wird es wieder technischer: Es geht um Tracking von Bots. Serverseitig per Measurement Protocol - auswertbar mit Google Analytics. Nerdig genug? 😉