Steekproefverhoudingsverschil (SRM)

Een mismatch in de steekproefverhouding, vaak afgekort als SRM, treedt op wanneer de werkelijke verdeling van het verkeer tussen de experimentele varianten meer afwijkt van de beoogde verdeling dan door willekeurige variatie kan worden verklaard. Een test die is geconfigureerd voor een gelijke verdeling van 50/50 en die 51,200 bezoekers naar de controlevariant en 48,800 naar de variant stuurt, is niet zomaar pech; bij dat volume is een verschil van die omvang statistisch onwaarschijnlijk bij een correcte randomisatie. SRM wordt gedetecteerd met een chi-kwadraat toets ten opzichte van de verwachte verdeling, en elke test die dit aantoont, moet als ongeldig worden beschouwd totdat de oorzaak is gevonden.

SRM is belangrijk omdat het aangeeft dat de twee groepen niet langer vergelijkbaar zijn. De hele logica van een gecontroleerd experiment berust op willekeurige toewijzing, waarbij groepen ontstaan ​​die alleen verschillen in de toegepaste behandeling. Als een systematisch proces bepaalde bezoekers naar de ene groep leidt, of bezoekers uit een groep verwijdert voordat ze geteld worden, dan kan elk waargenomen verschil in conversie dat proces weerspiegelen in plaats van de verandering die getest wordt. Het gerapporteerde resultaat is niet alleen onnauwkeurig; het meet iets anders dan wat het team denkt te meten.

De oorzaken zijn vrijwel altijd technisch in plaats van statistisch. Code voor varianten die traag laden, zorgt ervoor dat bezoekers vertrekken voordat ze worden meegeteld, waardoor systematisch de minst geduldige gebruikers uit een groep worden verwijderd. Tests op basis van redirects verliezen verkeer tijdens de redirect, en dit verlies is niet gelijkmatig verdeeld over apparaten of verbindingssnelheden. Botfiltering die inconsistent wordt toegepast op varianten, cachinglagen die één versie onevenredig veel bedienen, tracking calls die worden uitgevoerd voordat de rendering is voltooid in de ene variant, maar erna in de andere, en interacties tussen gelijktijdig uitgevoerde experimenten leiden allemaal tot SRM (Subject Rate Management). Elk van deze problemen is een reëel defect dat de resultaten zou vertekenen, ongeacht of iemand de ratio controleert.

De juiste reactie is om de test te stoppen, de oorzaak vast te stellen, deze te verhelpen en helemaal opnieuw te beginnen. Pogingen om een ​​door SRM beïnvloede test te redden door de groepen opnieuw te wegen of een subset te analyseren, zijn zelden te verdedigen, omdat het ontbrekende of verkeerd toegewezen verkeer niet willekeurig ontbreekt. De neiging om een ​​test te redden die al drie weken verkeer heeft verbruikt, is groot, vooral wanneer deze een positief resultaat lijkt te laten zien, maar een resultaat van een mislukte randomisatie heeft geen bewijswaarde en het uitbrengen van een test op basis daarvan is erger dan helemaal niet testen.

Omdat SRM onzichtbaar is tenzij iemand ernaar zoekt, moet de controle geautomatiseerd worden. Volwassen programma's voeren een SRM-test uit op elk experiment als onderdeel van de standaard analysepipeline, signaleren elke afwijking boven een strikte drempel en weigeren resultaten te publiceren totdat de signalering is opgeheven. Retrospectieve audits van eerdere experimenten tonen vaak aan dat een aanzienlijk deel van de historische tests is getroffen. Dit is een van de meest ongemakkelijke ontdekkingen die een testprogramma kan doen, maar tegelijkertijd ook een van de meest waardevolle, omdat het verklaart waarom bepaalde successen uit het verleden zich niet in de bedrijfsresultaten hebben vertaald.

Het onderzoeken van een discrepantie is een systematisch proces, geen zoektocht. De eerste stap is controleren of de onevenwichtigheid aanwezig is in de toewijzingsgegevens van de testtool zelf, of alleen in die van het analyseplatform. Dit onderscheidt een randomisatieprobleem van een trackingprobleem. De tweede stap is het segmenteren van de verhouding per apparaat, browser, geografische locatie en verkeersbron, aangezien de oorzaak vaak één groep onevenredig treft en het segment met de grootste afwijking meestal direct wijst op het onderliggende mechanisme. De derde stap is het controleren van de timing, omdat een verhouding die aanvankelijk correct was en later afweek, vaak duidt op een implementatie, een wijziging in de caching of een script van derden dat halverwege de test is geïntroduceerd. Het documenteren van elk onderzoek levert een catalogus op van terugkerende oorzaken, en de meeste organisaties vinden dezelfde twee of drie mechanismen verantwoordelijk voor de meerderheid van hun incidenten.

Het invoeren van een automatische SRM-controle is doorgaans een van de eerste technische aanbevelingen in een CRO-service betrokkenheid, omdat de implementatie ervan zeer weinig kost en de betrouwbaarheid van alles wat het programma daarna produceert direct verhoogt. Waar SRM terug te voeren is op vertraging in de weergave van varianten of omleidingslatentie, ligt de oplossing bij webprestaties Het probleem zit hem in het werk zelf, en niet in de testtool, maar in het oplossen ervan. Door het onderliggende snelheidsprobleem aan te pakken, worden zowel de validiteit van de experimenten als de conversieratio die ze meten verbeterd.