Mit AB-Testing und multivariaten Tests agile Methoden ins Unternehmen schmuggeln

AB-Testing

Glaubt man den Verkaufszahlen, dürfte Eric Ries’ Buch »The Lean Startup« inzwischen in einigen Bücherschränken stehen. Was aber tun, wenn man kein Startup, sondern ein Teil eines großen und möglicherweise wandlungsresistenten Unternehmens ist? Wie so oft: Klein anfangen und mit Pilotprojekten beweisen, dass agile und leane Methodik funktioniert. Strukturierte AB/MV-Tests eignen sich dazu besonders gut – wenn man ein paar Grundregeln beachtet.

Was ist AB/MV-Testing?

Beim AB-Testing werden die Benutzer einer Website (oder einem anderen interaktiven Produkt) zufällig in mehrere Gruppen geteilt, die unterschiedliche Varianten der Seite präsentiert bekommen. Zum Beispiel eine Landing-Page, bei der einer Hälfte der Benutzer ein Produktvideo gezeigt wird, während die andere Hälfte statische Bilder sieht. Bei beiden Varianten misst man KPIs – etwa Bounce-Rate, Clickthroughrate oder Conversion – und bekommt so solide Daten, um sich für ein Design entscheiden zu können.

Multivariate (MV) Tests gehen noch einen Schritt weiter und testen mehr als eine Variable gleichzeitig. Also etwa Video vs. statische Bilder und lange Produktbeschreibungen vs. Bullet-Points. Dadurch ergeben sich im Beispiel insgesamt vier mögliche Kombination, die dann im Test miteinander konkurrieren. Anders als bei klassischen AB-Tests erfährt man so, welche Element-Kombinationen am besten ankommen, da AB-Tests immer nur eine Variable untersuchen. Dabei gibt es manchmal überraschende Ergebnisse: In Kombination funktionieren teilweise Elemente besser, die allein betrachtet eher schwach abschneiden.

Was haben AB/MV-Tests mit Lean zu tun?

build-measure-learn

Eine zentrale Idee von Lean sind schnelle, Daten-getriebene Iterationen im Build-Measure-Learn-Kreislauf: Prototypen werden schnell gebaut (Build), dann mit empirischen Methoden vermessen (Measure) und auf Basis dieser Ergebnisse verbessert (Learn und wieder Build).

Schnellere Entwicklungszyklen allein lassen sich mittlerweile im Unternehmen gut verkaufen, statistische Daten aus Nutzertests werden aber oft als unnötiges Hindernis wahrgenommen. Wo klassische Wasserfalldenke herrscht, ist außerdem iterative Entwicklung schwer durchzusetzen, weil bei Wasserfall-Entwicklung oft das Ziel ist, schon im ersten Versuch ein vollständiges und optimal benutzbares Produkt zu erhalten – für zyklische Verbesserungen ist in so einem Modell kein Platz.

AB/MV-Tests sind ein Ansatzpunkt, diese beiden Hürden hin zu leaner und agiler Entwicklung einfacher zu nehmen. Der Measure-Schritt ist fester Teil jedes AB/MV-Tests und hat den großen Vorteil, dass er quantitative Daten produziert. Nach jedem Test lässt sich also klar beziffern, wie viel Uplift bei einem KPI zu erwarten sind. Solche Zahlen lassen sich sehr gut in Richtung Management kommunizieren und helfen, das AB/MV-Test-Projekt zu etablieren.

Auch die Iterationen ergeben sich fast zwangsläufig: Selbst ein großes Projekt hat nur eine gewisse Anzahl an geschäftskritischen Templates – wird regelmäßig getestet, führt kein Weg daran vorbei, immer wieder bei den gleichen Seitentypen anzusetzen und auf das bereits Getestete aufzubauen.

Grundvoraussetzung für schnelle Testzyklen sind allerdings eigene Entwicklungskapazitäten im AB/MV-Projekt, sonst bleibt die Agilität schnell auf der Strecke.

Build: Was testen?

Multivariate Tests verführen leicht zu sehr umfangreichen Überprüfungen, in denen viele Variablen miteinander kombiniert werden. Das hat den Vorteil, dass so vielleicht Kombinationen entdeckt werden, die sonst unbeachtet bleiben. Wenn es darum geht, schnell zu iterieren und leane Methoden zu etablieren, sind sehr umfangreiche Tests allerdings keine gute Idee: Jede neue Variable in einem multivarianten Test verdoppelt die Anzahl der Kombinationen und damit auch die Laufzeit des Tests. Zu Beginn heißt die Devise deshalb: Kleine Tests mit großen Änderungen.

Tests sollten nicht nur wenige Änderungen enthalten, diese Änderungen sollten auch deutliche konzeptuelle Unterschiede aufweisen. Farbvariationen bei Call-To-Actions fallen in der Regel nicht in die Klasse »deutliche konzeptuelle Änderung«, da bei solchen Designvariationen normalerweise nur mit kleinen Uplifts zu rechnen ist und sie deshalb deutlich länger laufen müssen, um statistische Signifikanz zu erreichen. Hingegen sind wirklich wahrnehmbare Änderungen an User-Interaktion und -Kommunikation leichter zu messen, weil sie sich auch von den Kennzahlen deutlich unterscheiden. Sie stellen gleichzeitig aber auch ein höheres Risiko dar, denn auch Änderungen, die zwar heuristisch Sinn machen, können am User kolossal scheitern. Im Gegensatz zur Wasserfall-Entwicklung ist so ein Scheitern aber in der nächsten Iteration schnell wieder überwunden, das Risiko sollte man also eingehen.

Bei kleinen Tests ist die Entscheidung, was genau in welcher Reihenfolge getestet wird, umso kritischer. Dabei besteht die Gefahr, Tests dazu zu verwenden, um geschmackliche Differenzen im Unternehmen zu klären. Natürlich kann ein Test beantworten, ob Überschrift 1 oder Überschrift 2 besser konvertiert, große Umsatzsteigerungen sind durch diese Antwort aber nicht zu erwarten. Für ein produktives Test-Programm ist deshalb eine transparente Priorisierung sehr wichtig. Dazu hat sich die PIE-Metrik von Wider Funnel bewährt.

PIE

PIE beantwortet in einer Zahl, wie hoch der geschätzte ROI eines Tests ist. Diese Zahl ist der Mittelwert aus drei Variablen

  1. Potential: Wie schlecht ist die Seite aktuell, wie viel Uplift ist hier zu erwarten?
  2. Importance: Wie wichtig ist die Seite für den Geschäftsprozess. Hier sollte man nicht allein auf den Traffic achten, da Seiten, die tiefer im Conversion-Funnel stecken (wie z.B. Bestellbestätigungen) zwar weniger Page-Impressions als etwa Landing-Pages (wie z.B. Artikeldetailseiten) aufweisen, aber für Conversions an sich genauso wichtig sind. Seiten tiefer im Funnel haben außerdem den Vorteil, dass sie politisch weniger umstritten sind als etwa eine Homepage, und Tests sich so wesentlich schneller durchführen lassen.
  3. Ease: Wie einfach lässt sich der Test technisch umsetzen.

Mit dieser Zahl ausgerüstet, lässt sich gut argumentieren, welche Tests im Backlog Priorität haben. Wenn man diese Optimierung hin zum kurzfristigen ROI noch um eine langfristige Strategie zur Weiterentwicklung des Projekts ergänzt, kann eigentlich nichts mehr schief gehen. Im Build-Schritt zumindest.

Measure: Wie testen?

An dieser Stelle muss die Atemlosigkeit von Agile und Lean einen Moment aussetzen. Der wichtigste Grundsatz während der Testdurchläufe ist Geduld.

Sobald die ersten User die einzelnen Varianten aufrufen und die ersten Ergebnisse vorliegen, ist die Versuchung groß, die beeindruckenden Uplifts zu kommunizieren. Diese Zahlen haben zu Beginn des Tests so viel Aussagekraft wie ein Würfelwurf. Damit ist also weder dem Unternehmen, noch dem AB/MV-Test-Projekt geholfen. Wie lange ein Test läuft, hängt vom Traffic und der Samplegröße ab, also der Anzahl von Nutzern in jeder Variante, die nötig ist, um ein statistisch sauberes Ergebnis für eine Kennzahl zu erreichen. Evan Miller hat einen praktischen Rechner programmiert, um schon vor Beginn des Test die Samplegröße zu planen. Er liefert außerdem ein paar sehr gute Argumente, warum man einen Test nicht stoppen sollte, bevor diese Zahl erreicht ist.

Learn: Das Problem mit quantitativen Daten

Learn

Am Ende eines erfolgreichen Tests steht immer eine statistisch bestätigte Gewinnervariante. Das ist schon mal großartig, aber es bleibt die Frage, warum genau diese Variante so erfolgreich war. Genau diese Antwort wird benötigt, um zu lernen und die nächste Iteration zu planen. Aus einem Vergleich von zwei Conversion Rates ergibt sich dieser Lerneffekt normalerweise nicht. Neben KPIs sollte deshalb so viel wie möglich gemessen werden. Also nicht nur die Gesamt-Conversion, sondern auch Micro-Conversions in der User-Journey und Interaktionen innerhalb der getesteten Seite. Wenn man also beispielsweise eine Landing-Page testet, ist nicht nur die Danke-Seite am Ende des Checkout-Funnels interessant,  sondern auch die Schritte die dorthin führen.

Das Maximum an Messtiefe ist Clicktracking, bei dem für jede Variante Mausbewegungen im Detail aufgezeichnet und zu Interaktionsvideos verarbeitet werden. Aber Clicktracking ist nicht der einzige Weg, um qualitative Daten in AB/MV-Tests zu integrieren, einige AB/MV-Testing-Tools erlauben auch das Ausspielen von Surveys mit offenen Fragen. Solche Fragebögen werden notorisch selten ausgefüllt, aber mit genügend Traffic kann man auch hier Anhaltspunkte nach dem »Warum« sammeln. Helfen kann natürlich auch der klassische Usability-Labortest. Hier bekommt man nicht nur Einblicke in die Stärken und Schwächen der Varianten, sondern auch Ideen für neue Tests

Immer im Kreis

AB-Testing ist ein großartiges Werkzeug, nicht nur um die Conversion zu erhöhen, sondern auch um leane und agile Prinzipien einzuführen. Wenn die Iterationen dann erstmal laufen, erzeugen sie konstant sehr überzeugende Daten, die den gesamten Designprozess in User-zentrierte Bahnen lenken. Erste Versuche mit AB-Testing sind nicht schwer – auch ohne großes Investment kann man mit einer einfachen Javascript-Library oder Google Content Experiments erste Erfahrungen sammeln.

Falls ihr solche Erfahrungen habt, würde ich mich freuen, wenn ihr sie mit uns teilt!

Über Björn Ganslandt (Gastautor)

Björn entwickelt mit seinen Kollegen bei intuio interaktive Produkte. Am liebsten vom Konzept bis zum Prototyp, was kein weiter Weg ist, wenn man gerne mit HTML, CSS und JavaScript arbeitet. Davor war er bei Peek & Cloppenburg für Usability und Conversion verantwortlich und hat das Kleinzeigensystem der Expat-Community »Just Landed« mit konzipiert.

Ein Kommentar

  1. Thorsten Wilhelm

    Tolle Einordnung von A/B- / MV Tests, mit hilfreichen Hinweisen zur Vorbereitung und Nachbereitung. Letztere bleibt meines Erachtens viel zu oft auf der Strecke, sie ist aber das absolut wichtigste, wenn es darum geht mit diesen Tests „schneller zu optimieren“.

Schreibe einen Kommentar

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