av Rostyslav Mykhajliw Grundare av TrueSocialMetrics.com ~ 4 min
Det klassiska A/B-testet är en fördelning mellan olika stater. Låt oss utgå från ett allmänt exempel som alla använder. Vi har en sida med en registreringsknapp, för närvarande är den blå, men vi vill testa en ny färg röd.
Sedan fördelar vi lite trafik dit och väntar på lite. Det finns en enkel miniräknare för statistical significance.
Alternativ A: 50 000 besök - 500 registreringar Alternativ B: 50 000 besökare - 570 registreringar - vinnare
B är en vinnare det är klart. Fler anmälningar, statistisk signifikans.
Vänta lite! Vad vi släpper något nytt. Till exempel lägger vi till en knapp "demo" för översikt över en steg-för-steg-guide genom produkten.
Om vi följer en enkel logik av A/B-tester - det fungerar inte! För vi kan inte jämföra äpplen med apelsiner. Vi kan inte jämföra ingenting med något! Det är helt felaktigt. Om det inte finns någon demoknapp, så kan användare få en sämre upplevelse än de som har det här alternativet. Men det här alternativet kan bara hjälpa användare som redan är intresserade av produkten eller som redan sagt att de nyligen ska använda produkten. Även om du har miljontals trafik kan du inte säga hur det fungerar på några timmar/dagar eftersom resultaten kan skjutas upp i tid.
För en ny funktionalitet bör släppas linjär som enteral releaseprocess. Först då efter ett tag kan vi titta på det och ta reda på om det hade någon inverkan på kundupplevelsen eller inte, men spåra affärsmått. A/B-tester är INTE tillämpliga för en ny funktionalitet.
Gå tillbaka till det första provet med registreringsknappen. Om vår gissning är korrekt kan vi lägga till fler A-alternativ och fler B-alternativ och ingenting ändras, eftersom B fortfarande kan vinna striden.
Titta sedan på resultaten:
A1: 50 000 besökare - 500 anmälningar A2: 50 000 besökare - 580 registreringar - vinnare B1: 50 000 besökare - 570 anmälningar - vinnare B2: 50 000 besökare - 500 registreringar
VAD! VAD! VAD! Du kan säga att det är omöjligt men den här situationen visar skillnad om tilldelningen av besökare träder i kraft på testresultaten. Och dessa resultat visar stabil 95 % statistisk signifikans men lågt konfidens.
Om vi går tillbaka till början av artikeln kommer vi att märka en enorm trafik på 50 000 besökare och 500 övergångar som krävs för att få ett meningsfullt resultat. Men inte alla sidor har dessa möjligheter. Alla startups är inte tillräckligt bra för att generera sådan trafik, eller så kan det vara sidor med låg trafik som inställningar/fakturor etc. I alla dessa fall kommer klassiska a/b-tester att ta enormt lång tid att samla in data månader/halvår eller så. Nästa nackdel med det allmänna tillvägagångssättet är att minst 50 000 besökare (från 100 000 tilldelade för att testa) fick sämre kundupplevelse. Så vi väntar länge och tappar kunder på grund av allokering till ett "förlorande" test. Är det någon mening? Inom vården korsade läkare fallfrågorna, men i en tabell var människors liv. Om vi gör ett test under häxan dör 50% tålamod på grund av "inte-testat-ännu-vård". Och det är jävla galet. Här är en kille Marvin Zelen som kom på idén om adaptiv testning, nu kallad Zelen’s design.
Låt oss föreställa oss att vi har två möjligheter: röda och blå bollar, så statistiskt är det 50% sannolikhet.
Till exempel fördelar vi besökare slumpmässigt till "blå" och "blå" är en bättre upplevelse eftersom vi fick ett köp. I det här fallet vinner "blå", det är därför vi lägger till en extra "blå" boll i poolen.
Som ett resultat ändrades sannolikheten "röd" - 33% och "blå" - 67%
Låter bra! Men nästa besökare med "blått" gör ingenting. Så "blå" tappar, det är därför vi måste ta bort en "blå" boll från poolen och vi fick vårt tidigare tillstånd.
Plus: + fungerar för små mängder trafik + ger användarna bättre vård på ett adaptivt sätt Minus: - kräver att utvecklare arbetar för att ta reda på vinnande/förlorade tester under testprocessen