Utvalgsstørrelse før du starter: Beregningen de fleste A/B-tester hopper over

Utvalgsstørrelse før du starter: Beregningen de fleste A/B-tester hopper over

De fleste A/B-tester mislykkes før en eneste besøkende ser dem. Ikke fordi hypotesen var svak eller designet var dårlig, men fordi ingen fant ut om testen i det hele tatt kunne gi et svar.

Mønsteret er kjent. Et team sender en variant, følger med på dashbordet, og etter ti dager ser de at utfordreren er opp 6 % med en p-verdi på 0.14. Noen sier «den trender positivt, la oss gi det en uke til.» En uke til går. Nå er den opp 4 %, p = 0.09. Testen blir kalt en «retningsbestemt seier» og sendt, eller den blir avvist som ufullstendig. Uansett ga tre uker med trafikk ingen kunnskap – og det resultatet ble fullstendig bestemt før lansering av fire tall ingen sjekket.

Denne artikkelen handler om disse fire tallene.

De fire inngangene

Utvalgsstørrelse er ikke en vurdering. Den faller ut fra fire parametere, og ethvert seriøst eksperimenteringsprogram fikser dem før lansering i stedet for etter.

InputHva det betyrTypisk verdi
Grunnleggende konverteringsfrekvensDen nåværende frekvensen for beregningen du tester, målt på den nøyaktige siden og målgruppen testen skal kjøres påUansett hva dataene dine sier
Minimum detekterbar effekt (MDE)Den minste endringen du vil at testen skal kunne finne5–20 % relativt, avhengig av trafikk
Signifikansnivå (α)Din toleranse for å erklære en vinner som ikke er ekte0.05
Statistisk styrke (1−β)Sannsynligheten din for å oppdage en effekt som is ekte0.80

Gi en kalkulator disse fire, og den returnerer det nødvendige antallet besøkende per variant. Vår gratis A/B-testkalkulator gjør akkurat dette, og det tar omtrent tretti sekunder – som er poenget. Grunnen til at lag hopper over dette trinnet er ikke at det er vanskelig. Det er at svaret ofte er uvelkomment.

MDE er inndataene alle får feil

Minimum detekterbar effekt er parameteren som forårsaker mest skade, fordi navnet antyder noe den ikke er.

MDE er ikke økningen du forventer. Det er ikke en prediksjon, et mål eller en prognose. Det er en grense for detekterbarhet: den minste sanne effekten testen din har 80 % sjanse for å fange opp. Sett MDE til 5 %, og du sier «hvis den virkelige forbedringen er mindre enn 5 %, aksepterer jeg at denne testen sannsynligvis vil bomme på den».

To konsekvenser følger, og begge har betydning.

En test kan bare svare på spørsmålet du dimensjonerte den for. Hvis du vurderer en 20 % MDE og den virkelige effekten er 7 %, vil testen mest sannsynlig returnere «ingen signifikant forskjell». Det er ikke bevis på at varianten ikke gjør noe. Det er bevis på at testen din ikke kunne se effekter av den størrelsen – en helt annen påstand, og en som team rutinemessig feiloversetter til «vi testet det, det fungerte ikke».

Relativ og absolutt MDE er ikke utskiftbare. En grunnlinje på 2.5 % med 10 % slektning MDE betyr å oppdage en bevegelse til 2.75 % – en absolutte en forskjell på 0.25 prosentpoeng. Skriv inn 10 i et kalkulatorfelt og forvent absolutte prosentpoeng, og du har nettopp bedt om å oppdage en bevegelse fra 2.5 % til 12.5 %, og verktøyet vil muntert fortelle deg at 400 besøkende vil gjøre det. Sjekk hvilken konvensjon kalkulatoren din bruker. Denne ene forvirringen ugyldiggjør flere testplaner enn noen annen feil vi ser.

Et praktisert eksempel

En e-handelsklient ønsker å teste et nytt oppsett for produktdetaljsiden. Grunnleggende konvertering på den siden er 2.5 %. De ønsker å oppdage en relativ forbedring på 10 % – en endring til 2.75 %.

Ved α = 0.05 og 80 % effekt er kravet omtrent 100 000 besøkende per variant, eller omtrent 128 000 totalt.

Den siden får 40 000 besøkende i måneden. Så testen trenger litt over tre måneder for å nå utvalgsstørrelsen den var designet for.

Det er dette tallet som endrer samtalen. Ikke fordi tre måneder er umulig, men fordi det nå er en avgjørelse som tas åpent – ​​før lansering, med avveiningene synlige – snarere enn en langsom skuffelse oppdaget på dag 21.

Endre nå én inndata. Behold samme grunnlinje, men størrelse for en relativ løft på 20 % i stedet for 10 %:

MDE (relativ)Absolutt forskjellBesøkende per variantTid på 40 000/måned
5%0.125 s~ 256,000~ 13 måneder
10%0.25 s~ 64,000~ 3.2 måneder
20%0.5 s~ 16,800~ 25 dager
30%0.75 s~ 7,700~ 12 dager

Å halvere MDE firedobler omtrent utvalget. Dette forholdet er ikke en særegenhet ved disse tallene – utvalgsstørrelsen skaleres med den inverse kvadraten av effektstørrelsen. Det er det aller mest nyttige å internalisere om eksperimentdesign, fordi det forteller deg hvor innflytelsen er: Å gjøre en større endring er mye billigere enn å samle mer trafikk.

En forsiktig variant som flytter en knapp to piksler trenger en utvalgsstørrelse ingen mellomstor nettside kan tilby. En variant som omstrukturerer siden har en sjanse. Det er derfor forsiktige testprogrammer stopper opp – ikke fordi ideene er feil, men fordi de er for små til å måle.

Der trafikken faktisk er

Den andre spaken som skjuler seg i regnestykket er grunnlinjeraten. Kravene til utvalgsstørrelse faller kraftig etter hvert som grunnlinjen øker.

Ta den samme 10 % relative MDE, men kjør den på frakttrinnet i kassen, hvor 40 % av ankomstene fortsetter til betaling:

  • Grunnverdi 2.5 % → ~64,000 per variant
  • Grunnverdi 40 % → ~2,400 per variant

Samme MDE, samme selvtillit, samme kraft. Tjueseks ganger mindre trafikk.

Den siden har selvfølgelig langt færre besøkende enn PDP-en. Men kravet synker raskere enn trafikken, og det er derfor deep-funnel-tester ofte er de eneste testene et nettsted med middels trafikk faktisk kan fullføre. Hvis konverteringen på hele nettstedet er 2 %, er testing av hjemmesiden en årslang forpliktelse, og testing av betalingsprosessen tar to uker.

Praktisk veiledning: Når kalkulatoren returnerer et umulig tall, må du sjekke om det finnes et trinn lenger nede i trakten der den samme hypotesen kan testes mot en høyere grunnlinje før du utvider MDE.

Hva går egentlig galt når du hopper over det

Det finnes to feilmoduser her, og den andre er mye mindre kjent enn den første.

Du går glipp av reelle forbedringer. En test med lav ytelse gir «ingen signifikant forskjell» for en endring som virkelig fungerer. Teamet konkluderer med at ideen var dårlig og forlater en retning som ville ha lønnet seg. Dette er fiaskoen alle kjenner til, og det er den billigste av de to.

Vinnerne dine er oppblåste. Dette er den som i stillhet korrumperer et programs tall. I en test med lav styrke er den eneste måten et resultat kan overskride signifikansgrensen hvis tilfeldig støy oppstår som presser det langt nok – som betyr at effektene du do De som erklærer signifikante er systematisk større enn sannheten. Jo lavere potens, desto verre er overdrivelsen.

Så et program med lav ytelse bommer ikke bare på ting. Det produserer en testlogg full av vinnere med overvurderte økninger, som deretter multipliseres med trafikk for å forutsi inntekter som aldri materialiserer seg. Seks måneder senere spør noen hvorfor summen av gevinstene ikke vises i topplinjen. Dette er vanligvis svaret.

Du kan ikke fikse dette i analysen. Det må forhindres i designfasen.

Per variant, ikke totalt

Kalkulatorutdata er kravet for hver arm av testen. To varianter betyr dobbelt så mange. Dette høres opplagt ut og blir stadig feiltolket, vanligvis i den optimistiske retningen.

Flere varianter forverrer problemet dobbelt. En A/B/C/D-test trenger fire ganger utvalget av enarmsfiguren, og Tre samtidige sammenligninger mot kontrollgruppen øker sjansen for minst én falsk positiv verdi godt utover de nominelle 5 %. Hvis man korrigerer for det, presser man kravet opp igjen.

For de fleste nettsteder er den praktiske regelen: med mindre du har trafikk til overs, kjør to armer. En fireveis test på en side som knapt kan drive en toveis test er ikke fire ganger så mye læring. Den er null ganger så mye læring, levert saktere.

Varighet er en separat begrensning

Det er nødvendig å nå utvalgsstørrelsen. Det er ikke tilstrekkelig.

En test som når tallet sitt på fire dager har målt fire dagers atferd. Trafikk på hverdager og i helger konverterer ulikt. Lønningsdagssykluser er viktige i e-handel. Betalte kampanjer som lanseres midt i testen endrer publikumsmiksen under deg. Nye design gir også en nyhetseffekt som avtar – tidlig engasjement med et ukjent oppsett er ikke et stabilt estimat av ytelse i stabil tilstand.

Kjør i minst én hel uke, og helst to, uavhengig av hva beregningen av utvalgsstørrelsen tillater. Den begrensningen som er lengst – utvalgsstørrelse eller konjunktursyklus – er den som styrer. Og sett sluttdatoen på forhånd i stedet for å sjekke hver morgen og stoppe når tallene ser bra ut, noe som er en separat og svært effektiv måte å produsere falske vinnere på.

Når tallet er umulig

Noen ganger er det ærlige svaret at testen ikke kan kjøres. Det er nyttig informasjon, og det finnes fem fornuftige svar.

Test en større endring. Det kvadratiske forholdet gjør dette til det alternativet med høyest gearing med god margin. Redesign flyten i stedet for knappen.

Gå over til en høyere baseline-måling. Test mot kjøp eller kjøp i stedet for kjøp. Effektstørrelsen måles mot en større base, og utvalgskravet kollapser. Godta at du måler en proxy, og valider koblingen til inntekter separat.

Test lenger ned i trakten, som ovenfor.

Grupper lignende sider. Å kjøre én test på tvers av alle kategorisider i stedet for én enkelt kategori multipliserer tilgjengelig trafikk, forutsatt at sidene er like nok i atferd til at sammenslåing er forsvarlig.

Slutt å teste og begynn å undersøke. Hvis et nettsted ikke kan drive et eksperiment, er A/B-testing feil instrument for det. Brukbarhetstesting, øktopptak og heuristisk gjennomgang vil finne de ødelagte tingene raskere og billigere. Kvantitativ validering kommer senere, når endringene er store nok til å være målbare. Det er ingen skam i dette – å kjøre underdrevne tester for å føle seg grundig er verre enn å ikke kjøre dem.

Sjekkliste før flyturen

Før noen test starter:

  • [ ] Grunnverdi målt på den faktiske siden og målgruppen testen kjøres på, ikke på hele nettstedet
  • [ ] MDE anga eksplisitt, skriftlig, med relative eller absolutte spesifiseringer
  • [ ] Utvalgsstørrelse beregnet per variant og multiplisert med antall armer
  • [] Nødvendig varighet sammenlignet med tilgjengelig trafikk – og svaret som ble akseptert før lansering
  • [ ] Sluttdato fastsatt på forhånd
  • [ ] Minimum én full konjunktursyklus, uansett hva matematikken sier
  • [ ] Randomiseringsenheten samsvarer med analyseenheten (tildeling på besøksnivå, målinger på besøksnivå)
  • [ ] Trafikkfordeling bekreftet i løpet av de første timene – en 50/50-test som gir 53/47 betyr et instrumentproblem, og resultatene er ubrukelige inntil det er funnet.

Kjør tallene før du bygger varianten

Hele beregningen tar et halvt minutt, og den endrer hva du bygger. Team som dimensjonerer testene sine, utformer først dristigere varianter, fordi de kan se hva de mer forsiktige vil koste.

Skriv inn den grunnleggende konverteringsfrekvensen din, effekten du ønsker å kunne oppdage, og innstillingene dine for selvtillit og effekt. Hvis tallet som kommer tilbake er større enn trafikken din, er det uansett ikke en grunn til å lansere – det er testen som forteller deg at du bør endre planen.

Ofte stilte spørsmål

Hvor mange besøkende trenger jeg for en A/B-test? Det finnes ikke noe universelt tall. Det avhenger av den grunnleggende konverteringsraten, den minste effekten du ønsker å oppdage, og de valgte signifikans- og effektnivåene. En side som konverterer på 2.5 % trenger omtrent 64 000 besøkende per variant for å oppdage en relativ forbedring på 10 %; et kassetrinn som konverterer på 40 % trenger omtrent 2,400 for den samme relative effekten.

Hva er en god minimum detekterbar effekt? Den laveste trafikken din kan støtte innenfor en rimelig tidsramme. Start med tilgjengelig trafikk og en målvarighet på to til fire uker, og finn deretter MDE-en som passer baklengs. Hvis den MDE-en er større enn endringen du tester sannsynlig kan produsere, må du designe testen på nytt.

Kan jeg stoppe en test tidlig hvis den tydeligvis vinner? Ikke med en standard test med fast horisont. Gjentatt kontroll og stopp ved det første signifikante resultatet blåser opp den falske positive raten til langt over 5 %. Hvis du trenger muligheten til å stoppe tidlig, bruk en metode som er laget for det – sekvensiell testing eller et Bayesiansk rammeverk – og bestem det før lansering, ikke underveis.

Hva om testen min når signifikans før utvalgsstørrelsen er nådd? Behandle det med mistenksomhet og fortsett å løpe til den planlagte slutten. Tidlig betydning i et vindu med lav effekt er nettopp det mønsteret som produserer oppblåste, ikke-reproduserbare vinnere.

Er 80 % strøm nok? Det er den konvensjonelle standarden og et rimelig utgangspunkt, men det betyr å akseptere en 20 % sjanse for å gå glipp av en reell effekt. For beslutninger med høy innsats – en ny utforming av kassen, en prisendring – er 90 % makt verdt den ekstra prøven. For lave kostnader, reversible endringer er 80 % greit.

Er du ikke sikker på om testprogrammet ditt gir reelle svar?

Hvis testloggen din er full av små gevinster som aldri dukker opp i topplinjen, ligger problemet vanligvis oppstrøms for analysen. Vi gjennomgår eksperimenteringsprogrammer og forteller deg tydelig hvor designet svikter.

Lær mer om CRO-tjenesten? 


Çağdaş Polat
Written by

Çağdaş Polat

Çağdaş Polat er medgründer av Switas, hvor han leder teknologi- og vekstrådgivning for merkevarer innen e-handel, reiseliv, helsevesen og offentlig sektor. Han er utdannet innen informatikk og har gått fra programvareutvikling til seniorroller innen markedsføring, produkt og strategi i løpet av det siste tiåret. Han gir nå råd til selskaper om CRO, analyse og bygging av vekstsystemer som holder mål.


Relaterte artikler

Switas sett på

Magnify: Skalering av influencer-markedsføring med Engin Yurtdakul

Sjekk ut vår casestudie om Microsoft Clarity

Vi fremhevet Microsoft Clarity som et produkt bygget med praktiske brukseksempler fra den virkelige verden i tankene, av ekte produktfolk som forstår utfordringene selskaper som Switas står overfor. Funksjoner som «raseriøse klikk» og JavaScript-feilsporing viste seg å være uvurderlige for å identifisere brukerfrustrasjoner og tekniske problemer, noe som muliggjorde målrettede forbedringer som direkte påvirket brukeropplevelsen og konverteringsfrekvensen.