A / B-Tests werden häufig als wissenschaftliche Methode zur Validierung von Designentscheidungen berechnet. Gelegentlich als Split-Test bezeichnet, ist der A / B-Test ein einfacher Prozess, der auf der Oberfläche konkrete Ergebnisse verspricht:

Erstellen Sie zwei Varianten eines Designelements, tauschen Sie sie zufällig auf Ihrer Website aus und zeichnen Sie auf, wie Ihre Nutzer reagieren, vergleichen Sie die Ergebnisse und implementieren Sie die jeweils beste Variante. Es macht Sinn.

Das klassische Beispiel ist: ein roter Knopf gegen einen grünen Knopf, der mehr angezapft wird? Die interessantere Frage ist jedoch: ein grüner Knopf gegen den gleichen grünen Knopf, der mehr angezapft wird?

Was passiert, wenn wir A / B zwei identische Varianten testen? Ein A / A-Test, wenn Sie so wollen.

Grüner Knopf gegen grünen Knopf

Um die Gültigkeit eines A / B-Tests zu testen, benötigen wir einen Test, der eine "richtige" Antwort hat. Wir brauchen eine korrekte Antwort, weil wir wissen wollen, dass der A / B-Test bei gleichen Bedingungen wahrscheinlich das gewünschte Ergebnis liefert und wir daher wissen müssen, welches Ergebnis zu erwarten ist.

Wenn wir A / B zwei identische Tasten testen, sollte das Ergebnis eine Tothitze sein

Nehmen wir an, wir testen einen grünen Knopf gegen den gleichen grünen Knopf, und der Knopf ist so verlockend, dass 100% der Benutzer ihn antippen.

(Der Prozentsatz ist nicht wirklich wichtig, es könnte 14,872% sein. Wichtig ist, dass die Tap-Rate identisch sein sollte, weil die Buttons identisch sind.)

Wenn wir A / B zwei identische Tasten testen, sollte das Ergebnis eine Tothitze sein.

Der Münzwurf-Test

Wirf eine Münze. Welche Seite wird auftauchen, Kopf oder Zahl? Wir wissen, dass es zwei Seiten gibt, beide identisch, also ist es eine 50-50 Chance.

Wenn wir unsere Münze zweimal werfen, wissen wir, dass es drei mögliche Ergebnisse gibt: 2 Köpfe, 2 Schwänze oder 1 Kopf und 1 Schwänze. Und so weiter…

Nehmen wir an, der Münzwurf ist unser A / A-Test; Die Wahrscheinlichkeit, dass die Kopfseite auftaucht, ist identisch mit der Wahrscheinlichkeit, dass die Zahl der Schwänze hochkommt, genauso wie die Wahrscheinlichkeit, dass einer unserer grünen Knöpfe angetippt wird, gleich ist.

Lassen Sie uns also ein kurzes Skript im Browser schreiben (weil die meisten A / B-Tests im Browser ablaufen), um Benutzer zu simulieren, die auf die eine oder die andere Schaltfläche tippen, je nachdem, auf welcher Seite sie angezeigt werden.

Denken Sie daran: Wir testen zwei identische Variationen einer Schaltfläche, und die Art und Weise, wie wir sie kennen, ist identisch mit der Wahrscheinlichkeit, dass sie identisch sind. Alles, wonach wir suchen, ist ein konsistentes (und daher korrektes) Ergebnis.

Erstens benötigen wir eine HTML-Tabelle, in der unsere Ergebnisse gespeichert werden. Die Tabelle sieht folgendermaßen aus:

#HeadsTailsDifferenceMargin of Error

In der ersten Spalte notieren wir die Nummer des Tests (alle guten A / B-Tests werden wiederholt, um die Ergebnisse zu verifizieren, daher wiederholen wir den Test einige Male). Als nächstes werden wir die Anzahl der Heads- Ergebnisse und dann die Anzahl der Tails- Ergebnisse aufzeichnen. Die Spalte danach ist die Differenz zwischen den beiden Ergebnissen (die Null sein sollte). Dann werden wir die Fehlerquote aufzeichnen (die wiederum 0% sein sollte). Unterhalb der Tabelle drucken wir eine Zusammenfassung, den Durchschnitt aller Ergebnisse und das Worst-Case-Ergebnis aus.

Hier ist das Skript:

var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + "" + headsCounter + "" + tailsCounter + "" + difference + "" + error + "%"; // add result to tabletotalDifference += difference; // increments the difference counterworstDifference = difference > worstDifference ? difference : worstDifference; // updates worstDifferenceif(--testRepeat == 0){var averageDifference = totalDifference / testCount, // finds average differenceaverageError = (averageDifference / bestOf) * 100; // finds the average error margindocument.getElementById("summary").innerHTML = "

Average difference: " + averageDifference + "

Average margin of error: " + averageError + "%

Worst Case: " + worstDifference + "

"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}

Der Code ist kommentiert, hier sind nur die Highlights:

Zuerst stellen wir einige Variablen auf, einschließlich der Anzahl, wie oft wir die Münze werfen wollen (bestOf) und wie oft wir den Test wiederholen wollen (testRepeat).

Spoilerwarnung: Wir werden in einige ziemlich hohe Schleifen geraten, um den Browser eines anderen zu brechen, führen wir den Test alle 100ms in Intervallen durch.

Innerhalb der performCoinToss- Funktion durchlaufen wir die erforderliche Anzahl von Wiederholungen , bei jeder Wiederholung der Schleife verwenden wir die Zufallsfunktion von JavaScript, um entweder eine 1 oder eine 0 zu erzeugen, die wiederum entweder den headsCounter oder den tailsCounter inkrementiert .

Als nächstes schreiben wir das Ergebnis aus diesem Test in die Tabelle.

Schließlich, wenn der Test die Anzahl der Male wiederholt wurde, die wir möchten, finden wir die Durchschnittswerte und den schlimmsten Fall, schreiben Sie sie in die Zusammenfassung und löschen Sie das Intervall.

Hier ist das Ergebnis . Wie Sie sehen können, ist der durchschnittliche Unterschied, nun, es wird anders für Sie sein, aber da ich dies schreibe, ist der durchschnittliche Unterschied 2,8333333333333335, der durchschnittliche Fehler ist daher 23.611111111111114%.

Ein Fehler von über 23% führt nicht zu Vertrauen, zumal wir wissen, dass der Unterschied bei 0% liegen sollte. Was noch schlimmer ist, ist, dass mein Worst-Case-Ergebnis 8 ist, das ist 10-2 für Köpfe.

Mit einigen realistischen Zahlen

Okay, dieser Test war nicht fair. Ein echter A / B-Test würde niemals behaupten, ein schlüssiges Ergebnis von nur 12 Benutzern zu finden.

A / B-Tests verwenden etwas, das als "statistische Signifikanz" bezeichnet wird, was bedeutet, dass der Test genügend oft ausgeführt werden muss, um ein umsetzbares Ergebnis zu erzielen.

Also, lasst uns die bestOf- Variable verdoppeln und sehen, wie weit wir gehen müssen, um eine Fehlermarge von weniger als 1% zu erreichen - das entspricht 99% Vertrauen.

Bei einem best off 24 (zum Zeitpunkt des Schreibens) ist die durchschnittliche Differenz 3,16666666666666665, was 13,194444444444445% ist. Ein Schritt in die richtige Richtung! Probieren Sie es selbst aus (Ihre Ergebnisse werden variieren).

Lass es uns nochmal verdoppeln. Diesmal, meine durchschnittliche Differenz 6.666666666666667, mit einer Marge für den Fehler von 13.88888888888889%. Schlimmer noch, der schlimmste Fall ist 16, das ist ein Fehler von 33.333333333333333%! Sie können probier das mal für dich auch.

Eigentlich keine Preise zu erraten, dass wir weitermachen können: Beste von 96 , Beste von 192 , Beste von 384 , Beste von 768 , Bestes von 1536 , best von 3072 , Beste von 6144 , Beste von 12288 , Beste von 24576 , Beste aus 49152 , Beste von 98304 .

Bei einem Höchstwert von 98304 fällt das Worst-Case-Szenario unter 1%. Mit anderen Worten, wir können zu 99% sicher sein, dass der Test genau ist.

In einem A / A-Test, dessen Ergebnis wir im Voraus wussten, brauchte es eine Stichprobengröße von 98.304, um eine akzeptable Fehlerquote zu erreichen.

Der 3.000.000.000 $ -Button

Wann immer A / B-Tests diskutiert werden, erinnert sich jemand an einen Freund eines Freundes, der auf seiner Seite einen einzigen Button getestet hat und sofort einen unwahrscheinlichen Gewinn gemacht hat (der tatsächliche Dollarwert des Buttons erhöht sich jedes Mal, wenn ich das höre Geschichte).

In diesen Geschichten werden die Tasten normalerweise für Mikrokopie, "Download mein E-Book" vs. "Download mein kostenloses E-Book" getestet. Es sollte keine Überraschung sein, dass Letzterer gewinnt. Es ist eine Verbesserung, die jeder gute Texter machen würde. Ein geeigneterer A / B-Test wäre "Laden Sie mein E-Book herunter" vs. "Laden Sie das E-Book herunter" (mein Geld ist auf letzteres).

Wenn Sie feststellen, dass ein Ergebnis stark auf eine der Optionen gewichtet ist, deutet dies darauf hin, dass bei einer Ihrer Varianten etwas nicht stimmt. Ein gutes Ergebnis ist häufiger eine Verbesserung von weniger als 5%, was ein Problem darstellt, wenn Sie mit etwa 1000 Benutzern testen (die Fehlermarge beträgt etwa 5%).

Je nützlicher ein Test ist, desto enger ist die Gewinnspanne für die eine oder die andere Variante. Je enger die Gewinnmarge ist, desto größer ist jedoch die Stichprobengröße, die benötigt wird, um eine akzeptable Fehlerquote zu erreichen.

Lügen, verdammte Lügen und A / B-Tests

Mark Twain, der möglicherweise Disraeli zitiert, benutzte einmal den Satz: Lügen, verdammte Lügen und Statistiken. Womit er gemeint hat, dass etwas durch Statistiken bewiesen ist, ist nicht unbedingt wahr. Statistiken können verwendet werden, um alles zu beweisen, was Sie wollen.

A / B-Tests liefern Ihnen ein Ergebnis, aber es ist ein Ergebnis, das mehr über Sie und über das, was Sie erwartet haben, aussagt, als über Ihre Kunden

Das gefährlichste an A / B-Tests ist, dass es alles beweisen kann, was Sie wollen; es kann falsche positive Ergebnisse erzeugen und es ermöglicht uns, Muster zu erkennen, die nicht richtig unterstützt werden.

Außerdem kann ein A / B-Test anzeigen, dass ein grüner Knopf einen roten Knopf übertrifft, aber was ist mit einem blauen Knopf? Selbst erfolgreiche A / B-Tests erlauben uns nur, unsere Designentscheidungen im Rahmen des Tests selbst zu validieren.

Damit ein A / B-Test wie beabsichtigt funktioniert, müssen zwei entgegengesetzte Bedingungen erfüllt sein:

  1. Es sollte minimale Unterschiede zwischen den Optionen geben, daher wird der Test nicht nach unserer Präferenz gewichtet;
  2. Die Stichprobengröße sollte ausreichen, dass die Fehlermarge geringer ist als die Stärke des Ergebnisses.

Leider haben die meisten Websites keine Stichprobengröße, die groß genug ist, um eine ausreichend kleine Fehlerspanne zu erreichen. Und weil wir unsere Stichprobengröße nicht erhöhen können (wir würden, wenn wir könnten), ist unsere einzige Wahl, die Variation der Optionen zu erhöhen, um ein klares Ergebnis zu erzielen, was den Test nach unseren Präferenzen verzerrt.

A / B-Tests liefern Ihnen ein Ergebnis, aber es ist ein Ergebnis, das mehr über Sie und über das, was Sie erwartet haben, aussagt, als über Ihre Kunden. Wenn es darum geht, Designentscheidungen an anderen Standorten als denen mit sehr hohem Verkehrsaufkommen zu treffen, können wir auch eine Münze als A / B-Test werfen.

Ausgewähltes Bild, Münze werfen Bild über Shutterstock.