Peeking, multiple testing and sequential testing

Questa lezione tratta peeking, multiple testing e sequential testing come una scelta operativa, non come una raccolta di definizioni. La domanda di fondo è semplice: quando il dato di un esperimento diventa più affidabile, quale decisione cambia davvero? Tutto il resto serve solo a rendere quella decisione più difendibile.

Quando la fretta corrompe l’evidenza

Il punto non è conoscere peeking e sequential testing in astratto. Il problema arriva quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura di un test. Guardare il risultato ogni mattina, fermare l’esperimento quando il numero conviene e provare dieci metriche finché una diventa significativa: tre abitudini che trasformano un esperimento in selezione opportunistica. Ognuna gonfia la probabilità di scambiare rumore per segnale.

Il fallimento più comune nasce prima ancora dei numeri. Il team riconosce che questo tema conta, ma non sa dire quale decisione ne dipenda. Si aprono dashboard, si leggono report, si discutono strumenti, e intanto la domanda operativa resta implicita. Ogni stakeholder usa parole simili con significati diversi. Nel lavoro reale questo costa caro: le priorità seguono il rumore del momento, le letture non sono confrontabili nel tempo e la responsabilità si sposta appena il risultato delude. La lezione parte quindi da una domanda concreta. Come formulare peeking, multiple testing e sequential testing in modo che un team prenda una decisione migliore, e non solo discuta meglio.

Il modello: dalla decisione all’azione

Conviene leggere il tema come un ponte tra contesto, misura e azione. Un modello robusto separa quattro blocchi: la decisione da supportare, i segnali osservabili, il meccanismo che collega segnali e decisione, e i guardrail che limitano gli errori di interpretazione. L’obiettivo del modulo aiuta a tenere la rotta: portare la sperimentazione a un livello serio, non da checklist. La domanda giusta non è solo “cosa misuro”, ma quale ipotesi sto assumendo, quale rischio sto introducendo e quale output voglio produrre alla fine.

Per non ridurre tutto a un rituale vuoto, uso questa sequenza come mappa di lavoro. Ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo meglio peeking e sequential testing?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Formalizzare la relazione tra decisione, evidenza e rischio

Formalizzare non serve a complicare la lezione. Serve a rendere visibili le assunzioni, così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità. La tabella seguente lega ogni elemento al suo controllo minimo.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

Il criterio operativo resta semplice. Se due persone esperte leggono la stessa definizione e guardano lo stesso materiale, devono arrivare a conclusioni comparabili sugli stessi trade-off. Quando questo non succede, il problema non è lo strumento ma la formalizzazione. Una buona formalizzazione esplicita unità di analisi, denominatori, segmentazioni rilevanti, condizioni di validità e failure mode, e lascia spazio a ipotesi ed eccezioni invece di chiudersi in una checklist cieca.

Un caso: l’esperimento che cambia idea ogni giorno

Un esperimento sembra vincere al giorno 3, perde significatività al giorno 5 e torna positivo al giorno 8. È l’esempio più chiaro del perché peeking e sequential testing richiedono regole di lettura predefinite: senza di esse il team finisce per scegliere il momento più conveniente e raccontarlo come prova. Il valore del caso non sta nel singolo numero, ma nella catena logica che collega contesto, misura e decisione.

La stessa logica vale quando i numeri sono ambigui. Se il dato migliora ma la baseline è debole, il segnale potrebbe essere reale oppure dipendere dal campione, e conviene rafforzare il confronto prima di scalare. Se la metrica cambia in un solo segmento, l’effetto medio nasconde eterogeneità, e bisogna separare le coorti. Quando il costo operativo cresce, il beneficio va valutato sul margine con una soglia economica esplicita. E quando il sistema produce numeri incoerenti, la fiducia nel dato diventa parte della decisione: prima si correggono ownership e controlli, poi si legge il risultato.

Lab a tre livelli

Nel livello base scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a questa lezione, indicando metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, la lezione è ancora troppo astratta. Un secondo esercizio dello stesso livello: descrivi un caso in cui peeking e sequential testing vengono citati senza una decisione chiara alle spalle, poi riscrivi il problema in modo operativo indicando quale evidenza minima servirebbe per agire.

Nel livello intermedio costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Includi almeno un caso in cui il segnale non basta per decidere. Oppure usa il dataset pack del modulo per una mini-analisi completa, dalle definizioni al criterio di lettura fino all’output finale.

Nel livello research-grade trasforma l’esercizio in un memo decisionale che include assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Per spingerti oltre, confronta due modi diversi di trattare il tema e mostra quali ipotesi cambiano, quali errori emergono e quale formulazione regge meglio davanti a una review rigorosa.

Per i materiali ti basta un export reale, una tabella sintetica, una dashboard interna o un notebook di studio. Il dataset deve contenere almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto. Il pacchetto del modulo aggiunge query SQL, notebook commentato e soluzione guidata con checklist e rubric, utili per confrontare l’approccio corretto con l’errore tipico.

L’errore tipico

L’errore più comune è usare peeking e sequential testing come etichetta tecnica invece che come criterio di scelta. Succede quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. Il dato sembra preciso, ma non guida l’azione. C’è poi un errore gemello, scambiare familiarità con comprensione: i concetti citati più spesso sono proprio quelli che richiedono più rigore, perché muovono più decisioni e più risorse.

Checkpoint

Prima di considerare chiuso il lavoro, rispondi a queste domande.

1. Which concrete decision should this lesson improve?
2. Which unit of analysis makes the problem measurable?
3. Quale baseline useresti per evitare una lettura isolata?
4. Which guardrails prevent reading noisy signals as if they were proof?
5. Quale controllo presenteresti prima di raccomandare un’azione?

Dal concetto al lavoro consegnabile

Per consolidare il tema, trattalo come una piccola prova di lavoro dentro una decisione sperimentale, dove effetto, rumore, potenza e rischio di business si leggono insieme. Non basta dire di aver capito: devi produrre un memo di esperimento con ipotesi, MDE, guardrail, lettura e limite dichiarato. Parti da una domanda semplice, quale scelta diventerebbe migliore se applicassi bene questa lezione, e collega un problema reale a un output osservabile.

Un esempio valido non deve essere grande. Può essere una tabella con una baseline e due segmenti, una query che verifica una definizione, un disegno di esperimento o un memo di dieci righe. La qualità non dipende dalla complessità tecnica ma dalla tracciabilità del ragionamento: chi legge deve capire perché hai scelto quella metrica, quale alternativa hai scartato e quale evidenza ti farebbe cambiare idea. Scrivi la decisione con un verbo operativo (allocare, fermare, correggere, lanciare, misurare, priorizzare o investigare), definisci il segnale e almeno un guardrail, aggiungi una baseline e dichiara il rischio più probabile prima della raccomandazione. Il rischio quasi sempre è lo stesso: trasformare un p-value, una soglia o una curva di potenza in una sentenza più forte del disegno.

Un controllo finale utile è la verifica di trasferimento. Prendi un progetto reale o simulato e scrivi tre versioni dello stesso output: una per te, con dettagli tecnici e assunzioni; una per un collega, con controlli riproducibili; una per un decisore, con rischio residuo e prossima azione. Se le tre versioni non sono coerenti, il ragionamento non è ancora stabile.

Summary

Peeking, multiple testing e sequential testing non sono dettagli da sistemare a fine esperimento. Sono regole di governance che decidono quanto puoi fidarti di un risultato mentre la pressione di business spinge per agire subito. La padronanza sta nel definire prima quando guardi i dati, quante ipotesi stai testando e quale criterio userai per fermare, continuare o correggere il test. La forma utile della lezione resta sempre la stessa: decisione, segnale, baseline, rischio e azione. Hai assimilato il tema quando sai spiegarlo senza gergo inutile, applicarlo a un caso piccolo ma realistico e difendere una raccomandazione includendo limiti e prossimi controlli.