Näytteen suhdevirhe (SRM)

Otossuhteen epäsuhta, yleisesti lyhennettynä SRM, tapahtuu, kun liikenteen todellinen jakautuminen kokeiluvarianttien välillä eroaa tarkoitetusta jakautumisesta enemmän kuin satunnaisvaihtelu pystyy selittämään. Tasaiselle 50/50-jaolle konfiguroitu testi, joka tuottaa 51 200 kävijää kontrolliryhmään ja 48 800 varianttiin, ei ole ollut vain epäonninen; tuolla volyymilla tuon kokoinen ero on tilastollisesti epätodennäköinen oikean satunnaistamisen vallitessa. SRM havaitaan khiin neliö -testillä odotettua allokaatiota vastaan, ja kaikkia testejä, jotka osoittavat sen, tulisi käsitellä virheellisinä, kunnes syy löytyy.

Yksilöllinen konversiomittari (SRM) on tärkeä, koska se viestii, että nämä kaksi ryhmää eivät ole enää vertailukelpoisia. Kontrolloidun kokeen koko logiikka perustuu satunnaiseen määritysmenetelmään, joka tuottaa ryhmiä, jotka eroavat toisistaan ​​vain sovelletun käsittelyn suhteen. Jos jokin systemaattinen prosessi ohjaa tiettyjä kävijöitä yhteen ryhmään tai poistaa kävijöitä ryhmästä ennen kuin heidät on laskettu, havaittu konversioero voi heijastaa kyseistä prosessia eikä testattavaa muutosta. Raportoitu tulos ei ole pelkästään epätarkka; se mittaa jotain muuta kuin mitä tiimi uskoo mittaavansa.

Syyt ovat lähes aina teknisiä eivätkä tilastollisia. Hitaasti latautuva varianttikoodi saa kävijät poistumaan ennen kuin ne lasketaan, jolloin vähiten kärsivälliset käyttäjät poistetaan järjestelmällisesti yhdestä ryhmästä. Uudelleenohjaukseen perustuvat testit menettävät liikennettä uudelleenohjauksen aikana, eikä tappio jakaudu tasaisesti laitteiden tai yhteysnopeuksien välillä. Bottien suodatuksen epäjohdonmukainen soveltaminen eri varianttien välillä, yhtä versiota palvelevien kerrosten suhteeton välimuistiin tallentaminen, ennen renderöinnin valmistumista yhdessä variantissa ja sen jälkeen käynnistyvien kutsujen seuranta toisessa variantissa sekä samanaikaisesti käynnissä olevien kokeiden väliset vuorovaikutukset tuottavat kaikki SRM:ää. Jokainen näistä on todellinen vika, joka vääristäisi tuloksia riippumatta siitä, onko kukaan tarkistanut suhdetta vai ei.

Asianmukainen vastaus on pysäyttää testi, diagnosoida syy, korjata se ja aloittaa uudelleen nollasta. Yritykset pelastaa SRM:n vaikutuksen alaisena oleva testi painottamalla ryhmiä uudelleen tai analysoimalla osajoukkoa ovat harvoin puolustettavissa, koska puuttuva tai väärin allokoitu liikenne ei puutu satunnaisesti. Vaisto pelastaa testi, joka on jo kuluttanut kolmen viikon liikennea, on voimakas, varsinkin kun se näyttää osoittavan voittoa, mutta rikkinäisen satunnaistamisen tuloksella ei ole todistusarvoa ja lähettäminen yhden perusteella on pahempaa kuin testaamatta jättäminen ollenkaan.

Koska SRM on näkymätön, ellei joku etsi sitä, tarkistus on automatisoitava. Ammattitaitoiset ohjelmat suorittavat SRM-testin jokaiselle kokeelle osana vakioanalyysiputkea, merkitsevät kaikki tiukan kynnysarvon ylittävät poikkeamat ja kieltäytyvät julkaisemasta tuloksia, ennen kuin merkintä on poistettu. Aikaisempien kokeiden retrospektiivisissä tarkastuksissa havaitaan usein merkittävä osa historiallisista testeistä, jotka ovat vaurioituneet. Tämä on yksi epämukavimmista löydöksistä, joita testausohjelma voi tehdä, ja yksi arvokkaimmista, koska se selittää, miksi tietyt aiemmat voitot eivät koskaan toteutuneet liiketoiminnan tuloksissa.

Epätasapainon tutkiminen on systemaattinen prosessi eikä pelkkä metsästys. Ensimmäinen vaihe on tarkistaa, onko epätasapaino testaustyökalun omissa tehtävätietueissa vai vain analytiikka-alustan tietueissa, mikä erottaa satunnaistamisongelman seurantaongelmasta. Toinen vaihe on suhdeluvun segmentointi laitteen, selaimen, maantieteellisen sijainnin ja liikenteen lähteen mukaan, koska syy vaikuttaa usein suhteettomasti yhteen ryhmään ja suurinta poikkeamaa osoittava segmentti osoittaa yleensä suoraan mekanismiin. Kolmas vaihe on ajoituksen tarkistaminen, koska aluksi oikea ja myöhemmin muuttunut suhdeluku viittaa usein käyttöönottoon, välimuistin muutokseen tai kolmannen osapuolen komentosarjan lisäämiseen testin aikana. Jokaisen tutkimuksen dokumentointi luo luettelon toistuvista syistä, ja useimmat organisaatiot löytävät samat kaksi tai kolme mekanismia, jotka ovat vastuussa suurimmasta osasta tapauksiaan.

Automaattisen SRM-tarkistuksen käyttöönotto on yleensä yksi varhaisimmista teknisistä suosituksista. CRO-palvelu sitoutumista, koska sen toteuttaminen maksaa hyvin vähän ja se parantaa välittömästi kaiken ohjelman tuottaman luotettavuutta. Jos SRM jäljittää varianttien renderöintiviiveeseen tai uudelleenohjauksen latenssiin, ratkaisu on verkkosuorituskyky työskentelyä pikemminkin kuin itse testaustyökalua, ja taustalla olevan nopeusongelman korjaaminen yleensä parantaa sekä kokeiden validiteettia että niiden mittaamaa konversioprosenttia.