Diagnostica un'eventuale discrepanza nel rapporto di campionamento in cinque rami prima di scartare il test.

Circa il 6% degli esperimenti presso Microsoft mostra una discrepanza nel rapporto del campione, che in un prodotto che esegue 10,000 esperimenti all'anno corrisponde a circa un rilevamento al giorno (Fabijan e altri, KDD 2019I team che eseguono molti meno test raramente vedono quel numero, perché il controllo eseguito dalla loro piattaforma non può raggiungere la significatività con il loro volume di traffico. Il test sembra a posto, riporta un aumento del 4%, ma è comunque sbagliato.

Questa guida è pensata per chi legge i risultati dell'esperimento e deve decidere se procedere con la spedizione. Al termine, sarai in grado di valutare se il tuo test è sufficientemente ampio da rendere significativo il controllo delle discrepanze, eseguire cinque ramificazioni diagnostiche nell'ordine che individua la causa più rapidamente e distinguere uno squilibrio che invalida la lettura da uno che puoi invece considerare e mantenere.

Cosa ti dice effettivamente un allarme SRM

Una discrepanza nel rapporto di campionamento è una differenza tra la suddivisione configurata e quella osservata: ad esempio, si imposta 50/50 e si ottiene 50.8/49.2. Il controllo standard è il test del chi-quadrato di Pearson per la bontà dell'adattamento sui conteggi di esposizione, con un grado di libertà per un test a due bracci.

È importante perché il meccanismo che causa la perdita di utenti non è quasi mai neutrale rispetto alla tua metrica. Se un reindirizzamento elimina le connessioni lente dalla variante, i sopravvissuti sono quelli con connessioni migliori, e convertono meglio. L'aumento è reale nei dati ma assente nella realtà.

Ecco il primo errore che commettono la maggior parte dei team: non esiste una soglia di riferimento standard per il settore. Le piattaforme differiscono anche di oltre un ordine di grandezza.

Due conseguenze. Un test segnalato su una piattaforma risulta positivo su un'altra con dati identici, quindi "il nostro strumento non ci ha avvisato" non è prova di una netta distinzione. Inoltre, una soglia di 0.01 segnala un test su cento, anche se non errato. Se si controlla visivamente il valore p ogni giorno durante un test di tre settimane, il limite ingenuo di un falso allarme, calcolato con un approccio indipendente, è del 19%; la cifra reale è inferiore perché i giorni consecutivi sono fortemente correlati, ma non è dell'1%. Ecco perché AB Tasty utilizza una procedura sequenziale. Se la vostra piattaforma utilizza un test del chi-quadrato a orizzonte fisso, controllate una sola volta, alla fine, sui conteggi cumulativi.

Verifica se il tuo test è in grado di rilevare uno squilibrio.

Per una suddivisione 50/50, la statistica del chi-quadrato si semplifica in 4n(p̂−0.5)², dove n è il numero totale di esposizioni. Invertendola, si ottiene il più piccolo squilibrio che il controllo può segnalare:

Leggetelo come un limite, non come una licenza. Con 10,000 esposizioni, qualsiasi squilibrio inferiore a 1.3 punti è invisibile al controllo e un effetto di selezione di 1.3 punti è più che sufficiente per creare un piccolo aumento delle conversioni. Questo è il problema strutturale nella maggior parte della regione. La Turchia ha registrato circa 6 miliardi di transazioni di e-commerce in circa 634,000 aziende nel 2025 (Ministero del Commercio, 12 maggio 2026), una media di circa 9,500 all'anno ciascuno, e questa media viene notevolmente aumentata da una manciata di marketplace. Un negozio di medie dimensioni che testa una fase di pagamento lavora con decine di migliaia di esposizioni, non milioni, quindi il suo controllo SRM rileva i guasti più evidenti e niente di più sottile.

A quel volume, non fare affidamento sull'allarme. Estrai tu stesso i conteggi di esposizione grezzi per giorno e per segmento e considera sospetto un persistente spostamento nella stessa direzione anche quando il valore p non è rilevante. Se non sei sicuro di dove la tua piattaforma espone quei conteggi, Documentazione di SRM Checker mappano gli strumenti uno per uno.

I cinque rami, nell'ordine in cui individuano la causa più rapidamente

La tassonomia KDD classifica le cause di SRM in base alla fase del ciclo di vita: assegnazione, esecuzione, elaborazione dei log, analisi, interferenza. Diagnosticarle in un ordine diverso, partendo dalle cause più economiche e comuni.

1. Analisi e attivazione. Sintomo: la suddivisione è netta nel registro di esposizione grezzo e interrotta nella scorecard. Verifica: ricalcolare il rapporto senza la condizione di attivazione, il filtro data e le unioni a livello di metrica. Conferma se il rapporto torna al valore previsto. Soluzione: valutare l'attivazione in modo identico in entrambi i gruppi, prima che qualsiasi comportamento specifico della variante possa modificare l'idoneità. Il falso allarme più comune, dieci minuti per escluderlo.
2. Elaborazione dei log. Sintomo: i conteggi di esposizione differiscono tra due pipeline oppure il divario appare dopo la fase ETL. Verifica: confronta il conteggio lato SDK, il conteggio del data warehouse e il conteggio di reporting per la stessa finestra, quindi confronta i tassi di esclusione del filtro bot per braccio. Conferma se i bracci sono uguali a monte e diversi a valle. Correzione: filtra in modo deterministico e identico. Il traffico automatizzato ha raggiunto il 53% del traffico web nel 2026, rispetto al 51% del 2024 (Segnalazione di bot dannosi da Imperva, 29 aprile 2026), quindi un filtro euristico basato sui tempi di caricamento o sul comportamento dell'agente utente può escludere a tassi diversi per variante. Anche la perdita guidata dal consenso si trova qui: quando ad_storage se viene negato, la piattaforma di tag di Google smette di impostare i cookie pubblicitari (Documenti di consenso della piattaforma di tag di Google), quindi se i tassi di rifiuto differiscono a seconda delle aree geografiche in un test, qualsiasi assegnazione basata su tali identificatori perde utenti in modo non uniforme.
3. Esecuzione. Sintomo: lo squilibrio aumenta con il peso della pagina, è peggiore sui dispositivi mobili o inizia al momento del deployment. Verifica: suddividere il rapporto per dispositivo, browser, tipo di connessione e giorno; confrontare il tempo di esposizione tra i due gruppi. Conferma se il deficit si concentra sui segmenti lenti o in un browser specifico. Soluzione: è qui che i test di reindirizzamento falliscono. Un reindirizzamento aggiunge una navigazione completa solo a un gruppo e chiunque abbandoni la pagina durante il reindirizzamento rappresenta una perdita selettiva. Eseguire il rendering di entrambe le varianti lato server a un unico URL, oppure accettare che i gruppi non siano comparabili.
4. Assegnazione. Sintomo: il rapporto è errato fin dalla prima ora e rimane errato di un fattore costante. Verifica: eseguire un'analisi A/A sulla stessa allocazione e verificare che il salt di hash non sia stato riutilizzato da un esperimento precedente su questa popolazione. Conferma se anche l'analisi A/A mostra lo squilibrio. Soluzione: riassegnare con un nuovo salt e riavviare. Il carryover da un test precedente è la versione silenziosa di questo problema, e solo l'analisi A/A lo rivela.
5. Interferenza. Sintomo: lo squilibrio è concentrato in un piccolo numero di identificatori ad alta attività o in intervalli IP interni. Verifica: la distribuzione del conteggio delle esposizioni per utente e l'1% degli identificatori con il volume di eventi più elevato. Conferma se la loro rimozione ripristina il rapporto. Soluzione: escludere il traffico interno e quello generato da script tramite una regola documentata, non manualmente, in modo che l'esclusione sia identica la volta successiva.

Una guida dettagliata

I numeri seguenti sono a scopo illustrativo e non rappresentano dati del cliente. Un test di verifica riporta 61,480 esposizioni di controllo e 58,520 esposizioni della variante: 51.2/48.8 su 120,000 utenti, p del chi-quadro inferiore a 0.001. Ramo 1: l'eliminazione della condizione di attivazione restituisce 60,020/59,980, quindi l'assegnazione è corretta e la perdita si verifica dopo l'esposizione. Ramo 2: i conteggi della pipeline concordano, esclusioni dei bot dello 0.9% in entrambi i rami. Ramo 3: desktop si attesta a 50.1/49.9, mobile a 52.4/47.6 e il tempo mediano di esposizione della variante è superiore di 900 ms su mobile. Diagnosi: la variante invia una richiesta aggiuntiva che blocca il rendering, gli utenti mobile abbandonano durante tale richiesta, i sopravvissuti hanno connessioni migliori. La lettura è nulla. La correzione è una correzione delle prestazioni e il test viene eseguito nuovamente, non reinterpretato.

Cosa puoi salvare e cosa no

• Annullare la lettura quando il meccanismo di perdita potrebbe plausibilmente correlarsi con la metrica. Ogni causa di esecuzione e assegnazione si qualifica per impostazione predefinita.
• Recupero per segmento Solo quando lo squilibrio è circoscritto a un segmento che è possibile escludere in modo netto, tale segmento è stato definito prima di esaminare la metrica e la parte restante supera il proprio controllo SRM. Due su tre non sono sufficienti.
• Mantieni il test quando la causa era puramente nell'analisi e il punteggio corretto passa. Stai rileggendo gli stessi dati con un filtro fisso, non stai pescando.
• Registralo in entrambi i casi. Registra la categoria della causa sull'esperimento. La tassonomia ripaga in modo cumulativo: se tre dei tuoi ultimi dieci test sono falliti nel ramo 3, il problema non è la sperimentazione, ma la consegna front-end. [DATI INTERNI NECESSARI: percentuale di esperimenti eseguiti da Switas negli ultimi 24 mesi che non hanno superato un controllo SRM, suddivisa per ramo della tassonomia, per sostituire il benchmark Microsoft del 6% con una cifra di questo mercato]

Dove questo si interrompe

Questo albero presuppone un test a due bracci con allocazione fissa e nota e randomizzazione a livello utente. Non copre i test multi-braccio, che richiedono il chi-quadrato completo su tutti i bracci più un follow-up su quale coppia è fuori simmetria, o allocazioni a rampa, dove il rapporto atteso cambia durante il test e un chi-quadrato cumulativo è di per sé un test errato. Non si applica ai disegni a cluster o geo-randomizzati, dove l'unità non è l'utente e lo squilibrio rilevante è nelle caratteristiche del cluster. Non dice nulla sulla correttezza della definizione della metrica. E non può essere d'aiuto quando le esposizioni non vengono registrate e si inferisce l'assegnazione da un evento metrico, che non è un controllo A/B ma una supposizione.

FAQ

Una ripartizione 51/49 è sempre un problema? Dipende interamente da n. A 5,000 esposizioni si tratta di rumore ordinario; a 500,000 è un difetto quasi certo. Valuta il rapporto in base alla tabella di rilevabilità, non in base a una regola empirica basata su una percentuale fissa.

Posso semplicemente ricalcolare il peso dei bracci statisticamente invece di rieseguire l'esperimento? No. La riponderazione corregge i conteggi e lascia la selezione intatta. Gli utenti che hai perso non ci sono più e non rappresentavano un campione casuale del braccio.

Con quale frequenza dovrei controllare il valore p dell'SRM? Una volta, alla fine, sui conteggi cumulativi, a meno che la tua piattaforma non esegua una procedura sequenziale. Controllare quotidianamente un chi-quadrato a orizzonte fisso aumenta notevolmente i falsi allarmi.

SRM invalida anche le metriche di protezione? Sì, per lo stesso motivo. Se i bracci contengono popolazioni diverse, una linea di guardia fissa non è più affidabile di un parametro primario mobile.

E se anche un test A/A mostrasse una discrepanza? Il problema risiede quindi nell'assegnazione o nella pipeline di logging, non nel tuo metodo di elaborazione. Risolvilo prima di eseguire qualsiasi altra operazione, perché sta compromettendo tutti i test su quella piattaforma.

I test di reindirizzamento causano sempre SRM? Non sempre, ma comportano un rischio strutturale che nessun altro design presenta, perché la navigazione aggiuntiva è presente solo in un braccio. Se proprio dovete utilizzarne uno, verificate il rapporto in base alla velocità di connessione e al dispositivo prima di leggere qualsiasi parametro.

Il mio traffico è troppo basso perché il controllo abbia un qualche significato. Cosa posso fare, quindi? Monitora i conteggi giornalieri grezzi dell'esposizione per individuare derive persistenti, esegui un'analisi A/A periodica sul livello di assegnazione e preregistra un elenco più lungo di controlli di coerenza. Stai sostituendo la potenza statistica con il processo.

Il filtraggio dei bot dovrebbe avvenire prima o dopo l'assegnazione? Dopo la registrazione dell'esposizione, prima dell'analisi, utilizzando regole deterministiche applicate in modo identico a entrambi i gruppi. Il filtraggio euristico all'interno dell'SDK è il modo in cui il filtro stesso diventa la discrepanza.

Esegui il controllo sul tuo programma di esperimenti

Se desideri un secondo parere sullo stato di salute dei test che stai eseguendo ora, o una revisione del livello di assegnazione e registrazione da cui dipendono tutti, questo è ciò che il nostro CRO e servizi di sperimentazione fa.

fonti

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Diagnosi di discrepanza nel rapporto tra campioni in esperimenti controllati online: una tassonomia e regole pratiche per i professionisti", KDD 2019
• Documentazione AB Tasty, Discrepanza nel rapporto dei campioni (S-SRM sequenziale, soglia 0.01)
• Statsig, "Guida rapida alla discrepanza del rapporto campionario", 31 agosto 2023 (chi-quadrato, soglia 0.01)
• Documentazione di GrowthBook, Sperimentazione (test del chi-quadrato, attenzione per valori inferiori a 0.001)
• Imperva, "Bad Bot Report 2026: I bot nell'era degli agenti", 29 aprile 2026
• Repubblica di Turchia, Ministero del Commercio, dati sull'e-commerce relativi al 2025, 12 maggio 2026
• Piattaforma di tag di Google, modalità di consenso e comportamento di archiviazione
• Documentazione e FAQ di SRM Checker, Lukas Vermeer