En røykvarsler for eksperimentene dine: Vi introduserer Optimizelys automatiske deteksjon av avvik i prøveforhold

Optimizely Experiments automatiske deteksjon av avvik i prøveforhold (SRM) gir eksperimenterende ro i sjelen. Den reduserer brukerens eksponeringstid for dårlige opplevelser ved raskt å oppdage enhver forringelse av et eksperiment.

Denne forringelsen skyldes uventede ubalanser i besøkende til en variant i et eksperiment. Aller viktigst er det at denne automatiske SRM-deteksjonen gir produktledere, markedsførere, ingeniører og eksperimenteringsteam mulighet til trygt å lansere flere eksperimenter. 

Avviket i prøveforhold fungerer som dørvakten som har en mekanisk teller, sjekker gjestenes billetter (brukere) og forteller dem hvilket rom de får feste i.

Stats engine er som vertskapet for festen som alltid sjekker stemningen (atferden) til gjestene etter hvert som folk kommer inn i rommet.

Hvis SRM gjør jobben sin riktig, kan stats engine trygt fastslå hvilket festrom som er best og lede mer trafikk til den vinnende varianten (den bedre festen) raskere.

Det er like viktig å sikre at brukere av Optimizely Experiment vet at eksperimentresultatene deres er til å stole på, og at de har verktøyene til å forstå hva en ubalanse kan bety for resultatene deres og hvordan de kan forhindre den.

På en unik måte går Optimizely Experiment lenger ved å kombinere kraften i automatisk deteksjon av ubalanse i besøkende med en innsiktsfull helseindikator for eksperimentet. Denne helseindikatoren for eksperimentet spiller en dobbel rolle ved å la kundene våre vite når alt er i orden og det ikke foreligger noen ubalanse.

Når det trengs innsikt akkurat i tide for å beskytte forretningsbeslutningene dine, leverer Optimizely også varsler akkurat i tide som hjelper kundene våre med å gjenkjenne alvorlighetsgraden av, diagnostisere og komme seg etter feil.

Akkurat som feber er et symptom på mange sykdommer, er en SRM et symptom på en rekke datakvalitetsproblemer. Å ignorere en SRM uten å kjenne den underliggende årsaken kan føre til at en dårlig funksjon fremstår som god og blir sendt ut til brukerne, eller omvendt. Å finne et eksperiment med en ukjent kilde til trafikkubalanse lar deg slå det av raskt og redusere skadeomfanget.

Når vi gjør oss klare til å lansere et eksperiment, tildeler vi en trafikkfordeling av brukere som Optimizely Experiment skal distribuere til hver variant. Vi forventer at den tildelte trafikkfordelingen i rimelig grad stemmer overens med den faktiske trafikkfordelingen i et live eksperiment. Et eksperiment er utsatt for en SRM-ubalanse når det er en statistisk signifikant forskjell mellom de forventede og de faktisk tildelte trafikkfordelingene av besøkende til et eksperiments varianter.

Husk: En reell ubalanse krever et statistisk signifikant resultat av forskjellen i besøkende. Ikke forvent en plettfri, identisk, eksakt match mellom lanseringsdagens trafikkfordeling og din trafikkfordeling i produksjon. Det vil alltid være et bitte lite avvik.

Ikke ethvert trafikkavvik betyr automatisk at et eksperiment er ubrukelig. Fordi Optimizely setter dypt pris på kundenes tid og energi, utviklet vi en ny statistisk test som kontinuerlig overvåker eksperimentresultatene og oppdager skadelige SRM-er så tidlig som mulig. Alt mens vi fortsatt kontrollerer for å rope ulv om falske positiver (det vil si når vi konkluderer med at det er en overraskende forskjell mellom en testvariant og baselinen når det egentlig ikke er noen reell forskjell). 

Optimizely Experiments automatiske SRM-deteksjonsfunksjon benytter en sekvensiell bayesiansk multinomisk test (si det fem ganger fort!), kalt sequential sample ratio mismatch. Optimizely-statistikerne Michael Lindon og Alen Malek var pionerer for denne metoden, og den er et nytt bidrag til feltet sekvensiell statistikk. Optimizely Experiments deteksjon av avvik i prøveforhold harmoniserer sekvensielle og bayesianske metodologier ved kontinuerlig å sjekke trafikktall og teste for enhver signifikant ubalanse i en variants antall besøkende. Algoritmens konstruksjon er bayesiansk inspirert for å ta høyde for et eksperiments valgfrie stopp og videreføring, samtidig som den leverer sekvensielle garantier for sannsynligheten for type I-feil.

De mest populære fritt tilgjengelige SRM-kalkulatorene benytter kjikvadrattesten. Vi anbefaler på det sterkeste en grundig gjennomgang av mekanikken i kjikvadrattesting. Hovedproblemet med kjikvadratmetoden er at problemer først oppdages etter at alle dataene er samlet inn. Dette er uten tvil altfor sent og strider mot hvorfor de fleste klienter ønsker SRM-deteksjon i utgangspunktet. I blogginnlegget vårt «A better way to test for sample ratio mismatches (or why I don’t use a chi-squared test)» går vi dypere inn i kjikvadratmekanikken og hvordan det vi har bygget tar høyde for hullene som alternativene etterlater seg.

En SRM skyldes vanligvis at noen besøkende lukker og forlater siden før omdirigeringen er ferdig utført. Fordi vi bare sender beslutningshendelsene når de ankommer siden og Optimizely Experiment lastes inn, kan vi ikke telle disse besøkende på resultatsiden vår med mindre de kommer tilbake på et tidspunkt og sender en hendelse til Optimizely Experiment.

En SRM kan oppstå ved alt som ville få Optimizely Experiments hendelseskall til å forsinkes eller ikke utløses, for eksempel endringer i variantkode. Det skjer også når omdirigeringseksperimenter sender besøkende til et annet domene. Denne forekomsten forsterkes av trege tilkoblingstider.

Hvis en bruker først blir plassert (bucketed) i eksperimentet og den beslutningen deretter brukes til å tvinge dem inn i en bestemt bøtte i et påfølgende eksperiment, vil resultatene av det påfølgende eksperimentet bli ubalansert.

Her er et eksempel:

Variant A gir en svært annerledes brukeropplevelse enn variant B.

Besøkende som plasseres i variant A, får en flott opplevelse, og mange av dem fortsetter å logge inn og havner i det påfølgende eksperimentet der de tvangsplasseres i variant A.

Men besøkende som ble plassert i variant B, har ikke en god opplevelse. Bare noen få brukere logger inn og havner i et påfølgende eksperiment der de blir tvangsplassert i variant B.

Vel, nå har du mange flere besøkende i variant A enn i variant B.

Noen nettsteder har sine egne omdirigeringer (for eksempel 301-er) som, kombinert med våre omdirigeringer, kan føre til at en besøkende havner på en side uten kodesnutten. Dette gjør at ventende beslutningshendelser låses i localStorage og Optimizely Experiment aldri mottar eller teller dem.

Noen brukere inkluderer hold/send-hendelser i prosjektets JS. Andre inkluderer det imidlertid i andre skript på siden, for eksempel i leverandørpakker eller skript for analysesporing. Dette utgjør enda et skript som må lastes inn riktig for at beslutningene skal utløses som de skal. Implementerings- eller innlastingsratene kan variere mellom varianter, særlig ved omdirigeringer.

Hvis du allerede er Optimizely Experiment-kunde og ønsker å lære mer om hvordan automatisk SRM-deteksjon kommer A/B-testene dine til gode, kan du ta en titt på dokumentasjonen i kunnskapsbasen vår:

For ytterligere detaljer kan du alltid ta kontakt med din customer success manager, men ta deg gjerne et øyeblikk til å gjennomgå dokumentasjonen vår først!

Hvis du ikke er kunde, kom i gang med oss her! 

Og hvis du vil grave dypere i motoren som driver Optimizely-eksperimentering, kan du ta en titt på siden vår raskere beslutninger du kan stole på for digital eksperimentering.