Jeder hat es schon getan. Ehrlich. Ich weiß es. Ich habe es auch schon getan und meine Kollegen haben es auch schon getan.
Was?
Einen Test à la “Probier doch einfach mal aus, den Button hierher zu machen und die andere Box lieber weiß.” Oder so ähnlich. Wenn man wirklich nicht weiß, was das Problem einer Seite (bzw. der dort nicht erfolgenden Konversion) ist, dann kommt man schon in die Versuchung einfach mal ein paar Dinge auszuprobieren, von denen man glaubt, sie könnten eine Auswirkung haben.
Was ist so schlimm daran?
A) Je kleiner die Veränderung, desto größer ist die Wahrscheinlichkeit, dass das Resultat Zufall ist
Vor allem bei Seiten mit wenig Traffic und/oder wenn ohne Segementierung gearbeitet wird (was meist dort der Fall ist), sind die Unterschiede zwischen derart kleinen Iterationen so gering, dass unterschiedliche Konversionsraten ein reines Zufallsprodukt sind. Im Reporting sieht so ein Test dann so oder so ähnlich aus:
Bild 1) Tagesdarstellung von Resultaten eines A/B Tests (nicht kumuliert)
Der Zufalls-Teufel sorgt dafür, dass sich die Ergebnisse insgesamt immer weiter aneinander anschmiegen – einige Tage lang liegt eine Version vorne, dann die andere Version. Wenn man lange genug wartet, hat man vielleicht Glück, und für kurze Zeit gibt es eine Siegervariante.
Bild 2: Darstellung mit kumulierten Werten zeigt das Zufalls-Problem
B) (das größere Problem) Wenn es einen Sieger gibt, weiß niemand WARUM.
Ich gebe zu, das ist ein wenig abstrakt. Aber es ist das viel viel größere Problem (denn in Fällen mit genügend Traffic entwickeln selbst die oben genannten Tests nach wenigen Wochen einen fast stabilen Trend, auch wenn die Uplifts dann irgendwo im Bereich von 0,52% oder 2.13% sind – wer will das schon?).
Warum ist es ein so großes Problem?
Weil hinter dem Test keine echte qualitative Hypothese gesteckt hat.
Eine gute Test-Hypothese beinhaltet die Erklärung für eine mögliche Ursache, das “Warum”. Wenn der Warenkorb-Button also in Größe und Position verändert wird, müsste eine gute Hypothese lauten:
“Die meisten Nutzer übersehen den Button.
Wenn wir ihn größer machen, steigt die Chance der Konversion, weil die Nutzer ihn nun sehen”.
Jeder, der so eine Hypothese guten Gewissens nachvollziehen und als wichtigste Optimierung für einen Test priorisiert, sollte diesen Test auch machen. Aber ehrlich: Ist das wirklich das Problem der Seite?
Das Formulieren echter Hypothesen ist in Wirklichkeit mehr Arbeit als das direkte “Ausprobieren”. Optimierer müssen sich mit der Seite intensiver auseinandersetzen, sie mit den Augen der Nutzer sehen. Und sie müssen sich fragen “Ist es das wirklich?”…
Denn: Traffic ist kostbar, Ressourcen sind kostbar, alles kostet Geld – selbst mit kostenlosen Tools. Wirklich.
Tests, die scheitern, sollte man wenigstens dazu nutzen daraus zu lernen – in Wirklichkeit will jedoch jeder lieber aus erfolgreichen Tests lernen.
Wie kann man aus einen schlechten Test lernen, wenn man die Ursachen (sprich die Hypothese) nicht kennt?
Man wird sagen “Menno, ich dachte, das funktioniert” (frustrierten Gesichtsausdruck nicht vergessen).
Das reicht aber nicht.
Tests ohne echte Hypothesen werden zu echten Problemen
Spätestens, wenn man mehrere solcher Verlegenheiten durchtestet, wird es ein Problem. Dann laufen Variante A1 und B1 gegen C1 und C2. Schnell wird sogar (auch aus Verlegenheit) ein echter multivariater Test daraus. Das Ergebnis sieht meist nicht besser aus (irgendwie so):
Bild 3: Noch mehr Zufälle auf einem Haufen machen es nicht besser
Nach wenigen Wochen Laufzeit wird dann einfach die Siegervariante online gestellt. Auch wenn sich meistens eine kleine Gruppe von Leuten bemüht, die Ergebnisse zu interpretieren, endet die Diskussion in einem kollektiven “Pfff….” und einer sagt irgendwann:
“Lasst uns einfach die Siegervariante ausrollen”.
Das ist dann der Todesstoß der Optimierung (auch wenn es einen Uplift gab), denn echte Optimierung endet mit einem Learning, d.h. alle Beteiligten (am besten die gesamte Organisation) lernen aus den Resultaten. Ihre Hypothese wird validiert – oder widerlegt. Beider ist wichtig zu wissen. Das funktioniert aber – wie schon gesagt – nur bei einer echten Hypothese.
Verlegenheitstester und Ausprobierer nehmen sich diese Chance und vergeuden viel Zeit, Traffic, Ressourcen, und verpassen die Chance aus Tests zu lernen.
Bild 4: Aus den Verlierervarianten kann man nur lernen, wenn man weiß, warum sie nicht funktionieren
Optimieren ist nicht Ausprobieren!
Die Probleme von Tests mit fehlenden oder schwachen Hypothesen sind zusammenfassend:
Zufallsresultate, die oft nicht signifikante Unterschiede produzieren (kein hohes Konfidenzlevel)
Tests müssen daher länger laufen als nötig
Wenn Varianten gewinnen / verlieren, weiß niemand “Warum”
Daraus lässt sich nicht lernen (und daher auch keine Anschlusstests ableiten)
Die Mühe erzeugt im besten Fall einen kleinen Uplift, aber kein Wissen
Um ehrlich zu sein war alles eine große Verschwendung von (sehr teuren) Ressourcen
Daher gilt:
Liebe Conversion SuperHEROES, bitte stellt Eure Hypothesen auf den Prüfstand, bevor ihr daraus ein Testkonzept / einen Testplan macht! Fragt Euch:
“Was ist der Grund dafür, dass das besser funkionieren könnte? Warum? Was passiert genau, wenn wir das verändern?”
Seid ehrlich zu Euch selbst, denn Traffic ist teuer, Zeit ist kostbar und Testing-Ressourcen wertvoll!
Kleine Zugabe: Die bessere Hypothese wäre…
Wer sich jetzt fragt, wie denn eine bessere Hypothese aussehen kann, dem möchte ich auf Basis der Button-Problematik von oben ein paar konkrete Beispiele nennen:
Bild 5) Beispielseite http://www.mytheresa.com/de-de/tribtoo-105-platform-pumps-155259.html
Beispiele für “oberflächliche” Hypothesen ohne echtes “Warum wären”:
Ändere Buttonfarbe / -größe / -stil / -position
Mach’ die Box mit dem Inhalt “hübscher”
Platziere die alternativen Bilder unter dem Hauptbild
…
So ließe sich schnell ein einfacher Test mit mehreren Varianten erzeugen. Doch hinter all diesen Veränderungen fällt es mehr oder weniger schwer, den wahren Grund aus Nutzersicht zu formulieren (“ich (der Nutzer) kaufe eher, wenn die Bilder links stehen…” WTF?).
Bessere Hypothesen (aus Nutzersicht -> mit Ableitung) sind:
“685 € sind viel Geld – vielleicht kann ich irgendwo anders ein Schnäppchen machen” -> Zeige dem Nutzer, dass es diesen Schuh zu diesem Preis nur hier gibt, und die Wahrhscheinlichkeit für den Kauf (oder Nicht-Abbruch) steigt.
“Brauche ich das wirklich?” -> Zeige dem Kunden, was die (emotionalen) Werte (Value Propositions) dieses Produktes sind um seinen Wunsch zu bestärken, dann wird er weniger zaudern und das Risiko des Abbruchs sinkt.
“So teure Schuhe kaufe ich lieber dort, wo ich sie sehen kann…” -> Räume die wichtigsten Bedenken des Kunden vor dem Kauf aus (Häufige Fragen) und blende Hotline “above the fold” (steht zu tief) und Rückgabeoptionen prominenter ein.
Die Hauptaspekte dieser Thesen lassen sich unter den Überschriften:
Stimulanz (Alleinstellung)
Relevanz (Value Prosposition)
Sicherheit (Bedenken ausräumen)
zusammenfassen. Alle diese (und noch viel mehr) Aspekte gibt es übrigens in dem Framework “Sieben Ebenen der Konversion”, das wir hier schon vor einiger Zeit zusammengefasst haben. Falls sich jemand fragt, wofür man ein Framework braucht: Um die Verlegenheitsphase und Ausprobiertests zu beenden, lassen sich mit dem Framework in einer Art Checkliste (so hoffe ich) bessere Hypothesen erzeugen. Das Framework wird hier im Blog erklärt (in einer etwas älteren Fassung) oder etwas konkreter und detallierter im Buch “zum Blog”.
Vielleicht hat ja einmal jemand Lust, die beiden Arten von Tests in ihrer Performance gegeneinander zu testen – eine Art Meta-Test.
Weitere Infos zu dem Thema:
5 grobe Testing-Fehler, die viel Geld kosten können
Checkliste: Die vier Erfolgssäulen der Conversion-Strategie
War das schon alles? Weitere 10 “Tödliche Fehler der Conversion Optimierung”
