A/B Testing: Dieser Goal-Typ ist der Grund für die häufigsten Tracking-Fehler

A/B Testing: Dieser Goal-Typ ist der Grund für die häufigsten Tracking-Fehler

Für ein aussagekräftiges Ergebnis beim A/B Testing ist das korrekte Tracking der KPIs (Goals) entscheidend. Tracking-Fehler sind nicht nur ärgerlich, sondern können im schlimmsten Fall zu einer falschen Interpretation des Testergebnisses führen. Dabei ließe sich ein fehlerhaftes Tracking zum Großteil vermeiden. Nach meiner Erfahrung ist ein spezifischer Goal-Typ der Grund für die häufigsten Tracking-Probleme.

Der Prozess

A/B Tests durchlaufen in den meisten Unternehmen den gleichen Prozess. Nach der Spezifikation folgt die Entwicklung und den Abschluss bildet die interne und/oder externe Qualitätssicherung. Dieser Ablauf hat sich bewährt und soll gewährleisten, dass der Test für den Live-Gang möglichst fehlerfrei ist. Die Praxis zeigt allerdings, dass selbst die beste Qualitätssicherung nicht alle Fehler finden kann.

Warum ist das so?
In der Qualitätssicherung testet man im optimalen Fall verschiedene Szenarien, Endgeräte und simuliert sogar ein ungewöhnliches User-Verhalten. Letzteres kann man jedoch schlecht vorhersagen. Aus diesem Grund bleiben oft bestimmte Fehler unentdeckt oder fallen erst dann auf, wenn der Test schon live ist.

Dieses ungewöhnliche User-Verhalten hat beim KPI-Tracking auf einen bestimmten Goal-Typen eine besonders große Auswirkung – dem bedingten Ziel.

Was ist ein Bedingtes Ziel?

Streng genommen hat jedes Ziel immer mindestens genau eine Bedingung. Entwickler würden eher von Events sprechen. Dieses Event ist in der Regel vordefiniert. Zum Beispiel: Das Klick-Event, Load-Event (Page Load/Page Impression), Scroll-Event (…). Wenn jedoch mehr als ein Event oder weitere Aktionen und Ereignisse vorausgesetzt werden um das Goal zu triggern, dann spricht man von einem Bedingten Ziel.

Ein Praxisbeispiel

Auf einer Produktkategorie-Seite (z.B. Herren-Mode) soll eine neue Subnavigation getestet werden, die auf die Produkübersicht-Seiten führt. Ziel ist, es herauszufinden, ob die Klicks auf die Sub-Navi, die Add-To-Cart-Rate (auf der Produktdetail-Seite) positiv beeinflussen.
Mit einfachen Worten: Der Klick auf den Add-To-Cart-Button darf nur dann gezählt werden, wenn der Besucher über die neue Sub-Navigation die PDS erreicht hat.

Die konkrete Umsetzung für dieses Goal würde so aussehen:
Sobald der User auf die Navigation klickt, wird er markiert und bekommt ein „Fähnchen“. Im weiteren Verlauf der User-Journey gelangt er auf die Produktübersicht-Seite und darüber wiederum auf die PDS. Sobald er den Add-To-Cart Button triggert, findet eine Prüfung statt, ob der User (noch) das Fähnchen hat. Wenn ja, wird das Goal gezählt, ansonsten wird der Aktion ignoriert.

Soweit so gut. Wenn jeder Besucher brav diese Steps der Journey auf die gleiche Art und Weise durchlaufen würde, dann gäbe es kein Problem. Aber die Realität sieht leider etwas ander aus. Auf dem Weg zur Produktdetailseite könnte der Besucher es sich anders überlegen und einen Abstecher auf die Startseite machen um von dort aus über z.B. eine Recommendation auf die PDS zu gelangen. Da er sich zuvor das „Fähnchen“ abgeholt hat, würde der Klick auf den Add-To-Cart-Button in die Auswertung, fälschlicher Weise, mit aufgenommen werden.

Wie lässt sich dieser Fehler vermeiden? Ganz einfach, wenn der User vom Weg abweicht, wird ihm sein Fähnchen weggenommen. Dazu braucht es einer ständigen Abfrage der aktuellen Berechtigung über den Besitz des Fähnchens. Eine Möglichkeit wäre beispielsweise die Abfrage des sogenannten Referrers. Dieser liefert die URL der zuvor besuchten Seite. Damit könnte man eine „Breadcrumb“-Abfrage starten, bei der man auf jeder der nachfolgenden Seiten prüft ob der User von der „richtigen“ Seite kommt. Das bedeutet, dass der Weg vordefiniert sein muss, bzw. die Grenzen gezogen werden sollten, die der Besucher auf dem Weg zur Conversion nicht übertreten darf. In diesem Beispiel sind es drei Bedingungen (Steps).

  1. Produktkategorie-Seite (Ausgangsseite mit neuem Menü) erreicht und Sub-Navi geklickt (1)
  2. Produktübersicht-Seite erreicht und auf ein Produkt geklickt (2)
  3. Produktdetail-Seite erreicht und auf Add-To-Cart geklickt (3)

In Pseudocode Schreibweise könnten die Abfragen in etwa so aussehen:

//Pseudocode
(1) IF User clicks on Navigation AND current location is product-category-page THEN set flag
(2) IF User holds flag AND current location is product-overview-page AND  referrer contains URL from product-category-page THEN proceed ELSE remove flag
(3) ELSE IF User holds flag AND current location is product-detail-page AND referrer contains URL from product-overview-page, THEN proceed ELSE remove flag
(4) WHEN User passed step 1-3, listen to click on "Add-To-Cart"-Button, WHEN he clicks on the Button -> trigger the Goal

Es sei erwähnt, dass dieser Code bei jedem Seitenaufruf ausgeführt wird. Er stellt sicher, dass die „flag“ bis zur PDS durchgereicht wird, sofern der User den vorbestimmten Weg einhält. Würde er ihn verlassen, dann hätte dies zur Folge, dass die Stellen 2 und 3 im Code die „Flag“ entfernen würden. Um bei dem Beispiel von vorhin zu bleiben, würde das Verlassen der Journey nach Schritt 1 dazu führen, dass die Flag entfernt würde. Der User kommt zwar von der „richtigen“ Seite, allerdings fällt er durch die „location“-Prüfung, da er sich weder auf der Produktübersicht-Seite noch auf der Produktdetail-Seite befindet.

Das Beispiel in JavaScript:

Analysieren und Spezifizieren

Das Beispiel oben ist nur eines von vielen. Es müssen nicht immer Klick-Events dabei eine Rolle spielen. Denkbar sind auch einfache Page-Impressions (Page-Loads) oder z.B. Scroll-Events, die in Abhängigkeit von einem oder sogar noch weiteren Ereignissen, eine bestimmte Metrik bedingen. Das bedeutet, dass die Komplexität für diese Goals mit der Anzahl der Bedingungen steigt. Im gleichen Maße steigen allerdings auch dazu die Aufwände für die Entwicklung und Qualitätssicherung. Selbst der Projektmanager ist davon betroffen, da häufig Rücksprachen mit den Kunden und Consultants gehalten werden müssen um die Unklarheiten auszuräumen.

Um Fehler zu vermeiden, empfiehlt es sich jedes Goal in der Spezifikations-Phase genau unter die Lupe zu nehmen. Nicht jedes Goal ist immer offensichtlich ein Bedingtes Goal. Ein einfaches Beispiel sind Page-Impressions: Soll ein Page-Refresh auf der gleichen Seite als Page-Impression gemessen werden? Falls die Antwort Nein heißt, dann ist das Ziel ein Bedingtes Ziel. In diesem Fall wird nämlich bei jedem Page-Load abgefragt, ob auf der Seite, auf der ich mich aktuell befinde, bereits ein Load stattgefunden hat.

Es braucht an Zeit und Erfahrung um Bedingte Ziele zu erkennen und präzise zu spezifizieren. Während der Analyse, sollte man sich unbedingt die Zeit nehmen, die technischen Aspekte zu recherchieren. Alternativ hat man einen Entwickler an seiner Seite um offene Fragen oder potenzielle Probleme zu diskutieren.
Um den Überblick zu behalten empfiehlt es sich die Szenarien um ein Goal herum genau skizzieren. Dabei sollte man sich fragen, welche Ereignisse das Goal beeinflussen könnten und welche Rolle vor allem der User dabei spielt. Je genauer das „Bild“ des Szenarios, desto besser lassen sich potentielle Fehlerquellen erkennen und damit (langfristig) vermeiden.

tl;dr

Bedingte Ziele sind eine der häufigsten Ursachen für Fehler bei der KPI-Messung. Ihre Fehleranfälligkeit steigt, je umfangreicher die Bedingungen sind. Um Tracking-Fehler zu vermieden, müssen Bedingte Ziele identifiziert und analysiert werden. Damit minimiert man deutlich den Aufwand in der Entwicklung und Qualitätssicherung. Darüber hinaus schafft man langfristig eine solide Grundlage für ein fehlerfreies Goal-Tracking.

Bildquelle TItelbild: rawpixel.com

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.