A / B-test faktureres ofte som en videnskabelig måde at validere designbeslutninger på. Af og til omtalt som delt test, er A / B-test en simpel proces, der på overfladen ser ud til at løfte konkrete resultater:
Opret to varianter på et designelement, veksle dem om på dit websted og registrer, hvordan dine brugere reagerer, sammenlign resultaterne, implementer, hvilken variation der bedst udføres. Det giver mening.
Det klassiske eksempel er: en rød knap vs en grøn knap, som vil blive tappet mere? Men det mere interessante spørgsmål er: En grøn knap vs den samme grønne knap, som vil blive tappet mere?
Hvad sker der, når vi A / B tester to identiske variationer? En A / A-test, hvis du vil.
For at teste gyldigheden af enhver A / B-test, har vi brug for en test, der har et 'korrekt' svar. Vi har brug for et rigtigt svar, fordi vi gerne vil vide, hvor meget det er, hvor sandsynligt er det, at A / B-testen vil give det resultat, det skal, og for det er vi nødt til at vide, hvilket resultat der skal forventes.
Hvis vi A / B tester to identiske knapper, skal resultatet være en død varme
Så lad os antage, at vi tester en grøn knap vs. den samme grønne knap, og at knappen er så lokkende, at 100% af brugerne vil trykke på den.
(Procentdelen betyder faktisk ikke, det kan være 14.872%. Det er vigtigt, at fordi knapperne er identiske, skal trykfrekvensen også være identisk.)
Hvis vi A / B tester to identiske knapper, skal resultatet være en død varme.
Kast en mønt. Hvilken side kommer op, hoveder eller haler? Vi ved, at der er to sider, begge identiske, så det er en 50-50 chance.
Hvis vi kaster vores mønt to gange, ved vi, at der er tre mulige resultater: 2 hoveder, 2 haler eller 1 hoved og 1 hale. Og så videre…
Lad os sige, at møntkassen er vores A / A-test; oddsene for hovedsiden kommer op er identiske med oddsene for haler siden kommer op, ligesom oddsene for en af vores grønne knapper bliver tappet er ens.
Så lad os skrive et hurtigt script i browseren (fordi de fleste A / B-test sker i browseren) for at simulere brugere, der trykker på en knap eller den anden, afhængigt af den ene, de præsenteres med.
Husk: vi tester to identiske varianter af en knap, og den måde, vi ved, at de er identiske, er, at vi behandler sandsynligheden for, at de bliver tappet som identiske. Alt vi søger er et konsistent (og derfor korrekt) resultat.
For det første har vi brug for et HTML-bord til at registrere vores resultater i, tabellen vil se sådan ud:
# Heads Tails Difference Margin of Error
I den første kolonne registrerer vi testens nummer (alle gode A / B-tests gentages for at bekræfte resultaterne, så vi gentager testen et par gange). Derefter registrerer vi antallet af Heads resultater, så antallet af haler resulterer. Søjlen efter det vil være forskellen mellem de to resultater (som skal være nul). Så registrerer vi fejlmarginen (som igen skal være 0%). Under bordet udskriver vi et resumé, gennemsnittet af alle resultaterne og det værste tilfælde.
Her er scriptet:
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 + "% 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}}Koden er kommenteret, så her er blot højdepunkterne:
For det første opstiller vi nogle variabler, herunder antallet af gange, vi ønsker at kaste mønten (bestOf) og antallet af gange, vi vil gentage testen (testrepetion).
Spoiler advarsel: Vi kommer til at komme ind i nogle ret høje sløjfer, for at undgå at bryde alles browser, kører vi testen med et interval hver 100ms.
Inde i funktionen performCoinToss løber vi det krævede antal gange, hver iteration af sløjfen bruger vi JavaScript's tilfældige funktion til at generere enten en 1 eller en 0, som igen stiger enten headsCounter eller tailsCounter .
Herefter skriver vi resultatet fra testen til bordet.
Til sidst, hvis testen er blevet gentaget, hvor mange gange vi vil have, finder vi gennemsnittet og i værste fald, skriver dem til resuméet, og fjerner intervallet.
Her er resultatet . Som du kan se, er den gennemsnitlige forskel godt, det vil være anderledes for dig, men da jeg skriver dette er den gennemsnitlige forskel 2,8333333333333335, den gennemsnitlige fejl er derfor 23,611111111111114%.
Over 23% fejl inspirerer ikke tilliden, især da vi ved, at forskellen skal være 0%. Hvad er værre er, at mit værste tilfælde er 8, det er 10-2 til fordel for hoveder.
Okay, så testen var ikke fair. En ægte A / B-test ville aldrig hævde at finde et afgørende resultat fra kun 12 brugere.
A / B-test bruger noget kaldet "statistisk betydning", hvilket betyder, at testen skal løbe nok gange for at opnå et brugbart resultat.
Så lad os fordoble variablen bestOf og se, hvor langt vi skal gå for at nå en fejlmargin på mindre end 1% - svarende til 99% tillid.
På et bestOf på 24 (i skrivende stund) er den gennemsnitlige forskel 3,1666666666666665, hvilket er 13,19444444444444445%. Et skridt i den rigtige retning! Prøv det selv (dine resultater vil variere).
Lad os fordoble det igen. Denne gang er min gennemsnitlige forskel 6,6666666666666667, med en fejlmargin på 13.88888888888889%. Endnu værre er det værste tilfælde 16, det er en fejl på 33.33333333333333%! Du kan prøv den ene for dig selv også.
Faktisk ingen priser for at gætte, at vi kan fortsætte: bedste af 96 , bedste af 192 , bedste af 384 , bedste af 768 , bedst af 1536 , bedste af 3072 , bedst af 6144 , bedst af 12288 , bedste af 24576 , bedste af 49152 , bedste af 98304 .
Endelig falder det værste tilfælde under 1% til et bedst af 98304. Med andre ord kan vi være 99% sikre på, at testen er korrekt.
Så i en A / A-test, hvilket resultat vi vidste på forhånd, tog det en prøvestørrelse på 98.304 for at nå en acceptabel fejlmargin.
Når A / B-test diskuteres, minder en ven om en ven, som A / B testede en enkelt knap på hans / hendes websted og straks lavede et usandsynligt overskud (den faktiske dollarns værdi af knappen øges hver gang jeg hører historie).
I disse fortællinger testes knapperne normalt for mikrokopi, "Download min ebook" vs. "Download min gratis ebook". Det bør ikke være en overraskelse, at sidstnævnte vinder. Det er en forbedring, som enhver god tekstforfatter ville gøre. En mere hensigtsmæssig A / B test ville være "Download min ebook" vs. "Download ebook" (mine penge er på sidstnævnte).
Hvis du finder dig selv med et resultat, der er tungtvejet mod en af mulighederne, foreslår det at noget er meget galt med en af dine variationer. Oftere vil et godt resultat være en forbedring på under 5%, hvilket giver et problem, hvis du tester med omkring 1000 brugere (hvis fejlmargin er omkring 5%).
Jo mere nyttigt en test er, jo strengere sejrenes margen for en variation eller den anden. Men jo strammere vindermarginen er, jo større er stikprøvestørrelsen nødvendig for at give dig en acceptabel lille fejlmargin.
Mark Twain, muligvis citat Disraeli, brugte engang sætningen: løgne, forbandede løgne og statistikker. Hvormed han mente, at noget vist sig ved statistikker, er ikke nødvendigvis sandt. Statistikker kan bruges til at bevise alt, hvad du vil have dem til.
A / B-test vil give dig et resultat, men det er et resultat, der vil sige mere om dig og om, hvad du forventede at finde, end om dine kunder
Det farligste ved A / B-test er, at det kan bevise alt, hvad du vil have det til; det kan producere falske positiver, og det gør det muligt for os at skelne mønstre, der ikke understøttes korrekt.
Desuden kan en A / B-test indikere, at en grøn knap overgår en rød knap, men hvad med en blå knap? Selv succesfulde A / B-test giver os kun mulighed for at validere vores designbeslutninger inden for rammerne af selve testen.
For at en A / B-test skal fungere som påtænkt, har vi brug for to modstridende betingelser for at være sandt:
Desværre har de fleste steder ikke en stikprøvestørrelse, der er stor nok til at nå en tilstrækkelig lille fejlmargin. Og fordi vi ikke kan øge vores stikstørrelse (vi ville, hvis vi kunne), er vores eneste valg at øge variationen af mulighederne for at give et klart resultat, hvilket skævprøver testen med vores præferencer.
A / B-test vil give dig et resultat, men det er et resultat, der vil sige mere om dig og om, hvad du forventede at finde, end om dine kunder. Når det kommer til at træffe designbeslutninger på ethvert andet websted end dem med meget store mængder trafik, kan vi lige så godt smide en mønt, som A / B-test.