Diagnostiser en avvik i utvalgsforholdet i fem grener før du kaster testen

Diagnostiser en avvik i utvalgsforholdet i fem grener før du kaster testen

Omtrent 6 % av eksperimentene hos Microsoft viser et uoverensstemmelse mellom utvalgsforholdet, noe som i et produkt som kjører 10 000 eksperimenter i året tilsvarer omtrent én deteksjon per dag (Fabijan et al., KDD 2019). Team som kjører langt færre tester ser sjelden det tallet, fordi sjekken plattformen deres kjører ikke kan oppnå signifikant verdi med trafikkvolumet. Testen ser ren ut, rapporterer en økning på 4 %, og er uansett feil.

Denne veiledningen er for personen som leser avlesningen av eksperimentet og må bestemme seg for om den skal sendes. Til slutt vil du kunne finne ut om testen din er stor nok til at avvikssjekken har noe å si, kjøre fem diagnosegrener i den rekkefølgen som finner årsaken raskest, og skille en ubalanse som annullerer avlesningen fra en du kan segmentere rundt og beholde.

Hva en SRM-alarm faktisk forteller deg

Et avvik i utvalgsforholdet er et gap mellom delingen du konfigurerte og delingen du observerer: du satte 50/50 og fikk 50.8/49.2. Standardkontrollen er Pearsons kji-kvadrat-goodness-of-fit-test på eksponeringstallene, én frihetsgrad for en toarmet test.

Det er viktig fordi mekanismen som forårsaket tap av brukere nesten aldri er nøytral i forhold til målingen din. Hvis en omdirigering fjerner trege forbindelser fra varianten, er det de som overlever de som har bedre forbindelser, og de konverterer bedre. Økningen er reell i dataene og fraværende i virkeligheten.

Her er det første de fleste team tar feil av: det finnes ingen bransjeterskel. Plattformene er mer enn en størrelsesorden uenige.

PlattformTestFlagg kl.Merknader
AB VelsmakendeSekvensiell frekventist (S-SRM)p <0.01Bygget for kontinuerlig overvåking, slik at gjentatte sjekk tas med i betraktningen
StatsigChi-kvadratp <0.01«Vi anser eksponeringer som ubalanserte hvis SRM p-verdien er under 0.01»
VekstbokChi-kvadratp <0.001Advarselen er undertrykt over det
Microsoft (utarbeidet illustrasjon)Chi-kvadrat~1 i 139 838 160En splitt på 50.2/49.8 ved stor n fjerner allerede dette

To konsekvenser. En test som er flagget på én plattform, består en annen med identiske data, så «verktøyet vårt advarte oss ikke» er ikke bevis på en ren splittelse. Og en terskel på 0.01 flagger én av hundre friske tester. Hvis du ser på p-verdien daglig over en tre ukers test, er den naive uavhengige kikkgrensen for en falsk alarm 19 %; det sanne tallet er lavere fordi påfølgende dager er sterkt korrelert, men det er ikke 1 %. Det er derfor AB Tasty kjører en sekvensiell prosedyre. Hvis plattformen din kjører en kji-kvadrat med fast horisont, se én gang, på slutten, på kumulative tellinger.

Sjekk om testen din i det hele tatt kan oppdage en ubalanse

For en 50/50-deling forenkles kji-kvadratstatistikken til 4n(p̂−0.5)², hvor n er totale eksponeringer. Inverter den, og du får den minste ubalansen sjekken din kan flagge:

Totale eksponeringerMinste flaggede splitt ved p < 0.01ved p < 0.001
5,00051.8 / 48.252.3 / 47.7
10,00051.3 / 48.751.6 / 48.4
30,00050.7 / 49.351.0 / 49.0
100,00050.4 / 49.650.5 / 49.5
1,000,00050.13 / 49.8750.16 / 49.84

Les det som en grense, ikke en lisens. Ved 10 000 eksponeringer er alt mindre enn en ubalanse på 1.3 poeng usynlig for sjekken, og en seleksjonseffekt på 1.3 poeng er mer enn nok til å produsere en liten konverteringsøkning. Det er det strukturelle problemet i mesteparten av regionen. Tyrkia registrerte omtrent 6 milliarder e-handelstransaksjoner på tvers av omtrent 634 000 bedrifter i 2025 (Handelsdepartementet, 12. mai 2026), et gjennomsnitt på nærmere 9,500 i året hver, og det gjennomsnittet trekkes kraftig opp av en håndfull markedsplasser. En mellomstor butikk som tester et kassetrinn, jobber med titusenvis av eksponeringer, ikke millioner, så SRM-sjekken fanger opp grove brudd og ingenting mer subtilt.

Ikke stol på alarmen ved det volumet. Hent rå eksponeringstall per dag og per segment selv, og behandle en vedvarende drift i samme retning som mistenkelig selv når p-verdien er umerkelig. Hvis du ikke er sikker på hvor plattformen din eksponerer disse tallene, vil SRM Checker-dokumentasjon kartlegger dem per verktøy.

De fem grenene, i den rekkefølgen som finner årsaken raskest

KDD-taksonomien sorterer SRM-årsaker etter livssyklusfase: tildeling, utførelse, loggbehandling, analyse, interferens. Diagnostiser dem i en annen rekkefølge, billigst og vanligst først.

  1. Analyse og utløsning. Symptom: Delingen er ren i den rå eksponeringsloggen og ødelagt i scorekortet. Kontroll: Beregn forholdet på nytt uten utløserbetingelsen, datofilteret og koblinger på metrisk nivå. Bekrefter det hvis forholdet går tilbake til forventningene. Fiks: Evaluer utløsningen identisk i begge armer, før noen variantspesifikk oppførsel kan endre kvalifiseringen. Vanligste falske alarm, ti minutter for å utelukke.
  2. Loggbehandling. Symptom: Eksponeringstallene varierer mellom to pipelines, eller gapet vises etter ETL-trinnet. Sjekk: Sammenlign SDK-sidens antall, lagerantallet og rapporteringstallet for samme vindu, og sammenlign deretter botfilterekskluderingsrater per arm. Bekrefter det hvis armene er like oppstrøms og ulikt nedstrøms. Fiks: Filtrer deterministisk og identisk. Automatisert trafikk nådde 53 % av nettrafikken i 2026, opp fra 51 % i 2024 (Imperva Bad Bot-rapport, 29. april 2026), så et heuristisk filter som er tastet inn på lastetid eller brukeragent-atferd kan ekskludere med ulik hastighet per variant. Samtykkedrevet tap finnes også her: når ad_storage blir avvist, slutter Googles tagplattform å sette informasjonskapsler for annonsering (Samtykkedokumenter for Google Tag-plattformen), så hvis avslagsratene varierer på tvers av geografiske områder i én test, vil enhver oppgave som lener seg på disse identifikatorene føre til ujevn tap av brukere.
  3. Henrettelse. Symptom: Ubalansen øker med sidevekten, er verre på mobil, eller starter ved en utrulling. Sjekk: Del forholdet etter enhet, nettleser, tilkoblingstype og dag; sammenlign tid til eksponering mellom armene. Bekreft det hvis underskuddet konsentrerer seg om trege segmenter eller i én nettleser. Fiks: Det er her omdirigeringstester dør. En omdirigering legger til full navigasjon til bare én arm, og alle som forlater underveis er et selektivt tap. Gjengi begge variantene serverside på én URL, eller godta at armene ikke er sammenlignbare.
  4. Oppdrag. Symptom: forholdet er avvikende fra den første timen og forblir avvikende med en konstant faktor. Sjekk: kjør en A/A på samme allokering og bekreft at hash-saltet ikke ble gjenbrukt fra et tidligere eksperiment på denne populasjonen. Bekreft det hvis A/A også viser ubalansen. Fiks: tilordne på nytt med et nytt salt og start på nytt. Overføring fra en tidligere test er den stille versjonen av dette, og bare A/A eksponerer det.
  5. Innblanding. Symptom: Ubalansen er konsentrert i et lite antall identifikatorer med høy aktivitet, eller i interne IP-områder. Sjekk: fordelingen av eksponeringstall per bruker, og de øverste 1 % av identifikatorene etter hendelsesvolum. Bekrefter det hvis fjerning av dem gjenoppretter forholdet. Fiks: Ekskluder intern og skriptet trafikk etter dokumentert regel, ikke manuelt, slik at ekskluderingen er identisk neste gang.

En gjennomarbeidet gjennomgang

Tallene nedenfor er illustrerende, ikke klientdata. En utsjekkingstest rapporterer 61 480 kontroll- og 58 520 varianteksponeringer: 51.2/48.8 på 120 000 brukere, kji-kvadrat p under 0.001. Gren 1: utelatelse av utløserbetingelsen returnerer 60 020 / 59 980, så tildelingen er fin, og tapet skjer etter eksponering. Gren 2: pipeline-antall stemmer overens, bot-ekskluderinger 0.9 % i begge armer. Gren 3: datamaskin ligger på 50.1/49.9, mobil på 52.4/47.6, og variantens median tid til eksponering er 900 ms høyere på mobil. Diagnose: varianten sender en ekstra forespørsel om gjengivelsesblokkering, mobilbrukere forlater underveis, overlevende har bedre forbindelser. Avlesningen er ugyldig. Rettelsen er en ytelsesrettelse, og testen kjøres på nytt, ikke tolkes på nytt.

Hva du kan redde og hva du ikke kan

  • Annuller avlesningen når tapsmekanismen sannsynlig kunne korrelere med målestokken. Enhver utførelses- og tildelingsårsak kvalifiserer som standard.
  • Berging etter segment Bare når ubalansen er begrenset til et segment du kan ekskludere uten å måtte nøle, det segmentet ble definert før du så på målingen, og resten består sin egen SRM-sjekk. To av tre er ikke nok.
  • Behold testen når årsaken utelukkende var i analyse og det korrigerte scorekortet består. Du leser de samme dataene på nytt med et fast filter, ikke fisker.
  • Logg det uansett. Registrer årsakskategorien på eksperimentet. Taksonomien lønner seg kumulativt: hvis tre av de siste ti testene dine mislyktes i gren 3, er ikke problemet ditt eksperimentering, det er front-end-levering. [INTERNE DATA NØDVENDIG: andel Switas-kjørte eksperimenter de siste 24 månedene som ikke besto en SRM-sjekk, fordelt på taksonomigren, for å erstatte Microsofts 6%-referanseindeks med et tall fra dette markedet]

Hvor dette brytes ned

Dette treet forutsetter en toarmstest med en fast, kjent allokering og randomisering på brukernivå. Det dekker ikke flerarmstester, som trenger full kji-kvadrat på tvers av alle armer pluss en oppfølging av hvilket par som er feil, eller rampede allokeringer, der det forventede forholdet beveger seg under testen og en kumulativ kji-kvadrat er feil test. Det gjelder ikke for klynge- eller geo-randomiserte design, der enheten ikke er brukeren og ubalansen som betyr noe ligger i klyngekarakteristikkene. Det sier ingenting om hvorvidt metrikkdefinisjonen din er riktig. Og det kan ikke hjelpe når eksponeringer ikke logges og du utleder tildeling fra en metrisk hendelse, som ikke er en delt sjekk, men en gjetning.

FAQ

Er en 51/49-deling alltid et problem? Det avhenger helt av n. Ved 5,000 eksponeringer er det vanlig støy; ved 500 000 er det en nesten sikker defekt. Bedøm forholdet mot deteksjonstabellen, ikke mot en fast prosentregel.

Kan jeg bare vekte armene på nytt statistisk i stedet for å løpe på nytt? Nei. Omvekting korrigerer antallene og lar utvalget være intakt. Brukerne du mistet er borte, og de var ikke et tilfeldig utvalg av armen.

Hvor ofte bør jeg se på SRM p-verdien? En gang, på slutten, på kumulative tellinger, med mindre plattformen din kjører en sekvensiell prosedyre. Daglig kikking på en kji-kvadrat med fast horisont blåser opp falske alarmer betraktelig.

Ugyldiggjør SRM også autovernets målinger? Ja, av samme grunn. Hvis armene holder forskjellige populasjoner, er ikke et flatt autovern mer pålitelig enn en bevegelig primærmåling.

Hva om en A/A-test også viser et avvik? Da ligger feilen i tildelingen eller i loggføringen, ikke i behandlingen din. Fiks det før du kjører noe annet, fordi det forurenser alle tester på den plattformen.

Forårsaker omdirigeringstester alltid SRM? Ikke alltid, men de har en strukturell risiko som ingen andre design har, fordi den ekstra navigasjonen bare finnes i én arm. Hvis du må kjøre en, sjekk forholdet etter tilkoblingshastighet og enhet før du leser av noen målinger.

Trafikken min er for lav til at sjekken har noe å si. Hva da? Overvåk rådata for daglig eksponering for vedvarende avvik, kjør en periodisk A/A på tildelingslaget, og forhåndsregistrer en lengre liste med tilregnelighetskontroller. Du erstatter statistisk styrke med prosess.

Bør botfiltrering skje før eller etter tildeling? Etter eksponeringslogging, før analyse, brukes deterministiske regler som brukes identisk på begge armene. Heuristisk filtrering i SDK-et er hvordan selve filteret blir til avviket.

Kjør testen på ditt eget eksperimentprogram

Hvis du ønsker et ekstra blikk på den delte tilstanden til testene du kjører nå, eller en gjennomgang av tildelings- og logglaget de alle er avhengige av, er det det vår CRO og eksperimenteringstjeneste gjør.

Kilder


Relaterte artikler

Switas sett på

Magnify: Skalering av influencer-markedsføring med Engin Yurtdakul

Sjekk ut vår casestudie om Microsoft Clarity

Vi fremhevet Microsoft Clarity som et produkt bygget med praktiske brukseksempler fra den virkelige verden i tankene, av ekte produktfolk som forstår utfordringene selskaper som Switas står overfor. Funksjoner som «raseriøse klikk» og JavaScript-feilsporing viste seg å være uvurderlige for å identifisere brukerfrustrasjoner og tekniske problemer, noe som muliggjorde målrettede forbedringer som direkte påvirket brukeropplevelsen og konverteringsfrekvensen.