Der Kassenbereich spielt in jedem Shop eine besondere Rolle. Während man den Besucher auf den restlichen Seiten zum Kauf überzeugen will, geht es im Checkout vor allem darum, alles schnell und unkompliziert abzuwiegeln und kaufbereite Nutzer durch Usability Probleme, Formulare oder sonstiges nicht vom Kauf abzubringen.
Wie kann man die Performance des Checkouts und einzelne Bereiche und Formulare genauer im Blick behalten? Wir geben einen Überblick der besten Tracking- und Analyse-Möglichkeiten, die wir bisher bei unseren Kunden angewendet haben.
Die ersten Schritte, die im Bereich Checkout Analyse getätigt werden sollten, sind das Anlegen der Zielvorhaben in Google Analytics. Wir brauchen mindestens diese Ziele:
Mit diesen 3 Zielvorhaben können wir in Google Analytics die wesentlichen Funnelschritte untersuchen. Das bietet sich besonders an, wenn in einem Shop noch nicht so viele Transaktionen im Monat geschehen, da wir dann statt mit E-Commerce-Conversion-Rate auch mit der Warenkorb Rate als Qualitätsindikator arbeiten können und mehr Konversionen in unserer Analyse rechnen.
In Google Datastudio behalten wir mit einfachen Visualisierungen die absoluten Werte und die Conversion Raten von einem Schritt zum anderen im Blick.
Wer sich mit Funnel Visualisierung beschäftigt hat oder ein Ziel in Google Analytics erstellt hat, findet recht schnell die Trichterschritte und den Bericht Trichtervisualisierung.
Hier sieht man bei jedem Schritt, wie viele Nutzer von Schritt 1 zu Schritt 2 gegangen sind, wohin sie abgesprungen sind und von wo sie den Trichter neu betreten haben.
Als erster Überblick oder Ergänzung ist dieser Bericht sehr nützlich. Jedoch gibt es ein großes Manko: Man kann nicht segmentieren!
Es ist nicht möglich, sich z.B. neue vs. wiederkehrende Nutzer anzusehen oder Mobil gegen Desktop.
Damit kann dieser Bericht niemals das einzige Werkzeug für eine gute Analyse sein.
Ist auf einer Website das erweiterte E-Commerce Tracking implementiert, dann kann der Bericht „Kaufverhalten“ genutzt werden, um den Kaufprozess und damit auch die Unterschiede zwischen Warenkorbabschluss und Transaktion untersuchen. Das gute hier: im Gegensatz zu den Trichtervisualisierungen ist dieser Bericht segmentierbar!
Hat man zusätzlich noch das erweiterte E-Commerce Tracking für die Checkout Schritte implementiert, kann man auch im Bericht „Bezahlvorgang“ ein Balken Diagramm und eine Tabelle der getrackten Schritte analysieren. Auch dieser Bericht ist segmentierbar.
In der Praxis haben wir den Bericht „Bezahlvorgang“ bisher nicht so häufig benutzt, da es zum einen relativ viel Trackingaufwand bedeutet und zum anderen viele Kunden „Onepage Checkouts“ haben, bei denen man die Schritte nicht gut definieren kann.
Wie kann man einen Checkout – Funnel visualisieren, ohne dass man Trackinganpassungen vornimmt oder den Funnel im Zielvorhaben definiert? Wird jeder Checkout Step in Analytics als Seitenaufruf erfasst, kann man sich im Bericht „Alle Seiten“ die Schritte filtern und nach „Einzelnen Seitenaufrufen“ sortieren. „Einzelne Seitenaufrufe“ bedeutet: „In wie vielen Sitzungen wurde die Seite aufgerufen?“. Das ganze sieht dann so aus:
In unserem Beispiel haben wir den Bericht auf 5 Schritte gefiltert. Im Bericht erkennt man recht schnell, dass nach dem Warenkorb von den 156 Sitzungen auf #billing etwa 120 Sitzungen bis #review gelangen, wobei im Schritt #payment etwas mehr abspringen. Durch die farblichen Markierungen sieht man außerdem, dass z.B. bei #payment die Ausstiegsrate am höchsten im Checkout ist und dass die Wahl der Versandmethode sehr schnell geht.
Für den Filter wurde folgender regulärer Ausdruck benutzt:
^/checkout/cart/$|^/checkout/onepage/#billing|^/checkout/onepage/#shipping_method|^/checkout/onepage/#payment|^/checkout/onepage/#review
Der große Nachteil dieser Visualisierung ist, dass es keine Conversion Rates von Schritt zu Schritt gibt. Diese müsste man sich selbst berechnen. Will man die einzelnen Step-Conversion-Raten in einem Dashboard im Blick behalten, wäre ein Export über Google Sheets nötig, von wo aus die Daten in Google Data Studio geladen werden. Alternativ muss die Balken/Tabellen Visualisierung ausreichen.
Nachdem bisher ein paar Standard Verfahren vorgestellt wurden, möchte ich nun auf 4 Analysen und Trackings eingehen, bei denen ich die ersten drei als „made by Clicks“ betitele, weil sie in der hier beschriebenen Form in keiner Webanalyse Quelle im Netz beschrieben werden.
Bei der Analyse der Bezahlmethoden beschränken nach unserer Recherche sich viele Lösungen auf das Tracking der Methode bei Abschluss der Transaktion. So soll festgestellt werden, welche Methoden beim Kauf die häufigsten sind. Um über die Performance der Zahlungsmethode im Checkout eine Aussage zu machen müssen wir das Tracking jedoch schon früher ansetzen. Unser Ziel ist hier, bei jeder Methode eine Art Conversion Rate zu ermitteln und außerdem die Payments aufzudecken, bei denen sich die Nutzer unsicher sind und lieber etwas anderes wählen.
Wie wir tracken
Wir benötigen ein Ereignistracking (über Google Tag Manager), das bei einem Klick auf eine Zahlungsmethode ein Ereignis an Analytics sendet. In diesem Ereignis soll die neue gewählte Zahlungsmethode auf 2 Methoden übergeben werden: Einmal als Ereignislabel (oder Aktion) und einmal als benutzerdefinierte Variable.
Die benutzerdefinierte Variable legen wir in Google Analytics unter Verwaltung an mit dem Umfang „Sitzung“. Unsere Variable haben wir „last Payment Method Checkout Onepage“ genannt, um exakt den Inhalt zu treffen. Durch die Einstellung des Umfangs (Sitzung) wird in diese Dimension nur der zuletzt gewählte Wert einer Sitzung gespeichert. Wenn jemand sich also umentscheidet und von Paypal zu Kreditkarte wechselt, wird in der Dimension „Paypal“ durch „Kreditkarte“ überschrieben.
Beim Ereignistracking ist der Best Practice, wenn die IT einen Wechsel der ausgewählten Bezahlmethode an die Data Layer übergibt. Sollte dies nicht möglich sein, wäre ein Click Tracking die Alternative (In unseren Fällen brauchte das Formular bei Wechsel der Auswahl häufig etwas länger, weshalb wir das Analytics Ereignis zeitverzögert auslösen mussten).
Was wir damit konkret analysieren können
Im Kern ermöglicht uns dieses 2 verschiedene Analysemöglichkeiten.
Die erste Möglichkeit ist eine Auswertung der Performance der zuletzt gewählten Zahlungsmethoden. In der Tabelle unten sehen wir die Liste der zuletzt gewählten Payments mit den Metrika „Transaktionen“, „Sitzungen“ und der „E-Commerce Conversion Rate“. In unserer Beispiel Tabelle sehen wir, dass bei dieser Seite die meisten Kunden über PayPal und Paypal Express kaufen. In der Performance zeigt sich der Ratenkauf als weniger konversionstark.
Diese Daten können wir jetzt mit allen Google Analytics Werkzeugen weiter verarbeiten und segmentieren (z.B. nach Gerätekategorie). Die Daten spiegeln jedoch niemals zu 100% die tatsächlichen Bestellungen wieder. Für eine exakte Auswertung der Verteilung der Zahlungsmethoden sind die Daten des Shopsystems besser geeignet.
Die zweite Möglichkeit der Analyse ist die Auswertung der Wechsel zwischen Zahlungsmethoden. Hierfür kombinieren wir die Events mit der Dimension in einer Pivot Tabelle im Datastudio. Die Tabelle sollte Spaltenweise gelesen werden. In unserem Beispiel haben 188 Sitzungen insgesamt auf „Paypal“ geklickt – davon sind 163 auch letztendlich bei Paypal geblieben (86%). „Nachnahme“ haben 46 Sitzungen geklickt und nur 50% (23) sind dabei geblieben. Wir können also unterstellen, dass bei „Nachnahme“ die Nutzer Probleme haben könnten und deshalb die Methode wieder ändern.
Bei vielen Checkouts gibt es verschiedene Möglichkeiten, wie man zur Kasse gehen möchte. Vor der Eingabe der Lieferadresse gibt es einen Schritt, bei man zwischen Gastbestellung, Anmelden, Registrieren und anderen Möglichkeiten auswählt. Obwohl wir meistens empfehlen, diesen Schritt wegzulassen und anders zu lösen, ist es wichtig, über die Nutzung der Optionen mehr zu erfahren.
Wie wir tracken
Ähnlich wie beim vorgestellten Tracking Zahlungsoptionen gehen wir auch bei der Auswahl zwischen Gast-Bestellung, Anmelden, Registrieren etc. vor. Bei der Wahl z.B. „Gast Bestellung“ feuert ein Ereignis (über den Tag Manager) an Google Analytics. Wieder wird der Wert „Gastbestellung“ als Ereignislabel (oder Aktion) und als benutzerdefinierte Variable übergeben.
Wenn die IT die entsprechenden Datalayer Pushes nicht zuarbeiten kann, kann man hier den Weg über Klicks auf DOM Elemente gehen (je nach Html Struktur kann das Tracking dann fehleranfällig werden). Zu beachten ist auch, dass bei vielen Seiten der Nutzer bereits eingeloggt sein kann und die Auswahl dann gar nicht mehr sieht. Entsprechend kann schon beim Klick auf den „Zur Kasse“ Button erfasst werden, ob der Nutzer eingeloggt ist.
Außerdem wird auch bei Amazon Express und Paypal Express der Kassenbereich gar nicht besucht. Hier kann auch ein Klick Tracking auf die Buttons ebenfalls die Dimension füllen.
Die benutzerdefinierte Dimension ist ebenfalls wieder mit dem Umfang „Sitzung“ bei uns eingestellt.
Was wir damit konkret analysieren können
Wie bei den Zahlungsoptionen analysieren wir hier auch die Nutzung mit Sitzungen, Transaktionen und E-Commerce-Conversion-Rate.
In unserem Beispiel fällt z.B. auf, dass die Besucher, die Anmelden wählen, scheinbar wesentlich schlechter konvertieren. Hier sollte der Anmeldeprozess näher untersucht werden, um festzustellen, ob die Anmelder wirklich schlechter kaufen, weil sie z.B. im Anmeldeprozess abgelenkt werden oder ob im Prozess bei vielen eine neue Sitzung in Analytics entsteht und diese dann den Kauf beinhaltet.
Manche Checkouts bestehen nur aus einer Seite, auf der man Lieferadresse, Rechnungsadresse, Bezahlmethoden und Lieferart auswählen soll. Wenn man auf den Button „Zahlungspflichtig bestellen“ klickt, hat man entweder den Kauf abgeschlossen oder es gibt irgendwo Probleme.
Ein Ansatz zur besseren Nutzerverfolgung wäre es, hier die „Runden durch den Checkout“ mit zu zählen und zu untersuchen, wie viele Runden Käufer und Abspringer durch den Checkout drehen. Dafür brauchen wir eine benutzerdefinierte Metrik „Checkout Roundtrips/ Sitzungen“.
Wie wir tracken
Zuerst müssen wir festlegen, wie wir eine Runde durch den Checkout (Roundtrip) definieren wollen. In unserem Beispiel zählt jeder Seitenaufruf des Checkouts als eine Runde – ebenso jeder Klick auf den „Jetzt kaufen“ Button. Dementsprechend sollte bei einem Seitenaufruf und beim Klick auf den Button eine benutzerdefinierte Metrik um 1 hochgezählt werden.
In Analytics müssen wir diese Metrik erstellen. Dafür gehen wir unter „Verwaltung“ zu „benutzerdefinierte Messwerte“. Wir erstellen eine Metrik wie hier zu sehen:
Damit wir unser Ziel erreichen, mit einen Messwert „Checkout Roundtrips/Sitzung“ zu analysieren, benötigen wir einen berechneten Messwert, den wir uns unter „Verwaltung“ à „Berechnete Messwerte“ wie folgt erstellen können:
Was wir damit konkret analysieren können
Der Nutzen dieser Metrik ist zweierlei. Zum einen haben wir eine neue Metrik, die wir im Zeitverlauf oder zusammen mit einer Dimension in einem Dashboard ins Monitoring aufnehmen können.
Der zweite Nutzen dieser Metrik ist die Möglichkeit, sie in die Segmentierung für tiefere Analysen im Checkout einzubeziehen. Wir können uns z.B. nur die Sitzungen mit 10 oder mehr Roundtrips über ein Segment rausfiltern und versuchen zu analysieren, wie es zu dieser hohen Rundenzahl kam.
Wer die Schwachstellen seiner Formulare im Blick behalten möchte, sollte bei einem Fehler im Checkout ermitteln, an welcher Stelle der Fehler aufgetaucht ist. Senden wir alle Fehler als Ereignis an Google Analytics, erhalten wir eine Liste der häufigsten Fehler.
Wie wir tracken
Hier ist der Trackingaufwand sehr unterschiedlich. Wenn die Namen der fehlerhaften Felder von der IT in die Datenschicht gepusht werden, muss man im Tag Manager nur ein einziges Analytics – Event anlegen und ein Verfahren installieren, dass bei mehreren Fehlern dieses Event mehrmals absendet.
Wir haben uns bisher die Fehler jedoch meist direkt aus der Seite gezogen. Je nach Aufbau des Html kann man dann mit ein paar wenigen Events (bei guten Code Attributen) auskommen oder für jeden Fehler ein eigenes Analytics Ereignis erstellen müssen.
Das Ereignis für den Fall, dass pro Fehler ein eigenes Ereignis erstellt werden muss, würde im Tag Manager wie folgt konfoguriert werden:
Das Ereignis wird 2 Sekunden nach dem Klick auf „Jetzt Kaufen“ ausgelöst, da in diesem Fall die Fehler beim Klick vom System noch nicht ermittelt wurden. 2 Sekunden nach dem Klick wird von dem unten stehendem Code das Data Layer Event „form-error“ gefeuert. Wenn zu diesem Zeitpunkt die Fehlermeldung bei der Eingabe des „Stadt“ Feldes sichtbar ist, feuert das Analytics Event.
Die Methode, für jeden Fehler ein eigenes Ereignis Event zu senden, ist zwar an dieser Stelle am einfachsten erklärt, wird von uns wegen des hohen Konfigurationsaufwands nur als letztes Mittel angewandt, wenn wir keine Möglichkeit sehen, auf „elegantere“ Weise mehrere Fehler in einem Ereignis zu bündeln.
Was wir damit konkret analysieren können
Bei der Analyse in Google Analytics haben wir uns bisher größtenteils auf das „Ablesen“ der häufigsten Fehler beschränkt. In unserem Beispiel verursacht das Feld „City“ die meisten Fehler.
Für eine genauere Analyse ist wieder Segmentieren angesagt. Für die Fehler lohnt es sich auch, einen Blick in den Nutzer Explorer zu werfen, da man dort auf den einzelnen Nutzer herunter gebrochen sieht, wann und wie oft welcher Fehler entstanden ist. Nur sollte man aufpassen, dass man dabei nicht zu viel Zeit verliert. 🙂
Die Performance des Checkout sollte ein fester Bestandteil des Monitorings sein. Wer Optimierungen der Checkout Conversion Raten vornehmen möchte, sollte über die hier vorgestellten Trackings eine Bestandsaufnahme machen, Probleme identifizieren, Lösungsansätze finden und dann über Testings auf der Webseite validieren. Wir würden uns freuen, wenn Sie mit uns zusammen diese Schritte machen wollen.
Sie möchten mehr über Tracking- und Analyse-Möglichkeiten in Google Analytics erfahren, ein Angebot oder ein unverbindliches Beratungsgespräch anfordern?
Dann nehmen Sie gern Kontakt mit uns auf – wir melden uns umgehend bei Ihnen!
Björn Frasiak, Customer Success Manager