Un esperimento assegna gli utenti a due varianti, 50% e 50%, e alla fine del test la variante B mostra un miglioramento chiaro sulla metrica che contava. Prima di dichiararla vincente, però, un singolo controllo, quasi sempre saltato, dovrebbe far scattare un campanello d’allarme: quanti utenti sono finiti davvero in ciascuna variante? Nell’esempio riportato da Analytics Toolkit, su un totale di 31.009 utenti, il gruppo di controllo ne conteneva 15.752 e la variante 15.257: non il 50/50 atteso, ma una differenza di quasi 500 utenti a favore del controllo. È il Sample Ratio Mismatch (SRM): uno squilibrio nella proporzione di utenti tra i gruppi di un test, rispetto a quella configurata all’inizio, e un problema che, quando è statisticamente significativo, invalida il test prima ancora di guardare il risultato sulla metrica di interesse.
Perché uno squilibrio nel conteggio conta più di uno squilibrio nel risultato. L’assunzione su cui si basa qualunque test A/B è che l’assegnazione alle varianti sia casuale: se lo è, le differenze osservate tra i gruppi possono essere attribuite al trattamento testato, non a differenze preesistenti tra chi è finito in un gruppo e chi nell’altro. Un SRM rompe esattamente questa assunzione, e lo fa in un modo particolarmente insidioso: gli utenti che mancano da un gruppo raramente mancano a caso. Se un bug nel codice della variante B fa sì che gli utenti con una connessione lenta, o con un browser meno recente, vengano esclusi dal conteggio prima ancora di vedere la pagina, il gruppo B che resta non rappresenta più la stessa popolazione del gruppo di controllo: è già filtrato, in una direzione che nessuno ha scelto consapevolmente. Un miglioramento osservato in queste condizioni può riflettere quel filtro, non l’effetto della modifica testata.
Come si verifica con la matematica. Il controllo standard è un test chi-quadrato di adattamento, che confronta la distribuzione osservata degli utenti tra i gruppi con quella attesa in base alla configurazione del test. Con un’allocazione 50/50 su 31.009 utenti totali, il valore atteso per ciascun gruppo è 15.504,5. La formula è: χ² = Σ [(Osservato − Atteso)² ÷ Atteso]. Applicandola ai due gruppi: per il controllo, (15.752 − 15.504,5)² ÷ 15.504,5 ≈ 3,95; per la variante, (15.257 − 15.504,5)² ÷ 15.504,5 ≈ 3,95. Il valore totale è χ² ≈ 7,90, con un grado di libertà (il numero di gruppi meno uno). Un valore così alto corrisponde ad una probabilità di osservarlo per puro caso di circa 1 su 200: un risultato che, secondo gli stessi autori, è già sufficiente per considerare inattendibile l’intero esperimento, indipendentemente da cosa dica la metrica principale.
Perché la soglia va fissata più in basso del solito 0,05. La piattaforma di sperimentazione di Microsoft raccomanda di segnalare un SRM solo quando il p-value scende sotto 0,0005, dieci volte più severo dello standard convenzionale usato per giudicare l’effetto principale di un test. La ragione non è arbitraria: un controllo SRM viene eseguito automaticamente su ogni singolo esperimento in corso, non una volta sola su un singolo test, quindi una soglia larga produrrebbe troppi falsi allarmi su larga scala; inoltre, nella pratica osservata, gli squilibri campionari reali, quelli causati da bug effettivi e non da fluttuazioni casuali, tendono a produrre valori di p-value molto più estremi di 0,0005, per cui restringere la soglia elimina il rumore senza perdere quasi nessun caso reale.
Quanto è frequente e da dove arriva di solito. Uno studio di un gruppo di ricercatori Microsoft, presentato alla conferenza KDD nel 2019, ha stimato che circa il 6% dei test A/B condotti internamente presentasse un SRM statisticamente significativo; LinkedIn, analizzando più nel dettaglio un sottoinsieme di test già segnalati per altri motivi, ne ha trovato una quota prossima al 10%. Lo stesso studio classifica le cause più comuni in quattro fasi distinte del processo: nella fase di assegnazione (bucketing difettoso, ID utente instabili tra sessioni); nell’esecuzione (redirect asimmetrici tra le varianti, differenze di velocità di caricamento che fanno abbandonare una variante più dell’altra); nel processamento dei log (join di dati eseguiti in modo scorretto tra sistemi diversi); e nell’analisi stessa (filtri o condizioni di segmentazione applicati in modo asimmetrico tra i gruppi senza che chi analizza se ne renda conto).
Cosa comporta, in pratica, per chi gestisce test A/B su un sito o un prodotto. Il controllo SRM dovrebbe far parte della pipeline automatica di analisi, eseguito come un cancello (gate) prima di qualunque lettura del risultato principale, non come una verifica manuale occasionale che nella pratica quasi nessuno esegue quando un test “sembra” già andato bene. Per un’azienda che si affida ad una piattaforma di test A/B esterna (i costruttori di landing page e gli strumenti di CRO più diffusi variano molto su questo punto), la domanda da porre al fornitore prima di fidarsi ciecamente dei risultati è semplice e verificabile: il sistema effettua un controllo automatico del Sample Ratio Mismatch prima di dichiarare un vincitore, o quel controllo va fatto a mano, sui dati grezzi, ogni volta?
Fonti: Analytics Toolkit, “Does Your A/B Test Pass the Sample Ratio Mismatch Test?”; Microsoft Research, “Diagnosing Sample Ratio Mismatch in A/B Testing”; A. Fabijan et al., “Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners”, KDD 2019.