Historien bakom vår statistikmotor

Klassiska statistiska tekniker, som t-testet, är grunden för optimeringsbranschen och hjälper företag att fatta datadrivna beslut. I takt med att online-experiment har exploderat är det nu tydligt att dessa traditionella statistiska metoder inte är rätt lösning för digital data: Att tillämpa klassisk statistik på A/B-testning kan leda till felfrekvenser som är mycket högre än vad de flesta experimentörer förväntar sig.

Både branschen och akademiska experter har vänt sig till utbildning som lösningen. Titta inte! Använd en urvalsstorlekskalkylator! Undvik att testa för många mål och variationer samtidigt!

Men vi har dragit slutsatsen att det är dags att statistik, inte kunder, förändras. Säg adjö till det klassiska t-testet. Det är dags för statistik som är enkel att använda och fungerar med hur företag faktiskt fungerar.

I samarbete med ett team av statistiker från Stanford utvecklade vi Stats Engine, ett nytt statistiskt ramverk för A/B-testning. Vi är glada att kunna meddela att det från och med den 21 januari 2015 driver resultat för alla Optimizely-kunder.

Det här blogginlägget är långt, eftersom vi vill vara helt transparenta om varför vi gör dessa ändringar, vad ändringarna faktiskt är och vad det betyder för A/B-testning i stort. Håll utkik efter oss till slutet, du kommer att lära dig:

• Varför vi skapade Stats Engine:Internet gör det enkelt att utvärdera experimentresultat när som helst och köra tester med många mål och variationer. I kombination med klassisk statistik kan dessa intuitiva åtgärder öka risken för att felaktigt deklarera en vinnande eller förlorande variant med över 5 gånger.

• Hur det fungerar: Vi kombinerar sekventiell testning och kontroller av falsk upptäcktsfrekvens för att leverera resultat som är giltiga oavsett urvalsstorlek och matchar den felfrekvens vi rapporterar med de fel som företag bryr sig om.
• Varför det är bättre: Stats Engine kan minska risken för att felaktigt deklarera en vinnande eller förlorande variant från 30 % till 5 % utan att offra hastighet.

Varför vi skapade en ny Stats Engine

Traditionell statistik är ointuitiv, lätt att missbruka och ger pengar på bordet.

För att få giltiga resultat från A/B-tester som körs med klassisk statistik följer noggranna experimentatorer en strikt uppsättning riktlinjer: Sätt en minsta detekterbar effekt och urvalsstorlek i förväg, titta inte på resultaten, testa inte för många mål och variationer samtidigt.

Dessa riktlinjer kan vara besvärliga, och om du inte följer dem noggrant kan du omedvetet introducera fel i dina tester. Det här är problemen med dessa riktlinjer som vi försökte åtgärda med Stats Engine:

• Att bestämma sig för en detekterbar effekt och urvalsstorlek i förväg är ineffektivt och inte intuitivt.
• Att titta på resultat innan man når den urvalsstorleken kan introducera fel i resultaten, och du kan vidta åtgärder mot falska vinnare.
• Att testa för många mål och variationer samtidigt ökar fel på grund av falska upptäckter avsevärt – en felfrekvens som kan vara mycket större än den falska positiva frekvensen.

Att bestämma sig för en urvalsstorlek och detekterbar effekt kan sakta ner dig.

Att ställa in en urvalsstorlek innan man kör ett test hjälper till att undvika att göra misstag med traditionella statistiska metoder. För att ställa in en urvalsstorlek måste du också gissa om den minsta detekterbara effekten (MDE), eller förväntad konverteringsfrekvens, som du vill se från ditt test. Om du gissar fel kan det få stora konsekvenser för din testhastighet.

Ange en liten effekt, så måste du vänta på ett stort urval för att veta om dina resultat är signifikanta. Ange en större effekt, så riskerar du att missa mindre förbättringar. Detta är inte bara ineffektivt, det är inte heller realistiskt. De flesta kör tester eftersom de inte vet vad som kan hända, och att i förväg förbinda sig till en hypotetisk ökning är helt enkelt inte särskilt vettigt.

Att kika på dina resultat ökar dina felfrekvenser.

När data flödar in i ditt experiment i realtid är det frestande att ständigt kontrollera dina resultat. Du vill implementera en vinnare så snart som möjligt för att förbättra din verksamhet, eller stoppa ett ofullständigt eller förlorande test så tidigt som möjligt så att du kan gå vidare till att testa fler hypoteser.

Statistiker kallar detta konstanta kikarresultat för "kontinuerlig övervakning", och det ökar chansen att du hittar ett vinnande resultat när inget faktiskt existerar (naturligtvis är kontinuerlig övervakning bara problematiskt när du faktiskt stoppar testet tidigt, men du förstår poängen.) Att hitta en obetydlig vinnare kallas ett falskt positivt fel, eller typ I-fel.

Alla tester för statistisk signifikans som du kör kommer att ha en viss risk för fel. Att köra ett test med 95 % statistisk signifikans (med andra ord, ett t-test med ett alfavärde på 0,05) innebär att du accepterar en 5 % chans att, om detta vore ett A/A-test utan någon faktisk skillnad mellan variationerna, skulle testet visa ett signifikant resultat.

För att illustrera hur farlig kontinuerlig övervakning kan vara simulerade vi miljontals A/A-tester med 5 000 besökare och utvärderade risken för att göra ett fel under olika typer av kontinuerliga övervakningspolicyer. Vi fann att även konservativa policyer kan öka felfrekvensen från ett mål på 5 % till över 25 %.

I vår undersökning deklarerade mer än 57 % av de simulerade A/A-testerna felaktigt en vinnare eller förlorare minst en gång under sin tid, även om det bara var kort. Med andra ord, om du hade tittat på dessa tester kanske du undrat varför dina A/A-testresultat deklarerade en vinnare. Ökningen i felfrekvensen är fortfarande betydande även om du inte tittar på varje besökare. Om du tittar på var 500:e besökare ökar risken för att göra en falsk deklaration till 26 %, medan en sökning på var 1000:e besökare ökar samma risk till 20 %.

Detta diagram över den statistiska signifikansnivån för ett A/A-test över tid visar var försöksledaren skulle ha sett ett signifikant resultat om hon kontinuerligt övervakat testet.

Även om du är medveten om detta problem leder rimliga "korrigeringar" fortfarande till höga felfrekvenser. Anta till exempel att du inte litar på ett signifikant resultat för ditt A/B-test. Liksom många Optimizely-användare kan du använda en kalkylator för urvalsstorlek medan ditt test redan körs för att avgöra om ditt test har körts tillräckligt länge. Att använda kalkylatorn för att justera din urvalsstorlek medan testet körs är vad som kallas en "post-hoc-beräkning", och även om det minskar en viss risk för kontinuerlig övervakning leder det fortfarande till felfrekvenser som ligger runt 25 %.

Fram till nu har det enda sättet att skydda sig mot dessa fel varit att använda kalkylatorn för urvalsstorlek innan du börjar ditt test och sedan vänta tills ditt test når din urvalsstorlek innan du fattar beslut baserat på dina resultat.

Den goda nyheten är att det faktiskt finns en ganska enkel men elegant statistisk lösning som låter dig se resultat som alltid är giltiga, varje gång du tittar, utan att behöva gissa på en minsta detekterbar effekt i förväg. Det kallas sekventiell testning, och vi kommer att diskutera det mer i detalj senare.

Att testa många mål och variationer samtidigt leder till fler fel än du kanske tror.

En annan fallgrop med att använda traditionell statistik innebär att man testar många mål och variationer samtidigt ("multipla jämförelser" eller "multipla testproblem.") Detta händer eftersom traditionell statistik kontrollerar fel genom att kontrollera för falskt positiv frekvens. Ändå matchar inte detta fel, det du anger i din signifikansgräns, risken att fatta ett felaktigt affärsbeslut.

Felfrekvensen du verkligen vill kontrollera för att korrigera för problemet med multipla tester är falsk upptäcktsfrekvensen. I exemplet nedan visar vi hur kontroll för en falskt positiv andel på 10 % (90 % statistisk signifikans) kan leda till 50 % risk att fatta ett felaktigt affärsbeslut på grund av falska upptäckter.

Överväg att testa 5 varianter av din produkt eller webbplats, som var och en har 2 mål som framgångsmått. En av dessa varianter överträffar baslinjen och utses korrekt till vinnare. Enbart genom slumpmässig slump skulle vi förvänta oss att se ungefär en variant till som falskt utses till vinnare (10 % av de 9 återstående kombinationerna av mål och variant). Vi har nu 2 varianter som utses till vinnare.

Även om vi kontrollerade för en falskt positiv andel på 10 % (1 falskt positiv), har vi en mycket högre (50 %) andel falska resultat till bra resultat, vilket avsevärt ökar risken att fatta fel beslut.

I detta experiment finns det två vinnare av tio testade kombinationer av målvariationer. Endast en av dessa vinnare skiljer sig faktiskt från baslinjen, medan den andra är falskt positiv.

Att kontrollera för falskt positiv frekvens är farligt eftersom försöksledaren omedvetet straffas för att testa många mål och variationer. Om du inte är försiktig tar du på dig mer praktisk risk än du är medveten om. För att undvika detta problem i traditionell A/B-testning måste du alltid ha i åtanke antalet experiment som körs. Ett avgörande resultat från 10 tester skiljer sig från ett från 2 tester.

Lyckligtvis finns det ett principiellt sätt att få felfrekvensen för ditt experiment att matcha den felfrekvens du tror att du får. Stats Engine åstadkommer detta genom att kontrollera fel som kallas falska upptäckter. Felfrekvensen du anger i din signifikansgräns med Stats Engine kommer att återspegla den verkliga sannolikheten för att fatta ett felaktigt affärsbeslut.

Hur Stats Engine fungerar

Stats Engine kombinerar innovativa statistiska metoder för att ge dig tillförlitlig data snabbare.

Vi har hört från våra kunder under de senaste fyra åren om ovanstående problem, och vi visste att det måste finnas ett bättre sätt att lösa dem än en urvalsstorlekskalkylator och mer pedagogiska artiklar.

Vi samarbetade med statistiker från Stanford för att utveckla ett nytt statistiskt ramverk för A/B-testning som är kraftfullt, korrekt och, viktigast av allt, enkelt. Denna nya Stats Engine består av två metoder: sekventiell testning och kontroll av falsk upptäcktsfrekvens.

Sekventiell testning: Fatta beslut så snart du ser en vinnare.

Till skillnad från testning med fast horisont, som antar att du bara kommer att utvärdera dina experimentdata vid en viss tidpunkt, vid en bestämd urvalsstorlek, är sekventiell testning utformad för att utvärdera experimentdata allt eftersom de samlas in. Sekventiella tester kan stoppas när som helst med giltiga resultat.

Experimentörer har sällan en fast urvalsstorlek tillgänglig, och deras mål är vanligtvis att få en tillförlitlig slutsats så snabbt som möjligt. Stats Engine uppfyller dessa mål med en implementering av sekventiell testning som beräknar ett genomsnittligt sannolikhetsförhållande – den relativa sannolikheten att variationen skiljer sig från baslinjen – varje gång en ny besökare utlöser en händelse. P-värdet för ett test representerar nu chansen att testet någonsin kommer att nå det signifikansgränsvärde som du väljer. Det är analogin till ett traditionellt p-värde för en värld där din urvalsstorlek är dynamisk. Detta kallas ett test med styrka ett, och det passar bättre än ett traditionellt t-test för A/B-testare.

Detta innebär att du får tillförlitliga, giltiga slutsatser så snart de är tillgängliga utan att behöva ställa in en minsta detekterbar effekt i förväg eller vänta på att nå en fast urvalsstorlek.

Kontroll av falsk upptäcktsfrekvens: Testa många mål och variationer med garanterad noggrannhet.

Att rapportera en falsk upptäcktsfrekvens på 10 % innebär att "högst 10 % av vinnare och förlorare inte har någon skillnad mellan variation och baslinje", vilket är exakt risken att fatta ett felaktigt affärsbeslut.

Med Stats Engine rapporterar Optimizely nu vinnare och förlorare med låg falsk upptäcktsfrekvens istället för låg falsk positiv frekvens. När du lägger till mål och variationer i ditt experiment kommer Optimizely att korrigera mer för falska upptäckter och bli mer konservativ när det gäller att avgöra en vinnare eller förlorare. Även om färre vinnare och förlorare rapporteras totalt sett (vi hittade ungefär 20 % färre i vår historiska databas*), kan en försöksledare implementera dem med full kunskap om risken.

I kombination med sekventiell testning ger kontroll av falsk upptäcktsfrekvensen en korrekt bild av risken för fel när du tittar på testresultaten. Kontrollen ger dig en transparent bedömning av risken du har för att fatta ett felaktigt beslut.

Detta innebär att du kan testa så många mål och variationer du vill med garanterad noggrannhet.

* På ett stort, representativt urval av historiska A/B-tester av Optimizelys kunder fann vi att det fanns ungefär 20 % färre variationer med en falsk upptäcktsfrekvens på mindre än 0,1 jämfört med en falsk positiv frekvens på samma nivå.

Hur det är bättre

Optimizelys Stats Engine minskar fel utan att offra hastighet.

Vi körde om 48 000* historiska experiment med Stats Engine och resultaten är tydliga: Stats Engine ger mer exakta och handlingsbara resultat utan att offra hastighet.

Ha mer förtroende för dina vinnare och förlorare.

Åtgärdade Horizon-statistik som utsågs till vinnare eller förlorare i 36 % av testerna (när testet avbröts). I samma datamängd utsåg Stats Engine vinnare eller förlorare i 22 % av testerna.

Stats Engine avslöjade 39 % färre avgörande testresultat än traditionell statistik. Även om denna siffra kan vara alarmerande (och till en början oroade den oss också!) fann vi att många av dessa avbrutna experiment sannolikt avbröts för tidigt.

För att komma fram till detta resultat använde vi en liknande metod som den kunder använder när de manipulerar urvalsstorlekskalkylatorn för att avgöra om ett test har styrka (sannolikheten att du kommer att upptäcka en effekt om en faktiskt finns) efter att det startat – en post-hoc-styrkeberäkning. Att köra understyrkade tester tyder på att det inte finns tillräckligt med information i data för att tydligt kunna skilja mellan falskt positiva och sant positiva resultat. Med 80 % som vår standard för styrka, var de flesta (80 %) av de experiment som Stats Engine inte längre kallade avgörande underpresterande, medan de flesta (77 %) av de experiment som Stats Engine behöll var starka.

Stabila rekommendationer du kan lita på.

Statistik för fast horisont ändrade sin deklaration av vinnare eller förlorare i 44 % av våra historiska experiment. Stats Engine ändrade deklarationer i 6 % av dessa tester.

Med statistik för fast horisont kunde du se en vinnare en dag och ett ofullständigt resultat nästa. Den enda giltiga deklarationen var den med din förutbestämda urvalsstorlek. Med Stats Engine är resultaten alltid giltiga och det är osannolikt att de ändrar ett slutgiltigt resultat.

Med Stats Engine sjönk andelen falskt positiva resultat från >20 % till <5 .>

Kom ihåg våra A/A-testsimuleringar (varje test kördes till 5000 besökare) när vi diskuterade farorna med att titta på video. I dessa simuleringar körde vi tester med 95 % signifikans och fann:

• Om du tittade på resultaten efter varje ny besökare i experimentet finns det 57 % chans att utse en vinnare eller förlorare.
• Om du tittade på var 500:e besökare finns det 26 % chans för ett falskt påstående.
• Om du tittade på var 1000:e besökare finns det 20 % chans för ett falskt påstående.
• Med sekventiell testning (som tittar på varje besökare) sjunker samma feltal till 3 %.

Om vi ​​kör dessa simuleringar på högre urvalsstorlekar (säg 10 000 eller till och med 1 000 000 besökare) ökar chansen för ett falskt påstående med traditionell statistik (lätt över 70 % beroende på urvalsstorlek) oavsett hur ofta du tittar på dina resultat. Med sekventiell testning ökar även denna felfrekvens, men den övre gränsen är 5 %.

Det finns ingen hake: Noggranna och handlingsbara resultat behöver inte offra hastighet.

Så om du läser så här långt kanske du undrar: Vad är haken? Det finns ingen.

Här är anledningen: Att välja en lämplig urvalsstorlek innebär att välja en minsta detekterbara effekt i förväg. Som diskuterats tidigare är det en svår uppgift. Om du för varje experiment (innan du körde det) ställer in MDE inom 5 % av experimentets faktiska lyft, kommer det sekventiella testet i genomsnitt att vara 60 % långsammare.

Men i verkligheten väljer utövare en MDE som är utformad för att vara lägre än observerade lyft. Den återspeglar den längsta tid de är villiga att köra ett experiment. Med Stats Engine, när den verkliga ökningen är större än din MDE, kommer du att kunna anropa ditt test snabbare.

Vi fann att om ökningen av ditt A/B-test slutar 5 procentenheter (relativt) högre än din MDE, kommer Stats Engine att köras lika snabbt som Fixed Horizon-statistiken. Så snart förbättringen överstiger MDE med så mycket som 7,5 procentenheter är Stats Engine närmare 75 % snabbare. För större experiment (>50 000 besökare) är vinsterna ännu högre och Stats Engine kan avgöra en vinnare eller förlorare upp till 2,5 gånger så snabbt.

Möjligheten att få tester att köras inom en rimlig tidsram är en av de svåraste uppgifterna när man tillämpar sekventiell testning på A/B-testning och optimering. Vår stora databas med historiska experiment gör det möjligt för oss att finjustera Stats Engine från tidigare information. Genom att utnyttja vår omfattande experimentdatabas kan Optimizely leverera de teoretiska fördelarna med sekventiell testning och FDR-kontroll utan att medföra praktiska kostnader.

*En anmärkning om data: Datasetet vi testade hade experiment med ett medianvärde på 10 000 besökare. Tester med ett lägre antal besökare hade ett lägre antal deklarationer i både Fixed Horizon Testing och Stats Engine, ett liknande antal ändrade deklarationer, men vi är snabbare på att visa hastighetsvinster för sekventiell testning.

Vad detta betyder för varje testkörning fram till idag

Låt oss förtydliga en sak: Traditionell statistik kontrollerar fel vid förväntade frekvenser när den används korrekt. Det betyder att om du har använt en urvalsstorlekskalkylator och hållit dig till dess rekommendationer behöver du förmodligen inte oroa dig för tester du kört tidigare. På samma sätt, om du tenderar att fatta affärsbeslut baserat endast på primära konverteringsstatistik, minskar skillnaden mellan din falska upptäckt och falskt positiva frekvens. För Optimizely-användare som redan vidtog dessa försiktighetsåtgärder kommer Stats Engine att ge ett mer intuitivt arbetsflöde och minska ansträngningen med att köra tester.

Vi vet också att det finns många människor där ute som förmodligen inte gjorde exakt vad urvalsstorlekskalkylatorn sa åt dem att göra. Men digitala experimentatörer är ett kunnigt och skeptiskt gäng. Du kanske har väntat ett visst antal dagar innan du får fram resultaten, väntat längre om det såg skumt ut eller kört om din urvalsstorleksberäkning varje gång du tittade för att se hur mycket längre tid det tog att vänta. Alla dessa metoder hjälper till att minska risken för att göra ett fel. Även om din felfrekvens sannolikt är högre än 5 %, skulle den förmodligen inte heller vara över 30 %. Om du tillhör den här gruppen befriar Stats Engine dig från dessa metoder och ger dig istället exakta förväntningar om de felfrekvenser du kan förvänta dig.

Ett litet steg för Optimizely, ett jättekliv för onlineoptimering

Optimizelys uppdrag är att göra det möjligt för världen att omvandla data till handling. För fem år sedan tog vi vårt första steg mot detta uppdrag genom att göra A/B-testning tillgänglig för icke-ingenjörer med vår visuella redigerare. Nu har tiotusentals organisationer anammat en filosofi att integrera data i varje beslut.

Idag vill vi med Stats Engine ta branschen ett steg längre genom att ta bort ytterligare ett hinder för att bli en datadriven organisation. Genom att ge vem som helst möjlighet att analysera resultat med kraftfull statistik strävar vi efter att ge företag möjlighet att stödja ännu viktigare beslut med data.

Att få statistiken rätt är avgörande för att fatta datadrivna beslut, och vi är engagerade i att utveckla vår statistik för att stödja våra kunder. Vi kan inte vänta med att arbeta med dig för att skriva nästa kapitel inom onlineoptimering.

Vi ser fram emot din feedback och dina tankar om statistik. Låt oss veta vad du tycker i kommentarerna!

Vill du lära dig mer? Vi har skapat ett antal ytterligare resurser för att hjälpa dig att komma igång med statistik med Optimizely: