Otoskoko

Otoksen koko on kokeilun kuhunkin ryhmään sisältyvien kävijöiden, istuntojen tai käyttäjien lukumäärä, ja se on tärkein yksittäinen tekijä, joka määrää, voiko testi tuottaa luotettavan vastauksen. Se lasketaan ennen testin käynnistämistä neljän syötteen perusteella: kontrolliryhmän lähtötason konversioaste, yrityksen merkitykselliseksi katsoma pienin vaikutuskoko, haluttu tilastollinen teho ja merkitsevyystaso. Jos mitä tahansa näistä syötteistä muutetaan, vaadittu otoksen koko muuttuu, usein dramaattisesti.

Näiden syötteiden välinen suhde ei ole intuitiivinen, ja tässä kohtaa useimmat testausohjelmat menevät pieleen. Pienen vaikutuksen havaitseminen vaatii paljon enemmän liikennettä kuin suuren, ja vaatimus kasvaa suunnilleen vaikutuksen koon käänteisen neliön mukaisesti. Havaittavan vaikutuksen puolittaminen nelinkertaistaa tarvittavan liikenteen. Sivusto, joka konvertoi 2 prosentilla ja haluaa luotettavasti havaita 5 prosentin suhteellisen parannuksen, tarvitsee kymmeniä tuhansia kävijöitä varianttia kohden; sama sivusto, joka yrittää havaita 20 prosentin parannuksen, tarvitsee vain pienen osan tästä. Vastaavasti matalat lähtötason konversioasteet vaativat enemmän liikennettä kuin korkeat, minkä vuoksi liidien luontisivustot ja korkean harkinnan verkkokauppakategoriat suorittavat hitaampia testausohjelmia kuin korkean frekvenssin vähittäiskauppa.

Testin suorittaminen ilman otoskoon laskentaa tuottaa yhden kahdesta epäonnistumistavasta. Tehottomassa testissä ei koskaan päästä johtopäätökseen, se kuluttaa viikkoja liikennettä ja se hylätään epäselvänä tai, mikä pahempaa, sitä pidetään todisteena siitä, että muutos ei tehnyt mitään. Testi keskeytettiin aikaisin, kun onnekas konversiosarja ylitti merkitsevyyskynnyksen, ja se raportoi suuren vaikutuksen, joka enimmäkseen häviää, kun muutos otetaan käyttöön kaikille. Molemmat epäonnistumiset maksavat saman asian: testausohjelman uskottavuuden organisaation sisällä.

Myös otoskokovaatimukset rajoittavat sitä, mitä sivusto voi realistisesti testata. Rajallisen liikenteen omaava sivusto ei voi suorittaa pienten tarkennusten portfoliota, koska jokaisen ratkaiseminen veisi kuukausia. Sopiva strategia tällä liikennetasolla on testata vähemmän, rohkeampia muutoksia, joilla on suuret odotetut vaikutukset, testata ylempänä suppilossa, jossa volyymit ovat suuremmat, ja nojata vahvemmin laadulliseen tutkimukseen ja heuristiseen analyysiin sen päättämiseksi, mitä toimitetaan ilman kokeilua. Tämän rajoitteen rehellinen tunnustaminen on paljon tuottavampaa kuin sellaisen testiohjelman suorittaminen, joka matemaattisesti ei voi onnistua.

Käytännön laskennassa on myös otettava huomioon tilastollisen yksikön ja liiketoimintayksikön välinen ero. Jos satunnaistamisyksikkö on kävijä, mutta mittari mitataan istuntoa kohden, aritmeettiset tulokset eivät toimi ja raportoitu luottamustaso on liioiteltu. Testit, jotka mittaavat tuottoa kävijää kohden binäärisen konversiomallin sijaan, tarvitsevat vielä suurempia otoksia, koska tuotto on suuren varianssin mittari, jolla on pitkä häntä suuria tilauksia. Segmenttitason analyysi pahentaa ongelmaa: koko yleisölle suunnattu testi ei sovellu mobiiliosajoukolle, ja segmenttitulosten lukeminen koko yleisölle mitoitetusta kokeesta on yksi yleisimmistä väärien johtopäätösten lähteistä kentällä.

Laskelmasta seuraa kaksi käytännön kysymystä, joihin usein vastataan väärin. Ensimmäinen on, pitäisikö liikenne jakaa tasaisesti. Epätasaista allokaatiota, kuten 90 prosenttia kontrollia ja 10 prosenttia varianttia, ehdotetaan joskus altistumisen rajoittamiseksi riskialttiille muutokselle, mutta se pidentää vaadittua suoritusaikaa huomattavasti, koska pienempi ryhmä määrää vertailun tarkkuuden. Riskiä voidaan rajoittaa paremmin lyhyellä alkuvaiheella ja kaiteen seurannalla, jota seuraa tasainen jako. Toinen on, mitä tehdä useiden testien suorittamiselle kerralla. Samanaikaiset kokeet sivuston toisiinsa liittymättömillä osilla ovat yleensä hyväksyttäviä, ja useimmat ohjelmat saavuttavat kohtuullisen nopeuden juuri niiden avulla, mutta vuorovaikutuksessa olevat testit, kuten kaksi samaan suppilovaiheeseen vaikuttavaa muutosta, on joko järjestettävä tai analysoitava yhdistettynä suunnitteluna, koska molempia kokevia kävijöitä ei voida selkeästi selittää kummallakaan.

Rakenteisen muuntokurssin optimointi ohjelmassa otoskoon suunnittelu tapahtuu priorisoinnin aikana, ei julkaisun yhteydessä. Tieto siitä, että ehdotettu testi tarvitsee kuuden viikon liikenteen, muuttaa sen prioriteettia suhteessa ideaan, joka ratkeaa kymmenessä päivässä, ja tämä kompromissi odotetun vaikutuksen ja vastausajan välillä on yksi etenemissuunnitelman keskeisistä lähtökohdista. Vähäliikenteisillä sivustoilla a UX-tarkastus tuottaa usein paremman tuoton kuin kokeilujono, koska se tunnistaa niin vakavia vikoja, että niiden korjaaminen ei vaadi tilastollista näyttöä.