A / B-testen worden vaak gefactureerd als een wetenschappelijke manier om ontwerpbeslissingen te valideren. Af en toe splits testen genoemd, A / B testen is een eenvoudig proces dat op het eerste gezicht concrete resultaten lijkt te beloven:

Maak twee variaties op een ontwerpelement, wissel ze willekeurig op uw site en leg vast hoe uw gebruikers reageren, vergelijk de resultaten en voer de meest geschikte variant uit. Het is logisch.

Het klassieke voorbeeld is: een rode knop versus een groene knop, waarop meer wordt getikt? De interessantere vraag is echter: een groene knop versus dezelfde groene knop, die meer zal worden afgetapt?

Wat gebeurt er als we A / B twee identieke varianten testen? Een A / A-test, als je wilt.

Groene knop versus groene knop

Om de geldigheid van een A / B-test te testen, hebben we een test nodig met een 'correct' antwoord. We hebben een goed antwoord nodig, want we willen weten dat alle dingen gelijk zijn, hoe waarschijnlijk het is dat de A / B-test het gewenste resultaat oplevert, en daarvoor moeten we weten wat het resultaat is dat we verwachten.

Als we A / B twee identieke knoppen testen, moet het resultaat een dead heat zijn

Laten we dus aannemen dat we een groene knop tegen dezelfde groene knop testen en dat de knop zo verleidelijk is dat 100% van de gebruikers erop tikken.

(Het percentage doet er niet toe, het zou 14.872% kunnen zijn.) Wat belangrijk is, is dat omdat de knoppen identiek zijn, de taprate ook identiek moet zijn.)

Als we A / B twee identieke knoppen testen, moet het resultaat een dead heat zijn.

De muntworp test

Een munt opgooien. Welke kant zal omhoog komen, kop of munt? We weten dat er twee kanten zijn, beide identiek, dus het is een kans van 50-50.

Als we onze munt twee keer gooien, weten we dat er drie mogelijke uitkomsten zijn: 2 koppen, 2 staarten of 1 kop en 1 staarten. Enzovoort…

Laten we zeggen dat de toss een A / A-test is; de kansen dat de hoofden omhoog komen, zijn identiek aan de kansen dat de staartenzijde omhoog komt, net zoals de kansen van een van onze groene knoppen die worden aangeboord gelijk zijn.

Laten we dus een snel script in de browser schrijven (omdat de meeste A / B-tests in de browser plaatsvinden) om te simuleren dat gebruikers op de ene of de andere knop tikken, afhankelijk van de manier waarop ze worden gepresenteerd.

Let op: we testen twee identieke varianten van een knop, en de manier waarop we weten dat ze identiek zijn, is dat we de kans op identiek kloppen beschouwen. Alles wat we zoeken is een consistent (en dus correct) resultaat.

Ten eerste hebben we een HTML-tabel nodig om onze resultaten in op te nemen, de tabel ziet er als volgt uit:

#HeadsTailsDifferenceMargin of Error

In de eerste kolom nemen we het nummer van de test op (alle goede A / B-tests worden herhaald om de resultaten te verifiëren, dus we zullen de test een paar keer herhalen). Vervolgens nemen we het aantal Heads- resultaten en vervolgens het aantal Tails- resultaten op. De kolom hierna is het verschil tussen de twee resultaten (die nul zouden moeten zijn). Vervolgens nemen we de foutmarge op (die ook weer 0% zou moeten zijn). Onder de tabel drukken we een samenvatting af, het gemiddelde van alle resultaten en het slechtste resultaat.

Hier is het script:

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}}

De code is becommentarieerd, dus hier zijn slechts de hoogtepunten:

Eerst stellen we een aantal variabelen in, waaronder het aantal keren dat we de munt willen gooien (bestOf) en het aantal keren dat we de test willen herhalen (testRepeat).

Spoiler alert: we komen in een aantal behoorlijk hoge loops terecht, dus om te voorkomen dat de browser van iemand wordt overtreden, voeren we de test uit met een interval van elke 100 ms.

In de performCoinToss- functie herhalen we het vereiste aantal keren, elke iteratie van de lus gebruiken we de willekeurige functie van JavaScript om een ​​1 of een 0 te genereren, die op zijn beurt ofwel de headsCounter of de tailsCounter verhoogt .

Vervolgens schrijven we het resultaat van die test naar de tafel.

Ten slotte, als de test het aantal keren is herhaald dat we zouden willen, vinden we de gemiddelden, en in het slechtste geval, schrijf ze naar de samenvatting en wis het interval.

Dit is het resultaat . Zoals je kunt zien is het gemiddelde verschil, wel, het zal anders zijn voor jou, maar terwijl ik dit schrijf, is het gemiddelde verschil 2.8333333333333335, de gemiddelde fout is dus 23.611111111111114%.

Meer dan 23% fouten wekken geen vertrouwen, vooral omdat we weten dat het verschil 0% moet zijn. Wat erger is, is dat mijn slechtste case-uitkomst 8 is, dat is 10-2 in het voordeel van heads.

Met behulp van een aantal realistische cijfers

Oké, dus die test was niet eerlijk. Een echte A / B-test zou nooit beweren een sluitend resultaat te hebben van slechts 12 gebruikers.

A / B-testen gebruiken iets dat "statistische significantie" wordt genoemd, wat betekent dat de test voldoende lang moet lopen om een ​​bruikbaar resultaat te bereiken.

Dus laten we de bestof variabele verdubbelen en zien hoe ver we moeten gaan om een ​​foutmarge van minder dan 1% te bereiken - het equivalent van 99% vertrouwen.

Met een maximum van 24 (op het moment van schrijven) is het gemiddelde verschil 3,1666666666666665, dat is 13,194444444444445%. Een stap in de goede richting! Probeer het zelf (uw resultaten zullen variëren).

Laten we het nog een keer verdubbelen. Deze keer mijn gemiddelde verschil van 6.666666666666667, met een foutenmarge van 13.88888888888889%. Erger nog, het ergste geval is 16, dat is een fout van 33.33333333333333%! Jij kan probeer die ook voor jezelf.

Eigenlijk geen prijzen om te raden dat we door kunnen gaan: beste van 96 , beste van 192 , beste van 384 , beste van 768 , beste van 1536 , beste van 3072 , beste van 6144 , beste van 12288 , beste van 24576 , beste van 49152 , beste van 98304 .

Tot slot, met de beste score van 98304, daalt het worstcasescenario tot minder dan 1%. Met andere woorden, we kunnen er zeker van zijn dat de test accuraat is.

Dus bij een A / A-test, waarvan we het resultaat van tevoren wisten, kostte het een steekproefomvang van 98,304 om een ​​aanvaardbare foutenmarge te bereiken.

De knop $ 3.000.000.000

Wanneer A / B-testen worden besproken, herinnert iemand zich een vriend van een vriend, die A / B een enkele knop op zijn / haar site testte en onmiddellijk een onwaarschijnlijke winst maakte (de werkelijke waarde van de dollar neemt telkens toe als ik de verhaal).

In die verhalen worden de knoppen meestal getest op micro-kopie, "Download mijn e-boek" of "Download mijn gratis e-boek". Het moet geen verrassing zijn dat de laatste wint. Het is een verbetering die een goede copywriter zou maken. Een meer geschikte A / B-test zou zijn "Download mijn e-boek" versus "Download het e-boek" (mijn geld is hierop).

Als je merkt dat je een resultaat hebt dat zwaar gewogen is naar een van de opties, suggereert het dat er iets erg mis is met een van je variaties. Vaker is een goed resultaat een verbetering van minder dan 5%, wat een probleem is als u met ongeveer 1000 gebruikers test (de foutenmarge is ongeveer 5%).

Hoe nuttiger een test is, des te groter de winstmarge voor de ene variatie of de andere. Hoe groter de winstmarge, hoe groter de steekproefomvang die nodig is om u een aanvaardbaar kleine foutenmarge te geven.

Leugens, verdomde leugens en A / B-tests

Mark Twain, mogelijk met vermelding van Disraeli, gebruikte ooit de uitdrukking: leugens, verdomde leugens en statistieken. Waarmee hij bedoelde dat iets door statistieken bewezen is, is niet noodzakelijk waar. Statistieken kunnen worden gebruikt om te bewijzen wat u maar wilt.

A / B-testen zullen u een resultaat opleveren, maar het is een resultaat dat meer over u zal zeggen en over wat u verwachtte te vinden, dan over uw klanten

Het meest gevaarlijke aan A / B-testen is dat het alles kan bewijzen wat u maar wilt; het kan valse positieven produceren en het stelt ons in staat om patronen te onderscheiden die niet goed worden ondersteund.

Verder kan een A / B-test aangeven dat een groene knop beter presteert dan een rode knop, maar hoe zit het met een blauwe knop? Zelfs succesvolle A / B-tests stellen ons alleen in staat om onze ontwerpbeslissingen te valideren binnen de context van de test zelf.

Om een ​​A / B-test te laten functioneren zoals bedoeld, moeten twee tegengestelde voorwaarden kloppen:

  1. er moet een minimale variatie zijn tussen de opties, dus de test wordt niet gewogen naar onze voorkeur;
  2. de steekproefomvang moet voldoende zijn om de foutenmarge kleiner te maken dan de sterkte van het resultaat.

Helaas hebben de meeste sites geen steekproefomvang die groot genoeg is om een ​​voldoende kleine foutenmarge te bereiken. En omdat we onze steekproefomvang niet kunnen vergroten (als we dat zouden kunnen), is onze enige keuze om de variatie van de opties te vergroten om een ​​duidelijk resultaat te krijgen, waardoor de test wordt scheefgetrokken door onze voorkeuren.

A / B-testen zullen u een resultaat opleveren, maar het is een resultaat dat meer over u zal zeggen en over wat u verwachtte te vinden, dan over uw klanten. Als het gaat om het maken van ontwerpbeslissingen op een andere site dan die met zeer grote verkeersvolumes, kunnen we net zo goed een munt gooien, als A / B-test.

Uitgelichte afbeelding, toss afbeelding via Shutterstock.