A / B-testing blir ofte fakturert som en vitenskapelig måte å validere designbeslutninger på. Av og til referert til som deltesting, er A / B-testing en enkel prosess som på overflaten ser ut til å løfte konkrete resultater:
Lag to variasjoner på et designelement, bytt dem tilfeldig på nettstedet ditt og registrer hvordan brukerne reagerer, sammenlign resultatene, implementer hvilken variasjon som har vært best. Det er fornuftig.
Det klassiske eksempelet er: en rød knapp vs. en grønn knapp, som vil bli tappet mer? Men det mer interessante spørsmålet er: en grønn knapp vs. den samme grønne knappen, som vil bli tappet mer?
Hva skjer når vi A / B tester to identiske variasjoner? En A / A-test, hvis du vil.
For å teste gyldigheten av enhver A / B-test, trenger vi en test som har et "riktig" svar. Vi trenger et riktig svar fordi vi vil vite, uansett, hvor sannsynlig er det at A / B-testen vil gi resultatet det skal, og for det må vi vite hvilket resultat som skal forventes.
Hvis vi A / B tester to identiske knapper, bør resultatet være en død varme
Så, la oss anta at vi tester en grønn knapp vs. den samme grønne knappen, og at knappen er så fristende at 100% av brukerne vil trykke på den.
(Prosentandelen egentlig ikke betyr noe, det kan være 14.872%. Det som er viktig er at fordi knappene er identiske, bør trykkfrekvensen også være identisk.)
Hvis vi A / B tester to identiske knapper, bør resultatet være en død varme.
Kast en mynt. Hvilken side kommer opp, hoder eller haler? Vi vet at det er to sider, begge identiske, så det er en 50-50 sjanse.
Hvis vi kaster vår mynt to ganger, vet vi at det er tre mulige utfall: 2 hoder, 2 haler eller 1 hode og 1 haler. Og så videre…
La oss si at myntkastet er vår A / A-test; oddsen til hodesiden kommer opp er identisk med oddsene til haler siden kommer opp, akkurat som oddsene til en av våre grønne knapper blir tappet er like.
Så la oss skrive et raskt skript i nettleseren (fordi de fleste A / B-testing skjer i nettleseren) for å simulere brukere å trykke på en knapp eller den andre, avhengig av hvilken en de presenteres med.
Husk: vi tester to identiske variasjoner på en knapp, og måten vi vet at de er identiske, er at vi behandler sannsynligheten for at de blir tappet som identiske. Alt vi leter etter er et konsistent (og derfor riktig) resultat.
For det første trenger vi et HTML-tabell for å registrere våre resultater i, tabellen vil se slik ut:
# Heads Tails Difference Margin of Error
I den første kolonnen registrerer vi nummeret på testen (alle gode A / B-tester, gjentas for å bekrefte resultatene, så vi gjentar testen noen ganger). Deretter tar vi opp antall hoderresultater , og antallet haler oppstår. Kolonnen etter det vil være forskjellen mellom de to resultatene (som skal være null). Da tar vi opp feilmarginen (som igjen burde være 0%). Under bordet skriver vi ut en oppsummering, gjennomsnittet av alle resultatene og det aller beste resultatet.
Her er 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 er kommentert, så her er bare høydepunktene:
For det første oppretter vi noen variabler, inkludert antall ganger vi ønsker å kaste mynten (bestOf) og antall ganger vi vil gjenta testen (testrepetisjon).
Spoiler varsel: Vi kommer til å komme inn i noen ganske høye sløyfer, for å unngå å bryte noen nettleser kjører vi testen med et intervall hver 100ms.
Innenfor performCoinToss- funksjonen slår vi det nødvendige antall ganger, hver iterasjon av sløyfen bruker vi JavaScript's tilfeldige funksjon for å generere enten en 1 eller en 0, som igjen øker enten headsCounter eller tailsCounter .
Deretter skriver vi resultatet fra testen til bordet.
Til slutt, hvis testen har blitt gjentatt, antall ganger vi ønsker, finner vi gjennomsnittet, og verste fall, skriv dem til sammendraget, og fjern intervallet.
Her er resultatet . Som du kan se den gjennomsnittlige forskjellen er, vel, det vil være annerledes for deg, men som jeg skriver dette er gjennomsnittlig forskjell 2,8333333333333335, den gjennomsnittlige feilen er derfor 23,611111111111114%.
Over 23% feil inspirerer ikke tillit, særlig fordi vi vet at forskjellen skal være 0%. Hva er verre er at mitt verste fall er 8, det er 10-2 i favør av hoder.
Ok, så testen var ikke rettferdig. En ekte A / B-test ville aldri hevde å finne et avgjørende resultat fra bare 12 brukere.
A / B-testing bruker noe som kalles "statistisk signifikans", noe som betyr at testen må løpe nok ganger for å oppnå et handlingsbart resultat.
Så la oss doble bestOf- variabelen og se hvor langt vi må gå for å oppnå en feilmargin på mindre enn 1% - tilsvarende 99% tillit.
Ved en bestof på 24 (ved skrivingstid) er gjennomsnittlig forskjell 3.1666666666666665, som er 13,194444444444445%. Et skritt i riktig retning! Prøv det selv (resultatene dine vil variere).
La oss doble det igjen. Denne gangen min gjennomsnittlige forskjell 6,6666666666666667, med en margin for feil på 13.88888888888889%. Verre er det verste fallet 16, det er en feil på 33.33333333333333%! Du kan prøv den ene for deg selv også.
Egentlig ingen priser for å gjette at vi kan fortsette å gå: best av 96 , best av 192 , best av 384 , best av 768 , best av 1536 , best av 3072 , best av 6144 , best av 12288 , best av 24576 , best av 49152 , best av 98304 .
Til slutt, til det beste av 98304, faller det verste fallet under 1%. Med andre ord kan vi være 99% sikre på at testen er korrekt.
Så, i en A / A-test, som resultatene vi visste på forhånd, tok det en prøvestørrelse på 98.304 for å nå en akseptabel feilmargin.
Når A / B-testing er diskutert, husker noen en venn av en venn, som A / B testet en enkelt knapp på hans / hennes nettsted, og gjorde øyeblikkelig noe usannsynlig fortjeneste (den faktiske dollarverdien av knappen øker hver gang jeg hører historie).
I disse historiene blir knappene vanligvis testet for mikrokopi, "Last ned min ebook" vs. "Last ned min gratis ebook". Det bør ikke være en overraskelse at sistnevnte vinner. Det er en forbedring som en god tekstforfatter ville gjøre. En mer hensiktsmessig A / B-test ville være "Last ned min ebook" vs. "Last ned eBok" (pengene mine er på sistnevnte).
Hvis du finner deg selv med et resultat som er tungt vektet mot ett av alternativene, foreslår det at noe er veldig galt med en av dine variasjoner. Oftere vil et godt resultat være en forbedring på mindre enn 5%, noe som gir et problem hvis du tester med rundt 1000 brukere (feilmarginen er ca. 5%).
Jo mer nyttig en test er, desto strengere er seieren for en variant eller den andre. Imidlertid desto strammere marginalen til seier, desto større var prøvestørrelsen som trengs for å gi deg en akseptabel liten feilmargin.
Mark Twain, eventuelt citerer Disraeli, brukte en gang uttrykket: løgner, forbannede løgner og statistikk. Som han mente at noe viste seg med statistikk, er det ikke nødvendigvis sant. Statistikk kan brukes til å bevise alt du vil ha dem til.
A / B-testing gir deg et resultat, men det er et resultat som vil si mer om deg og hva du forventet å finne enn om kundene dine
Den farligste tingen om A / B-testing er at den kan bevise alt du vil ha det til; det kan produsere falske positiver, og det gjør det mulig for oss å skille mellom mønstre som ikke støttes riktig.
Videre kan en A / B-test indikere at en grønn knapp overgår en rød knapp, men hva med en blå knapp? Selv vellykket A / B-testing bare tillater oss å validere våre designbeslutninger innenfor selve testens sammenheng.
For at en A / B-test skal fungere som ønsket, trenger vi to motsatte forhold som er sanne:
Dessverre har de fleste nettsteder ikke en prøveformat som er stor nok til å oppnå en tilstrekkelig liten feilmargin. Og fordi vi ikke kan øke vår utvalgsstørrelse (vi ville hvis vi kunne), er vårt eneste valg å øke variasjonen av alternativene for å gi et klart resultat, å skille testen av våre preferanser.
A / B-testing gir deg et resultat, men det er et resultat som vil si mer om deg og hva du forventet å finne enn om kundene dine. Når det kommer til å ta designbeslutninger på et annet nettsted enn de med svært høye trafikkvolum, kan vi like godt kaste en mynt, som A / B-test.