En brandvarnare för dina experiment: Vi presenterar Optimizely's automatiska detektering av felaktiga provförhållanden

Optimizely Experiments automatiska SRM-detektering (Sample Ratio Mismatch) ger sinnesfrid för experimentering. Den minskar en användares exponeringstid för dåliga upplevelser genom att snabbt upptäcka försämringar av experimentet.

Denna försämring orsakas av oväntade obalanser av besökare till en variation i ett experiment. Viktigast av allt är att denna automatiska SRM-detektering ger produktchefer, marknadsförare, ingenjörer och experimentationsteam möjlighet att med tillförsikt lansera fler experiment.

Hur Optimizely Experiments statistikmotor och automatisk detektering av felmatchning av samplingsfrekvens fungerar tillsammans

Missmatchningen av urvalsförhållandet fungerar som dörrvakten vid dörren som har en mekanisk räknare, kontrollerar gästernas biljetter (användare) och berättar för dem vilket rum de får festa i.

Stats Engine är som festens drifta som alltid kontrollerar vibbarna (beteendet) hos gästerna när människor kommer in i rummet.

Om SRM gör sitt jobb rätt kan Stats Engine med säkerhet säga vilket festrum som är bättre och styra mer trafik till den vinnande varianten (det bättre partyt) tidigare.

Varför skulle jag vilja ha Optimizely One's SRM-detektering?

Det är lika viktigt att säkerställa att Optimizely One-användare vet att deras experimentresultat är pålitliga och har verktygen för att förstå vad en obalans kan betyda för deras resultat och hur man kan förhindra det.

Optimizely Experiment går längre genom att kombinera kraften i automatisk upptäckt av obalans hos besökare med en insiktsfull hälsoindikator för experimentet. Denna hälsoindikator för experimentet spelar dubbel roll genom att låta våra kunder veta när allt är bra och det inte finns någon obalans.

När det behövs insikter i rätt tid för att skydda dina affärsbeslut, levererar Optimizely också varningar i rätt tid som hjälper våra kunder att känna igen allvaret i, diagnostisera och återhämta sig från fel.

Varför ska jag bry mig om felmatchning av provförhållande (SRM)?

Precis som feber är ett symptom på många sjukdomar, är SRM ett symptom på en mängd olika datakvalitetsproblem. Om man ignorerar en SRM utan att känna till grundorsaken kan det leda till att en dålig funktion verkar vara bra och skickas ut till användarna, eller vice versa. Om du hittar ett experiment med en okänd källa till obalans i trafiken kan du stänga av det snabbt och minska sprängradien.

Vad är då kopplingen mellan en "missmatchning" och "provförhållande"?

När vi gör oss redo att lansera ett experiment tilldelar vi en trafikdelning av användare för Optimizely One att distribuera till varje variation. Vi förväntar oss att den tilldelade trafikfördelningen rimligen ska matcha den faktiska trafikfördelningen i ett live experiment. Ett experiment utsätts för en SRM-obalans när det finns en statistiskt signifikant skillnad mellan den förväntade och den faktiska tilldelade trafikfördelningen av besökare till ett experiments variationer.

1. En missmatchning betyder inte en ofullständig matchning

Kom ihåg detta: En bonifierad obalans kräver ett statistiskt signifikant resultat av skillnaden i besökare. Förvänta dig inte en perfekt, identisk, exakt matchning av lanseringsdagens trafikdelning med din trafikdelning i produktionen. Det kommer alltid att finnas någon liten avvikelse.

Inte varje trafikskillnad innebär automatiskt att ett experiment är värdelöst. Eftersom Optimizely värdesätter våra kunders tid och energi, utvecklade vi ett nytt statistiskt test som kontinuerligt övervakar resultaten av experiment och upptäcker skadliga SRM så tidigt som möjligt. Allt medan vi fortfarande kontrollerar för att inte gråta varg över falska positiva resultat (AKA när vi drar slutsatsen att det finns en överraskande skillnad mellan en testvariation och baslinjen när det inte finns någon verklig skillnad).

2. Att gå under huven på Optimizely Experiments SRM-detekteringsalgoritm

Optimizely Experiments automatiska SRM-detekteringsfunktion använder ett sekventiellt Bayesian multinomial test(säg det 5 gånger snabbt!), Som heter sekventiell sample ratio mismatch. Optimizely statistikerna Michael Lindon och Alen Malek var pionjärer inom denna metod, och det är ett nytt bidrag till området sekventiell statistik. Optimizely Ones detektering av felmatchning av urvalsförhållande harmoniserar sekventiella och Bayesianska metoder genom att kontinuerligt kontrollera trafikräkningar och testa för någon betydande obalans i en variations besöksantal. Algoritmens konstruktion är Bayesian-inspirerad för att ta hänsyn till ett experiments valfria stopp och fortsättning samtidigt som den levererar sekventiella garantier för typ-I-felsannolikheter.

3. Akta dig för chi-eap-alternativ!

De mest populära fritt tillgängliga SRM-kalkylatorerna använder chi-två-testet. Vi rekommenderar starkt en noggrann genomgång av mekaniken i chi-två-testning. Huvudproblemet med chi-tvåmetoden är att problem upptäcks först efter att alla data har samlats in. Detta är utan tvekan alldeles för sent och går stick i stäv med varför de flesta kunder vill ha SRM-återhållsamhet från första början. I vårt blogginlägg "A better way to test for sample ratio mismatches (or why I don't use a chi-squared test)" går vi djupare in på chi-kvadratmekaniken och hur det vi byggt står för de luckor som alternativen lämnat efter sig.

Vanliga orsaker till en SRM

1. Omdirigeringar och fördröjningar

En SRM beror vanligtvis på att vissa besökare stänger av och lämnar sidan innan omdirigeringen är klar. Eftersom vi bara skickar beslutshändelserna när de anländer till sidan och Optimizely Experiment laddas, kan vi inte räkna dessa besökare på vår resultatsida om de inte återvänder vid någon tidpunkt och skickar en händelse till Optimizely Experiment.

En SRM kan uppstå vid allt som skulle kunna orsaka att Optimizely Ones händelseanrop försenas eller inte avfyras, till exempel ändringar i variationskoden. Det inträffar också när omdirigeringsexperiment skyttlar besökare till en annan domän. Denna händelse förvärras av långsamma anslutningstider.

2. Tvinga fram bucketing

Om en användare först blir bortvald i experimentet och det beslutet sedan används för att tvinga bort dem i ett efterföljande experiment, kommer resultaten av det efterföljande experimentet att bli obalanserade.

Här är ett exempel:

Variation A ger en helt annan användarupplevelse än variation B.

Besökare som hamnar i Variation A har en fantastisk upplevelse, och många av dem fortsätter att logga in och hamnar i det efterföljande experimentet där de tvångskopplas till Variation A.

Men besökarna som hamnade i Variation B har ingen bra upplevelse. Endast ett fåtal användare loggar in och landar i ett efterföljande experiment där de kommer att tvångsbucketas till Variation B.

Nu har du många fler besökare i Variation A än i Variation B.

3. Webbplatsen har sina egna omdirigeringar

Vissa webbplatser har egna omdirigeringar (t.ex. 301) som i kombination med våra omdirigeringar kan leda till att en besökare landar på en sida utan snippet. Detta gör att väntande beslutshändelser låses i localStorage och Optimizely One tar aldrig emot eller räknar dem.

4. API-anrop för Hold/send-händelser ligger utanför utdraget

Vissa användare inkluderar hold/send-händelser i projekt-JS. Men andra inkluderar dem i andra skript på sidan, t.ex. i leverantörspaket eller spårskript för analys. Det här är ytterligare ett skript som måste laddas korrekt för att besluten ska utlösas på rätt sätt. Implementerings- eller laddningshastigheter kan variera mellan olika varianter, särskilt när det gäller omdirigeringar.

Är duintresserad ?

Om du redan är en Optimizely Experiment-kund och vill lära dig mer om hur automatisk SRM-detektering gynnar dina A/B-testningar, kolla in vår kunskapsbasdokumentation:

• Optimizely Experiments automatiska SRM-detektering (Sample Ratio Mismatch) upptäcker eventuella försämringar av experimentet tidigt
• Obalans upptäcks:Vad du ska göra om Optimizely Ones automatiska SRM-detektering varnar dig för en obalans.

För ytterligare information kan du alltid kontakta din kundansvarige, men ta dig tid att granska vår dokumentation först!

Om du inte är kund kan du komma igång med oss här!

Och om du vill gräva djupare i den motor som driver Optimizely experimentering kan du kolla in vår sida snabbare beslut du kan lita på för digital experimentering.