Discrepanza del rapporto di campionamento (SRM)

La discrepanza nel rapporto tra i campioni, comunemente abbreviata in SRM (Sample Ratio Mismatch), si verifica quando la ripartizione effettiva del traffico tra le varianti dell'esperimento differisce dalla ripartizione prevista di una quantità superiore a quella spiegabile dalla variazione casuale. Un test configurato per una divisione equa 50/50 che assegna 51,200 visitatori al gruppo di controllo e 48,800 al gruppo sperimentale non è stato semplicemente sfortunato; a quel volume, una differenza di tale entità è statisticamente implausibile con una corretta randomizzazione. L'SRM viene rilevato con un test del chi quadrato rispetto all'allocazione prevista e qualsiasi test che lo mostri deve essere considerato non valido finché non se ne individua la causa.

L'SRM è importante perché segnala che i due gruppi non sono più comparabili. L'intera logica di un esperimento controllato si basa sull'assegnazione casuale che produce gruppi che differiscono solo per il trattamento applicato. Se un processo sistematico sta indirizzando determinati visitatori verso un gruppo, o escludendo visitatori da un gruppo prima che vengano conteggiati, allora qualsiasi differenza osservata nel tasso di conversione potrebbe riflettere tale processo piuttosto che la variazione oggetto di studio. Il risultato riportato non è semplicemente impreciso; sta misurando qualcosa di diverso da ciò che il team crede di misurare.

Le cause sono quasi sempre di natura tecnica piuttosto che statistica. Il caricamento lento del codice delle varianti induce i visitatori ad abbandonare la pagina prima di essere conteggiati, escludendo sistematicamente gli utenti meno pazienti da un gruppo. I test basati su reindirizzamenti perdono traffico durante il reindirizzamento e la perdita non è distribuita uniformemente tra i dispositivi o le velocità di connessione. Il filtraggio dei bot applicato in modo incoerente tra le varianti, i livelli di caching che servono una versione in modo sproporzionato, le chiamate di tracciamento che si attivano prima del completamento del rendering in una variante ma dopo nell'altra, e le interazioni tra esperimenti in esecuzione simultanea, producono tutti SRM (Standardized Rate of Mark). Ognuno di questi è un difetto reale che comprometterebbe i risultati a prescindere dal fatto che qualcuno ne verificasse o meno il rapporto.

La risposta appropriata è interrompere il test, diagnosticare la causa, correggerla e ricominciare da capo. I tentativi di salvare un test influenzato da SRM riponderando i gruppi o analizzando un sottoinsieme sono raramente giustificabili, perché il traffico mancante o allocato in modo errato non è casuale. L'istinto di salvare un test che ha già consumato tre settimane di traffico è forte, soprattutto quando sembra dare un risultato positivo, ma un risultato derivante da una randomizzazione errata non ha alcun valore probatorio e rilasciare una versione basandosi su un singolo risultato è peggio che non testare affatto.

Poiché l'SRM è invisibile a meno che qualcuno non lo cerchi, il controllo deve essere automatizzato. I programmi maturi eseguono un test SRM su ogni esperimento come parte della pipeline di analisi standard, segnalano qualsiasi deviazione oltre una soglia rigorosa e si rifiutano di pubblicare i risultati finché il flag non viene rimosso. Le verifiche retrospettive degli esperimenti passati spesso rilevano una quota significativa di test storici interessati, il che rappresenta una delle scoperte più scomode che un programma di test possa fare, ma anche una delle più preziose, perché spiega perché alcuni successi passati non si sono mai concretizzati nei risultati aziendali.

L'analisi di una discrepanza è un processo sistematico, non una semplice caccia al colpevole. Il primo passo consiste nel verificare se lo squilibrio è presente nei record di assegnazione dello strumento di test o solo in quelli della piattaforma di analisi, distinguendo così un problema di randomizzazione da un problema di tracciamento. Il secondo passo è segmentare il rapporto per dispositivo, browser, area geografica e fonte di traffico, poiché la causa spesso colpisce un gruppo in modo sproporzionato e il segmento che mostra la deviazione maggiore di solito indica direttamente il meccanismo responsabile. Il terzo passo è verificare la tempistica, poiché un rapporto inizialmente corretto e successivamente alterato spesso indica un'implementazione, una modifica della cache o l'introduzione di uno script di terze parti durante il test. Documentare ogni indagine permette di creare un catalogo di cause ricorrenti e la maggior parte delle organizzazioni riscontra che gli stessi due o tre meccanismi sono responsabili della maggior parte degli incidenti.

L'introduzione di un controllo SRM automatico è solitamente una delle prime raccomandazioni tecniche in un Servizio CRO coinvolgimento, perché costa pochissimo da implementare e aumenta immediatamente l'affidabilità di tutto ciò che il programma produce in seguito. Laddove SRM risale al ritardo di rendering delle varianti o alla latenza di reindirizzamento, il rimedio risiede in prestazioni web È più importante lavorare sul problema di velocità piuttosto che sullo strumento di test stesso, e la risoluzione del problema di velocità sottostante tende a migliorare sia la validità degli esperimenti sia il tasso di conversione che misurano.