“Du behöver ha minst x användare för att kunna A/B-testa i din produkt!”
Jag ser titt som tätt den här typen av påståenden, ofta som en anledning till varför validerande tester inte är relevant för just den här produkten. Finns det en magisk gräns när du kan börja A/B-testa dina hypoteser?
Min högst personliga empiri säger att det antingen kommer från produktpersoner som inte vill anamma datadrivna utvecklingsmetoder, eller från datapersoner som tycker att statistisk metod är det viktigaste momentet i discovery-arbetet. Lite tillspetsat kanske, och båda lägren har sina poänger.
Vid små användarvolymer kan det finnas relevanta skäl att inte använda A/B-tester. Kanske är produkten precis lanserad till en liten grupp inbjudna betaanvändare, eller så är det en b2b-lösning där den totala marknaden uppgår till ett hundratal kunder. Då är nog inte A/B-tester det primära verktyget i discovery-lådan. (Våra vänner på den eminenta podden Datadrivet släppte 21:a mars ett avsnitt på temat validering för produkter mellan pre-launch och growth, så tune:a in på länken om du vill lära dig mer om just det!)
Och jag håller med om att statistisk metod är grundbulten i A/B-testning, och användarvolymer spelar en avgörande roll för experimentdesign. Trots det tycker jag att påståenden om att det finns vissa villkor eller gränsvärden för att ens kunna A/B-testa vittnar om ett ganska bakvänt förhållningssätt till experiment och validering. Så vad är det som gäller?
I den här artikeln förklarar jag varför jag tycker att frågan är felställd, och hur du istället bör tänka kring A/B-testning och validerat lärande för en produkt som ännu har relativt små användarvolymer.
Del 1: Sannolikhet och statistik 7.5 HP på 3 minuter
Varför krånglar vi till det?
Till syvende och sist är ett A/B-test en hypotesprövning som avgörs av ett signifikanstest. Men varför måste vi blanda in sannolikhet? Varför inte bara släppa vår nya pryl och se hur det påverkar användarbeteenden och våra metrics? (Säg det i kör:) Eftersom att det kan vara massor av andra saker som påverkar användarbeteenden. Det är helt enkelt väldigt svårt att säga om ett hack i kurvan beror på vår nya fräcka pryl eller om det var något helt annat som påverkade just den perioden.
Men om vi kan släppa den nya prylen parallellt med originalet och jämföra resultaten mellan grupperna, då ser vi ju vilken som går bäst? Det är på rätt väg, men vi kan fortfarande inte utesluta att slumpen spelar in. Kanske hamnade alla våra storkunder i den ena gruppen, eller så råkade några fler i den andra gruppen ta semester och därmed ha mycket mer tid att spendera i vår produkt. Faktum är att om vi skulle dela upp en användarbas i två randomiserade grupper och ge dem exakt samma upplevelse (ett s.k. A/A-test) så kommer våra metrics skilja sig åt när vi jämför grupperna. Användarbeteenden kommer variera slumpvis över tid, både på individnivå och på en aggregerad nivå, så vi kan aldrig ta bort slumpen helt, men med hjälp av en statistisk modell kan vi beräkna sannolikheten att vårt resultat inte beror på slump.
Signifikans och Power
Så vi har en hypotes som säger att B är bättre än A enligt en viss metric, och det är dags att konstruera ett experiment. Kortfattat så gör vi följande:
- Vi väljer en statistisk modell som beskriver det vi vill mäta, ex. ett binomialtest för en klickkonvertering, något som ofta sker “under huven” i en experimentplattform.
- Vi skapar två grupper via slumpmässigt urval från vår användarbas, ofta med hjälp av någon form assignment engine i experimentplattformen.
- Vi ger respektive grupp treatment A och treatment B via någon form av feature flagging eller motsvarande.
- Vi beräknar sannolikheten att den eventuella skillnaden mellan grupperna inte beror på slump, dvs. är statistiskt signifikant.
Om resultatet från experimentet är signifikant så ska vi på statistikspråk förkasta den s.k. nollhypotesen, och anta vår hypotes som sann, dvs B är bättre än A. Men detta gäller endast utifrån villkoren i vår statistiska modell, och som tidigare nämnt måste modellen ha utrymme för kontrollerad felmarginal och slump, så helt säkra kan vi inte vara.
Typ 1-fel och Typ-2 fel
Även ett felfritt utfört experiment har två möjliga fallgropar, vilka brukar kallas typ 1-fel och typ 2-fel:
- Typ 1 fel (False positives): Nollhypotesen är sann, dvs det finns ingen verklig skillnad mellan A och B, MEN våra resultat visar en signifikant skillnad mellan grupperna (p.g.a slumpmässig variation), och att vi därmed ska förkasta nollhypotesen.
- Typ 2 fel (False negatives): Nollhypotesen är inte sann, dvs det finns en verklig skillnad mellan grupperna, men våra resultat är inte tillräckligt tydliga för att vi ska kunna förkasta nollhypotesen.
Dessa fel innebär alltså inte att något har gått snett. Det måste finnas utrymme för viss kontrollerad osäkerhet för att experiment på slumpvisa urvalsgrupper ska gå ihop.
Lite förenklat så justerar vi för typ 1-fel genom att höja eller sänka signifikansnivån i vår statistiska modell. Klassikern är 95%, dvs. att vi anser att våra resultat är signifikanta om det enligt vår modell är < 5 % sannolikhet att våra resultat beror på slumpvis variation. Lite tillspetsat så är det alltså standarden att ca 1 av 20 experiment felaktigt förkastar nollhypotesen, och därmed gör ett typ 1-fel och drar fel slutsats. Om det känns för riskabelt så kan vi exempelvis höja signifikansnivån till 99% och på så sätt minska risken för typ 1-fel från 5% till 1%, men i samma veva ökar då risken för typ 2-fel, om vi inte samtidigt ökar testets power. Power är experimentets förmåga att faktiskt upptäcka verkliga skillnader i den slumpmässiga variationen, mao att undvika typ 2-fel, och att maximera power för experimentet är huvudmomentet i experimentdesign.
Del 2: Experimentdesign i praktiken
Verktygslådan
När vi designar vårt experiment behöver vi gå en balansgång mellan typ 1- och typ 2-fel, eller signifikansnivå och power. För att inte dribbla bort alla som inte råkar ha en masterexamen i statistik är min erfarenhet att signifikansnivån bör hållas konstant oavsett test, ofta på just 95%. (Och visst, det är suboptimering att inte vara flexibel även med signifikansnivå, men den kommunikativa utmaningen i att förklara olika signifikansnivåer och hur de bör väga in i beslutet överväger oftast fördelarna.)
Så vilka parametrar har vi att skruva på?
1. Sample size:
Antalet deltagare/försök som ingår i experimentet. Det tyngsta verktyget i verktygslådan (och anledningen till titeln på den här artikeln), större sample = mer power. För att optimera sample size är det vanligaste tillvägagångssättet att låta experimentet köra över en längre tidsperiod, då aktiva användare ökar över tid, vanligtvis. Att öka tiden är dock kostsamt, både som en alternativkostnad i att sänka lärandehastigheten, men kan även vara associerat med direkta kostnader, ex. om experimentet innefattar rabatter eller liknande, och större samples tenderar att generera fler frågor till kundsupport.
Ju längre testet är ute i det vilda, desto större chans andra releaser sker som potentiellt samspelar med det du undersöker och ställer analysen på ända. Ni fattar. Andra alternativ är att låta testet ske där flest användare befinner sig (ex. en startvy), eller att inkludera fler marknader/plattformar/operativsystem, men även detta innebär ofta mer utvecklingstid och kostnad. Det är heller inte alltid som hypotesen går att abstrahera över olika kontexter, eller att användarupplevelsen inte påverkas negativt av att “konstgjort” öka sample size på det här sättet, så en bör absolut inte maximera sample size bara för att en kan. Moderna experimentplattformar erbjuder ofta sample size calculators som en del av plattformen som kan hjälpa en i power-analysen.
2. Minimal Detectable Effect/MDE:
Storleken på den förväntade effekten av vår treatment, ofta förkortat MDE. Tror vi att vår nya variant kommer öka konverteringsgraden med 5% eller 20%? En copyförändring eller en ommöblering av element i UI:t är klassiska uppslag för A/B-test, men är i min erfarenhet sällan något som ger några enorma förändringar i användarbeteende och metrics. Små MDE’s kan vara helt rimliga om du är Amazon.com där du har tillräcklig power tack vare enorma samples, och där en MDE på 1% i köpkonvertering innebär snormycket pengar, medan det i andra icke-hyperoptimerade fall ofta finns intressantare saker att testa. Att angripa användares faktiska problem med mer betydande förändringar har inte bara högre potential att förbättra användarupplevelsen, utan även större chans att ge en stor MDE, och därmed mätbara effekter (varför också user research och kvalitativ data är oumbärligt för framgångsrik A/B-testning även ur ett rent statistiskt perspektiv).
Jag försöker ofta skruva upp förändringen så mycket det går, särskilt första gången jag testar en ny hypotes, just för att maximera MDE: vill du se om mängdrabatt har potential att driva merförsäljning för din produkt, prova då att erbjuda 30% rabatt för ett mindre sample, även om du vet att 15% vore mer realistiskt givet dina nuvarande marginaler. Frikoppla hypotesen från feature:n (om du har råd), och använd radikal design för att maximera power och hastigheten i det validerade lärandet.
3. Storlek på vår test metric:
Större storlek på test metric (exempelvis en konverteringsgrad) gör det lättare att upptäcka relativa skillnader mellan våra varianter, vilket hänger ihop med vår MDE. Om vi har förväntad MDE på 10% för två olika test metrics, så är såklart 10% av 50% större än 10% av 20%. Ju större den absoluta förändringen är desto större sannolikhet är det att vår experimentdesign har tillräcklig power för att upptäcka den.
Ett ständigt dilemma är valet mellan att använda downstream metrics såsom köpkonvertering som test metric, vilka ofta är bra mycket lägre jämfört med upstream metrics som att ex. att lägga i varukorg osv. Det är ofta transaktionen som är målet, men kommer vi ha tillräcklig power om den är på någon enstaka procent? Vanligaste knepen för att öka power genom storleken på vår test metric är att gå upstream i funneln, vilket alltid betyder högre konverteringsgrader, och ibland också automatiskt större sample size beroende på var vi placerat vår treatment, eller att titta på olika typer av proxy metrics.
Det här är långt ifrån alla knep att ta till när det kommer till praktiskt experimentdesign och optimeringen av statistical power, och samtliga parametrar skulle förtjäna en uttömmande text i sig. Varken genomförbarheten eller power av A/B-test avgörs enbart av sample size, och även produkter med stora användarvolymer bör göra hemläxan för att hålla sina experiment så billiga och snabba som möjligt.
Ett illustrereande exempel
Om vi jämför två olika bolag:
- Bolag 1:
E-Handel som säljer affischer
Trafik: 200 000 användare per vecka
Konverteringsgrad för köp: 1,5% - Bolag 2:
E-handel som säljer handmålade canvastavlor med marsvinsmotiv.
Trafik: 1000 användare per vecka
Konverteringsgrad för köp: 1,5%
Internsöket är den vanligaste vägen att hitta affischer/tavlor, och båda bolagen vill addera en ny sökalgoritm som tar hänsyn till vad som sålt bäst den senaste veckan. Baserat på användarresearch och existerande data tror de att effekten på konverteringen skulle vara ca. 10%, alltså från ca 1.5% till 1.65%. Vi gör vår poweranalys och får följande:
Vi ser att Bolag 1 utan problem kommer kunna testa sin hypotes med den föreslagna experimentdesignen. P-värdet givet antaganden är på 0.0019, alltså långt under gränsvärdet på 0.05. Det vore med andra ord extremt osannolikt att vårt experiment skulle ha för låg power för att utse en vinnare. För Bolag 2 ser det kärvare ut: ett p-värde på 0.4 innebär att det är 40% sannolikhet att det bara är slumpvis variation som genererat den potentiella skillnaden mellan varianterna. Med en såpass stor osäkerhet kan vi nästan lika gärna singla slant om saken. Så bolag 2 kan glömma A/B-tester då?
Nej! Vi går igenom våra 3 parametrar och funderar hur vi kan skruva på experimentdesignen.
Sample size: Om vi istället kör testet i 4 veckor så kan vi fyrdubbla vår sample size (åtminstone i detta idealiserade exempel)
Storlek på test metric: Vi kollar i vår funneldata och ser att i snitt så är det 10% konvertering på att lägga en marsvinstavla i kundvagnen. Alltså bra mycket större än köpkonvertering på 1.5 %
MDE: Av tidigare erfarenhet så vet vi att brukar se större effekter upstream i funneln där det inte är lika mycket commitment från kunden, och vi tror att vi kan förvänta oss MDE på 20 % för “add to cart”.
Vi beräknar ett nytt p-värde givet våra nya experimentdesign:
Här har vi alltså två identiska hypoteser i snarlika kontexter, men användarvolymerna är vitt skilda. Bolag 1 är 200x gånger större än bolag 2, mätt i veckoaktiva användare. Ändå så skulle båda experimenten ovan ha tillräcklig power, givet våra antaganden.
Om vår hypotes är att sökresultaten är mer relevanta med vår nya algoritm, så skulle min personliga bedömning vara att scenario 2 duger gott och väl för att validera att den nya algoritmen gör sitt jobb: fler användare verkar hitta relevanta produkter som de är intresserade av! Det är inte en lika avgörande insikt som en signifikant ökning i köp och intäkter hade varit, men det är oändligt mycket bättre än att inte validera den nya sökalgoritmen alls, vilket ofta är alternativet.
Fråga inte vad A/B-tester kan göra för dig…
Frågan som ligger till grund för den här texten är nästan alltid formulerad som “Hur många användare behöver jag för att A/B-testa?” när den relevanta frågan är “Hur kan jag A/B-testa med de användare jag har?”, och som jag hoppas att jag lyckats kommunicera i den här texten så kan smart experimentdesign validera både små optimeringsidéer såväl som större bets även vid lägre användarvolymer.
Det är just detta som i min mening utgör kärnkompetensen i ett skillat growth- och experimenteringsteam. Även om jag anser att snabbfotad A/B-testning är något av en guldstandard för validerat lärande så är det inte en universallösning för allt. Jag är ett stort fan av s.k. smokescreen / painted door-tester för att testflyga nya idéer, eller gamla hederliga surveys för den delen. Ett första steg som sällan slår fel är att börja fråga kollegor, förbipasserande eller i bästa fall verkliga användare vad de tycker. Det är inte validering som håller för kliniska studier, men redan här kan du börja ana om det du trodde faktiskt verkar sannolikt eller ej.
De som är smartast i sin experimentdesign utifrån de praktiska förutsättningarna för produkten är också de som snabbast genererar mest validerat lärande.
Så, finns det ett nedre gränsvärde för sample size? Som du kanske listat ut vid det här laget är mitt svar nej. I praktiken förhåller jag mig dock till denna tumregel: Skulle du och ditt team teoretiskt kunna plocka upp telefonen och ringa samtliga användare av produkten inom en vecka/sprint och fråga dem vad de tycker? Om svaret är ja så är nog det att föredra. Annars tycker jag att du ska köra på!
Jag hoppas att den här texten har inspirerat dig att komma igång att testa nya byggen och validera dina hypoteser, även om din produkt i dagsläget inte har tusentals användare. Vi kan aldrig vara helt säkra i vår validering, trots A/B-tester (typ 1-fel is a thing!) och alla valideringsmetoder rör sig på en glidande skala av kontrollerad osäkerhet.
Har du inspel, frågor eller bara vill prata mer A/B-testning, adda mig på Linkedin eller släng iväg ett mail!