A / B-testning faktureras ofta som ett vetenskapligt sätt att validera designbeslut. Av och med kallad split testning är A / B-testning en enkel process som på ytan verkar lova konkreta resultat:
Skapa två variationer på ett designelement, byt dem slumpmässigt på din webbplats och registrera hur användarna reagerar, jämföra resultaten, genomföra vilken variant som helst bäst utfört. Det är vettigt.
Det klassiska exemplet är: en röd knapp vs. en grön knapp, vilken kommer att tappas mer? Den mer intressanta frågan är emellertid: En grön knapp vs. samma gröna knapp, vilken kommer att tappas mer?
Vad händer när vi A / B testar två identiska variationer? Ett A / A-test, om du vill.
För att testa giltigheten för något A / B-test behöver vi ett test som har ett "korrekt" svar. Vi behöver ett korrekt svar eftersom vi vill veta, hur som helst, hur sannolikt är det att A / B-testet kommer att ge det resultat det borde, och för det behöver vi veta vad som ska förväntas.
Om vi A / B testar två identiska knappar, ska resultatet vara en död värme
Så låt oss anta att vi testar en grön knapp mot samma gröna knapp, och att knappen är så lockande att 100% av användarna klickar på den.
(Procentandelen spelar ingen roll, det kan vara 14.872%. Det som är viktigt är att eftersom knapparna är identiska, bör kretshastigheten också vara identisk.)
Om vi A / B testar två identiska knappar, ska resultatet vara en död värme.
Singla slant. Vilken sida kommer upp, huvud eller svansar? Vi vet att det finns två sidor, båda identiska, så det är en 50-50 chans.
Om vi kasta vårt mynt två gånger vet vi att det finns tre möjliga resultat: 2 huvuden, 2 svansar eller 1 huvud och 1 svans. Och så vidare…
Låt oss säga att myntkastet är vårt A / A-test; oddsen för huvudsidan som kommer upp är identiska med oddsen för svanssidan som kommer upp, precis som oddsen för någon av våra gröna knappar är knackade är lika.
Så låt oss skriva ett snabbt skript i webbläsaren (eftersom de flesta A / B-test händer i webbläsaren) för att simulera användare som knackar på en knapp eller den andra, beroende på vilken de presenteras med.
Kom ihåg: vi testar två identiska varianter av en knapp, och det sätt vi vet att de är identiska är att vi behandlar sannolikheten för att de tappas som identiska. Allt vi letar efter är ett konsekvent (och därför rätt) resultat.
För det första behöver vi ett HTML-bord för att spela in våra resultat, tabellen kommer att se ut så här:
# Heads Tails Difference Margin of Error
I den första kolumnen registrerar vi testets nummer (alla bra A / B-test, upprepas för att verifiera resultaten, så vi kommer att repetera testet några gånger). Därefter registrerar vi antalet Heads- resultat, så kommer antalet svansar att visas. Kolumnen efter det kommer att vara skillnaden mellan de två resultaten (som ska vara noll). Då registrerar vi felmarginalen (som återigen borde vara 0%). Under tabellen skriver vi ut en sammanfattning, medeltalet av alla resultat och värsta fallet.
Här är skriptet:
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 är kommenterad, så här är bara höjdpunkterna:
Först ställer vi upp några variabler inklusive antalet gånger vi vill kasta myntet (bestOf) och hur många gånger vi vill repetera testet (testrepetition).
Spoiler alert: vi kommer att komma in i några ganska höga loopar, för att undvika att bryta någons webbläsare kör vi testet med ett intervall på 100 ms.
Inuti funktionen performCoinToss löser vi det önskade antalet gånger, varje iteration av slingan använder vi JavaScripts slumpmässiga funktion för att generera antingen en 1 eller en 0 som i sin tur ökar antingen headsCounter eller tailsCounter .
Därefter skriver vi resultatet från det testet till bordet.
Slutligen, om testet har upprepats, hur många gånger vi vill, hittar vi medelvärdena och i värsta fall skriver du dem till sammanfattningen och rensar intervallet.
Här är resultatet . Som du kan se är den genomsnittliga skillnaden bra, det kommer att vara annorlunda för dig, men när jag skriver detta är den genomsnittliga skillnaden 2,8333333333333335, så är det genomsnittliga felet 23.611111111111114%.
Fel på över 23% inspirerar inte förtroendet, särskilt eftersom vi vet att skillnaden ska vara 0%. Vad som är värre är att mitt värsta fallresultat är 8, det är 10-2 för huvudet.
Okej, så det var inte rättvist. Ett verkligt A / B-test skulle aldrig göra anspråk på att hitta ett avgörande resultat från bara 12 användare.
A / B-test använder något som kallas "statistisk signifikans" vilket innebär att testet måste springa tillräckligt många gånger för att uppnå ett verkningsbart resultat.
Så, låt oss dubbla variabeln bestOf och se hur långt vi behöver gå för att nå en felmarginal på mindre än 1% - vilket motsvarar 99% förtroende.
Vid en bestOf av 24 (vid skrivningstidpunkten) är den genomsnittliga skillnaden 3,16666666666666665, vilket är 13,1944444444444455%. Ett steg i rätt riktning! Prova själv (dina resultat kommer att variera).
Låt oss fördubbla det igen. Den här gången min genomsnittliga skillnad 6,6666666666666667, med en marginal för fel på 13.88888888888889%. Ännu värre är värst fallet 16, det är ett fel på 33.33333333333333%! Du kan prova den där för dig själv också.
Egentligen inga priser för att gissa att vi kan fortsätta: bäst av 96 , bäst av 192 , bäst av 384 , bäst av 768 , bäst av 1536 , bäst av 3072 , bäst av 6144 , bäst av 12288 , bäst av 24576 , bäst av 49152 , bäst av 98304 .
Slutligen, till det bäst av 98304, faller värsta fallet under 1%. Med andra ord kan vi vara 99% övertygade om att testet är korrekt.
Så, i ett A / A-test, vilket resultat vi visste i förväg, tog det en provstorlek på 98.304 för att nå en acceptabel felmarginal.
När A / B-test diskuteras, minns någon om en vän till en vän, som A / B testat en enda knapp på sin webbplats och omedelbart gjorde en viss osannolik vinst (knappens faktiska dollarnivå ökar varje gång jag hör berättelse).
I dessa berättelser testas knapparna vanligtvis för mikrokopia, "Ladda ner min ebook" vs. "Ladda ner min gratis ebook". Det borde inte vara en överraskning att den senare vinner. Det är en förbättring som någon bra copywriter skulle göra. Ett mer lämpligt A / B-test skulle vara "Ladda ner min ebook" vs. "Ladda ner e-boken" (mina pengar på den senare).
Om du befinner dig med ett resultat som är tungt vägt mot ett av alternativen, föreslår det att något är mycket fel med en av dina variationer. Ofta kommer ett bra resultat att bli en förbättring på mindre än 5%, vilket innebär ett problem om du testar med cirka 1000 användare (felmarginalen är cirka 5%).
Ju mer användbar ett test är desto strängare segerns marginal för en variation eller den andra. Ju ju desto snabbare vinstmarginalen desto större är provstorleken som behövs för att ge dig en acceptabel liten felmarginal.
Mark Twain, eventuellt citat Disraeli, använde en gång frasen: lögner, förbannad lögner och statistik. Genom vilket han menade att något visat sig vara statistiskt, är det inte nödvändigtvis sant. Statistik kan användas för att bevisa vad du vill ha dem till.
A / B-test ger dig ett resultat, men det är ett resultat som säger mer om dig och om vad du förväntade dig att hitta än om dina kunder
Det farligaste med A / B-test är att det kan bevisa allt du vill ha det till; Det kan ge falska positiva resultat och det gör det möjligt för oss att urskilja mönster som inte stöds ordentligt.
Vidare kan ett A / B-test indikera att en grön knapp överträffar en röd knapp, men hur är det med en blå knapp? Till och med framgångsrik A / B-testning tillåter oss bara att validera våra designbeslut inom ramen för själva testet.
För att ett A / B-test ska fungera som avsett behöver vi två motsatta förhållanden vara sanna:
Tyvärr har de flesta sajter inte en provstorlek tillräckligt stor för att nå en tillräckligt liten felmarginal. Och eftersom vi inte kan öka vår samplingsstorlek (vi skulle om vi kunde), är vårt enda val att öka variationen av alternativen för att ge ett klart resultat, korsa testet med våra preferenser.
A / B-testning ger dig ett resultat, men det är ett resultat som säger mer om dig och om vad du förväntade dig att hitta än om dina kunder. När det gäller att fatta designbeslut på någon annan webbplats än de med mycket stora volymer av trafik, kan vi lika bra slänga ett mynt, som A / B-test.