Mismatch i stikprøveforhold (SRM)

Uoverensstemmelse i stikprøveforholdet, almindeligvis forkortet SRM, opstår, når den faktiske fordeling af trafik mellem eksperimentvarianter afviger fra den tilsigtede fordeling med mere end tilfældig variation kan forklare. En test konfigureret til en lige 50/50-deling, der leverer 51,200 besøgende til kontrolgruppen og 48,800 til varianten, har ikke blot været uheldig; ved det volumen er et gab af den størrelse statistisk usandsynligt under korrekt randomisering. SRM detekteres med en chi-i-anden-test mod den forventede allokering, og enhver test, der viser det, bør behandles som ugyldig, indtil årsagen er fundet.

SRM er vigtig, fordi den signalerer, at de to grupper ikke længere er sammenlignelige. Hele logikken i et kontrolleret eksperiment hviler på tilfældig tildeling, der producerer grupper, der kun adskiller sig i den anvendte behandling. Hvis en systematisk proces omdirigerer bestemte besøgende til én gruppe eller fjerner besøgende fra én gruppe, før de tælles med, kan enhver observeret forskel i konvertering afspejle denne proces snarere end den ændring, der testes. Det rapporterede resultat er ikke blot upræcist; det måler noget andet end det, teamet mener, det måler.

Årsagerne er næsten altid tekniske snarere end statistiske. Langsom indlæsning af variantkode får besøgende til at forlade siden, før de tælles, hvilket systematisk fjerner de mindst tålmodige brugere fra én gruppe. Omdirigeringsbaserede tests mister trafik under omdirigeringen, og tabet er ikke jævnt fordelt på tværs af enheder eller forbindelseshastigheder. Botfiltrering, der anvendes inkonsekvent på tværs af varianter, cachelag, der serverer én version uforholdsmæssigt, sporing af kald, der udløses, før gengivelse fuldføres i én variant, men efter i den anden, og interaktioner mellem samtidigt kørende eksperimenter producerer alle SRM. Hver af disse er en reel fejl, der ville ødelægge resultaterne, uanset om nogen tjekkede forholdet eller ej.

Den passende reaktion er at stoppe testen, diagnosticere årsagen, udbedre den og genstarte forfra. Forsøg på at redde en SRM-påvirket test ved at omvægte grupperne eller ved at analysere en delmængde er sjældent forsvarlige, fordi den manglende eller fejlallokerede trafik ikke mangler tilfældigt. Instinktet til at redde en test, der allerede har optaget tre ugers trafik, er stærkt, især når den ser ud til at vise en sejr, men et resultat fra en brudt randomisering har ingen bevisværdi, og det er værre at teste på baggrund af én test end slet ikke at teste.

Fordi SRM er usynlig, medmindre nogen leder efter det, skal kontrollen automatiseres. Modne programmer kører en SRM-test på hvert eksperiment som en del af standardanalysepipelinen, markerer enhver afvigelse ud over en streng tærskel og nægter at offentliggøre resultater, før markeringen er fjernet. Retrospektive revisioner af tidligere eksperimenter finder ofte en betydelig andel af historiske tests berørt, hvilket er en af ​​de mere ubehagelige opdagelser, et testprogram kan gøre, og en af ​​de mest værdifulde, fordi det forklarer, hvorfor visse tidligere sejre aldrig materialiserede sig i forretningsresultaterne.

Undersøgelse af en ubalance er en systematisk proces snarere end en jagt. Det første trin er at kontrollere, om ubalancen er til stede i testværktøjets egne tildelingsregistreringer eller kun i analyseplatformens, hvilket adskiller et randomiseringsproblem fra et sporingsproblem. Det andet er at segmentere forholdet efter enhed, browser, geografi og trafikkilde, da årsagen ofte påvirker én gruppe uforholdsmæssigt meget, og det segment, der viser den største afvigelse, normalt peger direkte på mekanismen. Det tredje er at kontrollere timingen, da et forhold, der var korrekt i starten og senere afveg, ofte indikerer en implementering, en ændring i cachelagring eller et tredjepartsscript, der introduceres midt i testen. Dokumentation af hver undersøgelse opbygger et katalog over tilbagevendende årsager, og de fleste organisationer finder de samme to eller tre mekanismer ansvarlige for størstedelen af ​​deres hændelser.

Introduktion af automatisk SRM-kontrol er normalt en af ​​de tidligste tekniske anbefalinger i en CRO-tjeneste engagement, fordi det koster meget lidt at implementere og øjeblikkeligt øger pålideligheden af ​​alt, hvad programmet producerer bagefter. Hvor SRM kan spores tilbage til variantgengivelsesforsinkelse eller omdirigeringslatens, ligger løsningen hos web ydeevne arbejde snarere end med selve testværktøjet, og at løse det underliggende hastighedsproblem har en tendens til at forbedre både validiteten af ​​eksperimenterne og den konverteringsrate, de måler.