Historien bak statistikkmotoren vår

Klassiske statistiske teknikker, som t-testen, er grunnfjellet i optimaliseringsbransjen, og hjelper bedrifter med å ta datadrevne beslutninger. Etter hvert som nettbasert eksperimentering har eksplodert, er det nå klart at disse tradisjonelle statistiske metodene ikke passer for digitale data: Å bruke klassisk statistikk på A/B-testing kan føre til feilrater som er mye høyere enn de fleste eksperimentatorer forventer.

Både bransjen og akademiske eksperter har vendt seg til utdanning som løsningen. Ikke kikk! Bruk en kalkulator for utvalgsstørrelse! Unngå å teste for mange mål og variasjoner samtidig!

Men vi har konkludert med at det er på tide at statistikken, ikke kundene, endrer seg. Si farvel til den klassiske t-testen. Det er på tide med statistikk som er enkel å bruke og som fungerer med hvordan bedrifter faktisk opererer.

I samarbeid med et team av statistikere fra Stanford utviklet vi Stats Engine, et nytt statistisk rammeverk for A/B-testing. Vi er glade for å kunne kunngjøre at det fra 21. januar 2015 gir resultater for alle Optimizely-kunder.

Dette blogginnlegget er langt, fordi vi ønsker å være helt transparente om hvorfor vi gjør disse endringene, hva endringene faktisk er og hva dette betyr for A/B-testing generelt. Følg oss til slutten, du vil lære:

• Hvorfor vi laget Stats Engine:Internett gjør det enkelt å evaluere eksperimentresultater når som helst og kjøre tester med mange mål og variasjoner. Når disse intuitive handlingene kombineres med klassisk statistikk, kan de øke sjansen for feilaktig å deklarere en vinnende eller tapende variant med over 5 ganger.

• Slik fungerer det: Vi kombinerer sekvensiell testing og kontroller for falsk oppdagelsesrate for å levere resultater som er gyldige uavhengig av utvalgsstørrelse og samsvarer med feilraten vi rapporterer med feilen bedriftene bryr seg om.
• Hvorfor det er bedre: Stats Engine kan redusere sjansen for feilaktig å deklarere en vinnende eller tapende variant fra 30 % til 5 % uten å ofre hastighet.

Hvorfor vi laget en ny Stats Engine

Tradisjonell statistikk er lite intuitiv, lett å misbruke og sparer penger.

For å få gyldige resultater fra A/B-tester som kjøres med klassisk statistikk, følger nøye eksperimentatorer et strengt sett med retningslinjer: Sett en minimum detekterbar effekt og utvalgsstørrelse på forhånd, ikke kikk på resultatene, ikke test for mange mål og variasjoner samtidig.

Disse retningslinjene kan være tungvinte, og hvis du ikke følger dem nøye, kan du ubevisst introdusere feil i testene dine. Dette er problemene med disse retningslinjene som vi satte oss fore å løse med Stats Engine:

• Å forplikte seg til en detekterbar effekt og utvalgsstørrelse på forhånd er ineffektivt og ikke intuitivt.
• Å kikke på resultater før man når den utvalgsstørrelsen kan introdusere feil i resultatene, og du kan iverksette tiltak mot falske vinnere.
• Å teste for mange mål og variasjoner samtidig øker feil på grunn av falsk oppdagelse betraktelig – en feilrate som kan være mye større enn den falske positive raten.

Å forplikte seg til en utvalgsstørrelse og detekterbar effekt kan bremse deg.

Å angi en utvalgsstørrelse før du kjører en test bidrar til å unngå å gjøre feil med tradisjonelle statistiske metoder. For å angi en utvalgsstørrelse må du også gjette på den minste detekterbare effekten (MDE), eller forventet konverteringsrate-økningen, du ønsker å se fra testen din. Hvis du gjetter feil, kan det ha store konsekvenser for testhastigheten.

Hvis du angir en liten effekt, må du vente på en stor utvalgsstørrelse for å vite om resultatene dine er signifikante. Hvis du angir en større effekt, risikerer du å gå glipp av mindre forbedringer. Dette er ikke bare ineffektivt, det er heller ikke realistisk. De fleste kjører tester fordi de ikke vet hva som kan skje, og det gir ikke mye mening å forplikte seg på forhånd til en hypotetisk økning.

Å kikke på resultatene dine øker feilraten.

Når data flyter inn i eksperimentet ditt i sanntid, er det fristende å stadig sjekke resultatene dine. Du ønsker å implementere en vinner så snart som mulig for å forbedre virksomheten din, eller stoppe en ufullstendig eller tapende test så tidlig som mulig, slik at du kan gå videre til å teste flere hypoteser.

Statistikere kaller denne konstante kikkingen «kontinuerlig overvåking», og det øker sjansen for at du finner et vinnende resultat når det faktisk ikke finnes noe (selvfølgelig er kontinuerlig overvåking bare problematisk når du faktisk stopper testen tidlig, men du skjønner poenget.) Å finne en ubetydelig vinner kalles en falsk positiv, eller type I-feil.

Enhver test for statistisk signifikans du kjører, vil ha en viss sjanse for feil. Å kjøre en test med 95 % statistisk signifikans (med andre ord, en t-test med en alfaverdi på 0,05) betyr at du aksepterer en 5 % sjanse for at testen ville vist et signifikant resultat dersom dette var en A/A-test uten noen faktisk forskjell mellom variasjonene.

For å illustrere hvor farlig kontinuerlig overvåking kan være, simulerte vi millioner av A/A-tester med 5000 besøkende, og evaluerte sjansen for å gjøre en feil under ulike typer kontinuerlige overvåkingsregler. Vi fant ut at selv konservative regler kan øke feilratene fra et mål på 5 % til over 25 %.

I vår undersøkelse erklærte mer enn 57 % av simulerte A/A-tester feilaktig en vinner eller taper minst én gang i løpet av forløpet, selv om det bare var kort. Med andre ord, hvis du hadde sett disse testene, ville du kanskje lurt på hvorfor A/A-testresultatene dine erklærte en vinner. Økningen i feilrate er fortsatt meningsfull selv om du ikke ser på hver besøkende. Hvis du ser på hver 500. besøkende, øker sjansen for å avgi en falsk erklæring til 26 %, mens det å se på hver 1000. besøkende øker den samme sjansen til 20 %.

Denne grafen over det statistiske signifikansnivået for én A/A-test over tid viser hvor forsøkslederen ville ha sett et signifikant resultat dersom hun hadde overvåket testen kontinuerlig.

Selv om du er klar over dette problemet, fører rimelige «rettelser» fortsatt til høye feilrater. La oss for eksempel si at du ikke stoler på et signifikant resultat for A/B-testen din. Som mange Optimizely-brukere kan du bruke en kalkulator for utvalgsstørrelse mens testen din allerede kjører for å avgjøre om testen har kjørt lenge nok. Å bruke kalkulatoren til å justere utvalgsstørrelsen mens testen kjører er det som kalles en «post-hoc-beregning», og selv om det reduserer noe av risikoen for kontinuerlig overvåking, fører det fortsatt til feilrater som ligger rundt 25 %.

Frem til nå har den eneste måten å beskytte seg mot disse feilene vært å bruke utvalgsstørrelseskalkulatoren før du starter testen, og deretter vente til testen når utvalgsstørrelsen før du tar avgjørelser basert på resultatene dine.

Den gode nyheten er at det faktisk finnes en ganske enkel, men elegant statistisk løsning som lar deg se resultater som alltid er gyldige, hver gang du kikker, uten å måtte gjette på en minimum detekterbar effekt på forhånd. Det kalles sekvensiell testing, og vi skal diskutere det mer detaljert senere.

Å teste mange mål og variasjoner samtidig fører til flere feil enn du kanskje tror.

En annen fallgruve ved bruk av tradisjonell statistikk innebærer å teste mange mål og variasjoner samtidig («multiple sammenligninger» eller «multiple testing-problemet.»). Dette skjer fordi tradisjonell statistikk kontrollerer feil ved å kontrollere for falsk positiv rate. Likevel samsvarer ikke denne feilen, den du setter i signifikansgrensen din, med sjansen for å ta en feil forretningsbeslutning.

Feilraten du egentlig ønsker å kontrollere for å korrigere for problemet med multiple testing, er falsk oppdagelsesrate. I eksemplet nedenfor viser vi hvordan det å kontrollere for en falsk positiv rate på 10 % (90 % statistisk signifikans) kan føre til 50 % sjanse for å ta en feil forretningsbeslutning på grunn av falske oppdagelser.

Vurder å teste 5 varianter av produktet eller nettstedet ditt, som hver har 2 mål som suksessmålinger. En av disse variantene overgår grunnlinjen og blir korrekt erklært som vinner. Bare ved tilfeldighet ville vi forvente å se omtrent én variant til som feilaktig erklært som vinner (10 % av de 9 gjenværende mål-variant-kombinasjonene). Vi har nå 2 varianter som er erklært som vinnere.

Selv om vi kontrollerte for en falsk positiv rate på 10 % (1 falsk positiv), har vi et mye høyere (50 %) forhold mellom falske resultater og gode, noe som øker sjansen for å ta feil beslutning betraktelig.

I dette eksperimentet er det to vinnere av ti mål-variasjonskombinasjoner som testes. Bare én av disse vinnerne er faktisk forskjellig fra grunnlinjen, mens den andre er falsk positiv.

Det er farlig å kontrollere for falsk positiv rate fordi eksperimentatoren ubevisst blir straffet for å teste mange mål og variasjoner. Hvis du ikke er forsiktig, tar du på deg mer praktisk risiko enn du er klar over. For å unngå dette problemet i tradisjonell A/B-testing må du alltid huske på antall eksperimenter som kjører. Ett konkluderende resultat fra 10 tester er forskjellig fra ett fra 2 tester.

Heldigvis finnes det en prinsipiell måte å få feilraten for eksperimentet ditt til å samsvare med feilraten du tror du får. Stats Engine oppnår dette ved å kontrollere feil kjent som falske oppdagelser. Feilraten du angir i signifikansgrensen din med Stats Engine vil gjenspeile den reelle sjansen for å ta en feil forretningsbeslutning.

Slik fungerer Stats Engine

Stats Engine kombinerer innovative statistiske metoder for å gi deg pålitelige data raskere.

Vi har hørt fra kundene våre de siste fire årene om problemene ovenfor, og vi visste at det måtte finnes en bedre måte å løse dem på enn en kalkulator for utvalgsstørrelse og mer lærerike artikler.

Vi samarbeidet med statistikere fra Stanford for å utvikle et nytt statistisk rammeverk for A/B-testing som er kraftig, nøyaktig og, viktigst av alt, uanstrengt. Denne nye statistikkmotoren består av to metoder: sekvensiell testing og kontroll av falsk oppdagelsesrate.

Sekvensiell testing: Ta avgjørelser så snart du ser en vinner.

I motsetning til testing med fast horisont, som forutsetter at du bare vil evaluere eksperimentdataene dine på ett tidspunkt, med en angitt utvalgsstørrelse, er sekvensiell testing utformet for å evaluere eksperimentdata etter hvert som de samles inn. Sekvensielle tester kan stoppes når som helst med gyldige resultater.

Eksperimentatorer har sjelden en fast utvalgsstørrelse tilgjengelig, og målet deres er vanligvis å få en pålitelig slutning så raskt som mulig. Stats Engine oppfyller disse målene med en implementering av sekvensiell testing som beregner et gjennomsnittlig sannsynlighetsforhold – den relative sannsynligheten for at variasjonen er forskjellig fra grunnlinjen – hver gang en ny besøkende utløser en hendelse. P-verdien til en test representerer nå sjansen for at testen noen gang vil nå signifikansgrensen du velger. Det er analogen til en tradisjonell p-verdi for en verden der utvalgsstørrelsen din er dynamisk. Dette kalles en test med styrke én, og den passer bedre enn en tradisjonell t-test for A/B-testernes mål.

Dette betyr at du får pålitelige, gyldige slutninger så snart de er tilgjengelige, uten å måtte sette en minimum detekterbar effekt på forhånd eller vente på å nå en fast utvalgsstørrelse.

Kontroll av falsk oppdagelsesrate: Test mange mål og variasjoner med garantert nøyaktighet.

Å rapportere en falsk oppdagelsesrate på 10 % betyr at «maksimalt 10 % av vinnere og tapere ikke har noen forskjell mellom variasjon og baseline», som er nøyaktig sannsynligheten for å ta en feil forretningsbeslutning.

Med Stats Engine rapporterer Optimizely nå vinnere og tapere med lav falsk oppdagelsesrate i stedet for lav falsk positiv rate. Når du legger til mål og variasjoner i eksperimentet ditt, vil Optimizely korrigere mer for falske oppdagelser og bli mer konservativ når det gjelder å avgjøre en vinner eller taper. Selv om færre vinnere og tapere rapporteres totalt sett (vi fant omtrent 20 % færre i vår historiske database*), kan en eksperimentator implementere dem med full kunnskap om risikoen som er involvert.

Når den kombineres med sekvensiell testing, gir kontroll av falsk oppdagelsesrate et nøyaktig bilde av sjansen for feil når du ser på testresultatene. Kontrollen gir deg en transparent vurdering av risikoen du har for å ta en feil beslutning.

Dette betyr at du kan teste så mange mål og variasjoner du vil med garantert nøyaktighet.

* På et stort, representativt utvalg av historiske A/B-tester utført av Optimizely-kunder fant vi at det var omtrent 20 % færre variasjoner med en falsk oppdagelsesrate på under 0,1 sammenlignet med en falsk positiv rate på samme nivå.

Hvordan det er bedre

Optimizelys Stats Engine reduserer feil uten å ofre hastighet.

Vi kjørte 48 000* historiske eksperimenter på nytt med Stats Engine, og resultatene er klare: Stats Engine gir mer nøyaktige og handlingsrettede resultater uten å ofre hastighet.

Ha mer tillit til vinnerne og taperne dine.

Fikset Horizon-statistikk erklært en vinner eller taper i 36 % av testene (da testen ble stoppet). I det samme datasettet erklærte Stats Engine vinnere eller tapere i 22 % av testene.

Stats Engine avdekket 39 % færre avgjørende testresultater enn tradisjonell statistikk. Selv om dette tallet kan være alarmerende (og i starten alarmerte det også oss!), fant vi ut at mange av disse avbrutt eksperimentene sannsynligvis ble stoppet for tidlig.

For å komme frem til dette resultatet brukte vi en lignende metode som den kundene bruker når de manipulerer utvalgsstørrelseskalkulatoren for å avgjøre om en test har styrke (sannsynligheten for at du vil oppdage en effekt hvis en faktisk eksisterer) etter at den starter – en post-hoc styrkeberegning. Å kjøre underpowered tester tyder på at det ikke er nok informasjon i dataene til å skille sterkt mellom falske positive og sanne positive. Med 80 % som standard for styrke, var de fleste (80 %) av eksperimentene som Stats Engine ikke lenger kalte konkluderende, understyrkede, mens de fleste (77 %) av eksperimentene som Stats Engine beholdt, var styrkede.

Stabile anbefalinger du kan stole på.

Statistikk for fast horisont endret sin deklarasjon av vinner eller taper i 44 % av våre historiske eksperimenter. Statistikkmotoren endret deklarasjoner i 6 % av disse testene.

Med statistikk for fast horisont kunne du se en vinner én dag, og et usikkert resultat den neste. Den eneste gyldige deklarasjonen var den med din forhåndsbestemte utvalgsstørrelse. Med Stats Engine er resultatene alltid gyldige og det er usannsynlig at de vil endre et avgjørende resultat.

Med Stats Engine falt andelen falske positive resultater fra >20 % til <5 .>

Husk våre A/A-testsimuleringer (hver test ble kjørt til 5000 besøkende) da vi diskuterte farene ved å kikke. I disse simuleringene kjørte vi tester med 95 % signifikans og fant:

• Hvis du så på resultatene etter hver nye besøkende i eksperimentet, er det 57 % sjanse for å erklære en vinner eller taper.
• Hvis du så på hver 500. besøkende, er det 26 % sjanse for en falsk erklæring.
• Hvis du så på hver 1000. besøkende, er det 20 % sjanse for en falsk erklæring.
• Med sekvensiell testing (som ser på hver besøkende) faller det samme feiltallet til 3 %.

Hvis vi kjører disse simuleringene til større utvalgsstørrelser (for eksempel 10 000 eller til og med 1 000 000 besøkende), øker sjansen for en falsk erklæring med tradisjonell statistikk (lett over 70 % avhengig av utvalgsstørrelse) uavhengig av hvor ofte du ser på resultatene dine. Med sekvensiell testing øker også denne feilraten, men den øvre grensen er 5 %.

Det er ingen hake: Nøyaktige og handlingsrettede resultater trenger ikke å ofre hastighet.

Så når du leser så langt, lurer du kanskje på: Hva er haken? Det finnes ingen.

Her er hvorfor: Å velge en riktig utvalgsstørrelse betyr å velge en minimum detekterbar effekt på forhånd. Som diskutert tidligere, er det en vanskelig oppgave. Hvis du for hvert eksperiment (før du kjørte det) setter MDE innenfor 5 % av den faktiske økningen i eksperimentet, vil den sekvensielle testen i gjennomsnitt være 60 % tregere.

I realiteten velger imidlertid utøvere en MDE som er designet for å være lavere enn observerte økninger. Det gjenspeiler den lengste tiden de er villige til å kjøre et eksperiment. Med Stats Engine, når den faktiske økningen er større enn MDE-en din, vil du kunne kalle testen din raskere.

Vi fant ut at hvis økningen i A/B-testen din ender opp med å være 5 prosentpoeng (relativt) høyere enn MDE-en din, vil Stats Engine kjøre like raskt som Fixed Horizon-statistikken. Så snart forbedringen overstiger MDE-en med så mye som 7,5 prosentpoeng, er Stats Engine nærmere 75 % raskere. For større eksperimenter (>50 000 besøkende) er gevinstene enda høyere, og Stats Engine kan avgjøre en vinner eller taper opptil 2,5 ganger så raskt.

Muligheten til å få tester til å kjøre på rimelig tid er en av de vanskeligste oppgavene når man bruker sekvensiell testing til A/B-testing og optimalisering. Vår store database med historiske eksperimenter lar oss finjustere Stats Engine fra tidligere informasjon. Ved å utnytte vår omfattende eksperimentdatabase kan Optimizely levere de teoretiske fordelene med sekvensiell testing og FDR-kontroll uten å påføre praktiske kostnader.

*Et notat om dataene: Datasettet vi testet hadde eksperimenter med en median på 10 000 besøkende. Tester med et lavere antall besøkende hadde et lavere antall deklarasjoner i både Fixed Horizon Testing og Stats Engine, et lignende antall endrede deklarasjoner, men vi er raskere til å vise hastighetsgevinster for sekvensiell testing.

Hva dette betyr for hver testkjøring frem til i dag

La oss avklare én ting: Tradisjonell statistikk kontrollerer feil med forventede rater når den brukes riktig. Det betyr at hvis du har brukt en kalkulator for utvalgsstørrelse og holdt deg til anbefalingene, trenger du sannsynligvis ikke å bekymre deg for tester du kjørte tidligere. På samme måte, hvis du har en tendens til å ta forretningsbeslutninger basert kun på primære konverteringsmålinger, reduseres forskjellen mellom falsk oppdagelse og falsk positiv rate. For Optimizely-brukere som allerede tok disse forholdsreglene, vil Stats Engine gi en mer intuitiv arbeidsflyt og redusere innsatsen som kreves for å kjøre tester.

Vi vet også at det er mange der ute som sannsynligvis ikke gjorde akkurat det utvalgsstørrelseskalkulatoren fortalte deg å gjøre. Men digitale eksperimentatorer er en smart og skeptisk gjeng. Du har kanskje ventet et visst antall dager før du fikk se resultatene, ventet lenger hvis ting så mistenkelige ut, eller kjørt utvalgsstørrelsesberegningen på nytt hver gang du kikket for å se hvor mye lenger du skal vente. Alle disse fremgangsmåtene bidrar til å bekjempe sjansen for å gjøre en feil. Selv om feilraten din sannsynligvis er høyere enn 5 %, vil den sannsynligvis heller ikke være over 30 %. Hvis du faller inn under denne gruppen, frigjør Stats Engine deg fra disse fremgangsmåtene og gir deg i stedet nøyaktige forventninger om feilratene du kan forvente.

Et lite skritt for Optimizely, et stort sprang for online optimalisering

Optimizelys oppdrag er å gjøre det mulig for verden å gjøre data om til handling. For fem år siden tok vi vårt første skritt mot dette målet ved å gjøre A/B-testing tilgjengelig for ikke-ingeniører med vår visuelle editor. Nå har titusenvis av organisasjoner omfavnet en filosofi om å integrere data i alle beslutninger.

I dag, med Stats Engine, ønsker vi å ta bransjen et skritt videre ved å fjerne enda en barriere for å bli en datadrevet organisasjon. Ved å gi alle mulighet til å analysere resultater med kraftig statistikk, tar vi sikte på å gi bedrifter mulighet til å støtte enda viktigere beslutninger med data.

Å få riktig statistikk er avgjørende for å ta datadrevne beslutninger, og vi er forpliktet til å utvikle statistikken vår for å støtte kundene våre. Vi gleder oss til å samarbeide med deg for å skrive neste kapittel innen online optimalisering.

Vi ser frem til tilbakemeldinger og tanker om statistikk. Gi oss beskjed om hva du synes i kommentarfeltet!

Vil du lære mer? Vi har laget en rekke tilleggsressurser for å hjelpe deg med å komme deg oppdatert på statistikk med Optimizely: