Stäng

Experimentell design, del 3

Detta är del 3 i min serie om experimentell design. Har du inte läst mina tidigare inlägg om Permutationstestet och A/B-testet rekommenderar jag att du börjar där, då detta kommer att bygga vidare på samma kodbas och ta vid i frågeställningen där vi senast lämnade den.

Vår nästa fråga att besvara är: när vet vi att vårt A/B-test är klart? Och det korta svaret är: har vi inte uppnått signifikansnivån (95%) är testet inte klart. Undantaget vore om testet pågått under en alltför lång tid, exempelvis +4 veckor, utan att närma sig signifikans. Skulle det bli alltför blockerande för andra tester som skulle kunna genomföras istället, kan det vara värt att överväga att avsluta det (utan resultat).

Graf, 2 veckor

På bilden ovan följer vi ett A/B-test under 2 veckors tid och som vi kan se är det en hel del fluxationer i signifikansen (blå linjen). Vid två tillfällen har den också korsat signifikansnivån (röda linjen), med andra ord har vi uppnått statistisk signifikans för att sedan förlora den igen. Skulle vi välja att avsluta vårt test vid första tillfället vi uppnådde signifikans skulle vi ha fel ca. 60% av gångerna i våra antaganden, vilket faktiskt är sämre än att inte göra något test överhuvudtaget. En kvalificerad gissning, eller till och med att fråga en schimpans skulle ge oss bättre tillförlitlighet än detta (50%, utan preferenser eller fördomar). Så frågan kvarstår, hur vet vi när testet är klart?

När vårt data korsar signifikansnivån kommer vi att applicera en sekundär diagnostik, en så kallad provstorlekskalkylator. Har vi signifikans i datat, samt att vår provstorlekskalkylator ger oss grönt ljus—DÅ är vi klara. Så vad är då en provstorlekskalkylator?

Hur många skruvar hade du behövt kontrollera för att säkerställa att det var fel på 50% av dem? Antagligen färre än om du skulle säkerställa att det var fel på 0.2% av dem, eller hur? Desto mindre skillnad som vi försöker upptäcka, desto mer data kommer vi med andra ord att behöva. Denna skillnad brukar kallas för Minimal Detectable Effect (MDE) och är alltså den minsta relativa, förbättringen eller försämringen, i konverteringen vi är intresserade av att upptäcka. Låt säga att vi idag har en konverteringsgrad på 20% och nu sätter vår MDE till 10%. De 10% av vår konverteringsgrad på 20% ger en absolut MDE på 2%, det betyder att vi vill upptäcka alla förändringar som ligger utanför intervallet 18-22%.

I mitt kodexempel är vår relativa MDE initialt satt till vår teststatistik, som om vi använder oss av mock-datat från tidigare vi vet är 66.67% (observera dock att vi inte uppnådde signifikans i detta data). Men, jag har också gjort det möjligt att skriva in en egen MDE som överrider detta. Varför? Vi återgår till skruvarna igen: om det vore så att någon skulle kontrollera om det var fel på endast ett liten procentandel skruvar, låt säga 2%, skulle det medföra en längre arbetstid, vilket i sin tur skulle leda till en större arbetskostnad. I vissa fall kan det alltså vara negativt för affärsvärdet att ha en alltför låg MDE. Skulle ett utvecklingsteam få i uppdrag att utveckla ett nytt betalflöde på en webbplats skulle detta antagligen innebära flera veckors utvecklingsarbete. För att motivera arbetskostnaden behöver vi en ROI, vi för exemplet kan säga är +5%. Alltså, det nya betalflödet måste sälja minst 5% bättre än det gamla för att utvecklingen på slutraden ska vara lönsam. Att då sätta en lägre MDE än 5% skulle inte vara nödvändigt för den bakomliggande orsaken, utan bara förlänga testet i onödan. Anledningen att jag lagt till ett input-fält är alltså för att kunna skriva in en egen MDE, då den har en relation till vårt specifika business case. Din MDE bör vara den minsta effekt som skulle motivera implementering av ändringen som testas.

Det andra vi behöver är vår konverteringsgrad för vad vi nu mäter. I koden nedan är denna satt till 40%, vilket är medelvärdet av konverteringen för båda variationerna (A + B). Även denna går att överrida, för kanske kan du tillgång till insikter och analysdata vilket kan ge dig en mer tillförlitlig konverteringsgrad att använda? Har vi haft en köpknapp på vår hemsida och kan se att knappen det senaste året har en konverteringsgrad på 3%, skulle detta antagligen vara bättre att utgå ifrån. Dock har vi inte alltid sådant populationsdata, utan måste ibland förlita oss på vad våra stickprov kan säga oss.

Vi har nu vad vi behöver för att beräkna vår provstorlek, vår MDE och vår konverteringsgrad. Innan vi gör detta ska jag även nämna att jag har lagt in en nedre tröskel som behöver uppfyllas. Den baseras på praxis och kräver att vi har minst 100 konverteringar per variation, samt att testet har pågått i minst två veckor. Detta brukar kallas för en fixerad horisont.

Källkoden finns att se här på min GitHub-profil: https://github.com/marcuskullman/code-examples