Markus Baersch

Software · Beratung · Lösungen

Suche im Blog

Sign In

Monday, 23 November 2015

Das Google Analytics Measurement Protocol: Stornierte Transaktionen und Retouren

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.

Alle Teile dieser Serie

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 (auch 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 auch 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:

//Transaktion - der Einfachheit ohne Affiliation, Steuer oder Versandkosten https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=transaction&ti=TRANS123&ta=&tr=300&ts=0&tt=0&cu=EUR&aip=1

//Der (einzige) enthaltene Artikel wird als Item hinterher gesendet. https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=item&ti=TRANS123&in=Artikelname+hier&ip=300&iq=1&ic=ART321&iv=green&cu=EUR&aip=1
//Hier könnten in anderen Fällen weitere Positionen folgen

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 auch 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:

//Transaktion mit gleichen Angaben, diesmal aber mit negativem Vorzeichen beim Umsatz https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=transaction&ti=TRANS123&ta=&tr=-300&ts=0&tt=0&cu=EUR&aip=1 //Auch der Artikel wird storniert - durch negative Menge https://www.google-analytics.com/collect?v=1&tid=UA-xxx-1&cid=555&t=item&ti=TRANS123&in=Artikelname+hier&ip=300&iq=-1&ic=ART321&iv=green&cu=EUR&aip=1

Bei Transaktionen erhält der Umsatz ein neues Vorzeichen, bei Artikeln die jeweilige Menge. Nicht der Betrag. Obwohl auch 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.

Korrekt stornierter Artikel
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 auch 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.

Stornierte Transaktion, erhaltene Artikel

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.

Transaktion mit letztem Artikel verschwunden

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.

Transaktion ist noch da

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.

Transaktion unsichtbar, da summen- und mengenneutral

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.

Stornolüge durch Vorzeichenfehler
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 auch 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:

Filter auf Stornos aus dem System
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?

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? ;)

#