Bayesian A/B, switchback test, and geo-test

Non tutti gli esperimenti possono essere randomizzati per utente: alcuni riguardano prezzi, delivery, marketplace, città o periodi temporali. Bayesian, switchback e geo-test mostrano come cambiare disegno quando l’unità sperimentale e il contesto non permettono un A/B classico. È una lezione di Analisi: il punto non è accumulare definizioni, ma capire quale decisione cambia quando scegli il disegno giusto per il vincolo reale che hai davanti.

Quando l’A/B classico non basta

Leggi questi metodi come scelta del disegno sperimentale adatto al vincolo, non come varianti decorative. Rispondono a problemi diversi di unità, interferenza, stagionalità e decisione. Il fallimento più comune nasce quando il team riconosce che questi disegni contano, ma non sa dire quale decisione dipenda davvero da essi. Si aprono dashboard, si leggono report, si discutono strumenti, ma la domanda operativa resta implicita e ogni stakeholder finisce per usare parole simili con significati diversi.

Nel lavoro reale questo produce costi immediati: priorità che cambiano al rumore del momento, letture non confrontabili nel tempo e responsabilità che si spostano quando il risultato è deludente. La lezione parte quindi da una domanda concreta: come formulare la scelta tra Bayesian, switchback e geo-test in modo che un team prenda una decisione migliore, non solo una discussione più elegante.

Come scegliere il disegno

Un modello robusto separa quattro blocchi: la decisione da supportare, i segnali osservabili, il meccanismo che collega segnali e decisione, i guardrail che limitano gli errori di interpretazione. La scelta del disegno non è un’etichetta da citare, ma un ponte tra contesto, misura e azione. Va letta insieme all’obiettivo del modulo, portare la sperimentazione a livello serio e non da checklist: la domanda corretta non è solo “cosa misuro?”, ma anche “quale ipotesi sto assumendo, quale rischio sto introducendo e quale output mi aspetto alla fine?”.

Step	Question to ask	Expected output
Decision	Che cosa cambia se scegliamo meglio il disegno?	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

Gli elementi da formalizzare

La formalizzazione serve a evitare due errori opposti: trattare tutto come opinione oppure ridurre il tema a una checklist cieca. Una formalizzazione buona esplicita definizioni, unità di analisi, denominatori, segmentazioni rilevanti, condizioni di validità e failure mode. Il criterio resta semplice: se due persone esperte leggono la stessa definizione e guardano lo stesso materiale, devono arrivare a conclusioni comparabili sugli stessi trade-off. Se non succede, il problema non è il tool, è la formalizzazione.

Element	Operational Definition
Supported decision	Quale scelta migliora quando il disegno viene definito bene
Input	Dati, vincoli, segmentazioni e segnali tipici del modulo
Mechanism	Rules by which the team moves from observations to interpretation
Guardrail	Checks that prevent opportunistic, confounding or out-of-context readings
Output	Query, memo, dashboard, design or defensible recommendation

A questi vanno aggiunti i controlli minimi che reggono la lettura: una soglia decisionale scritta prima dell’analisi e un rischio residuo da nominare anche dopo aver concluso, da verificare con un sensitivity check o una revisione qualitativa.

Un caso applicato

Un marketplace non può randomizzare utenti perché rider, ristoranti e città interferiscono tra loro. Il caso richiede di scegliere tra switchback e geo-test, dichiarando unità sperimentale, finestre temporali, rischio di spillover e metrica di marketplace da proteggere. Il valore non sta nel singolo numero, ma nella catena che collega contesto, misura e decisione: la lezione allena proprio questo passaggio, trasformare una situazione opaca in un output che si può discutere, correggere e difendere.

Step	Guiding question	Expected output
Context	Which decision are we trying to improve?	Well-formulated problem
Structure	Which definitions, variables, and segmentations really matter?	Coherent framework
Verification	Where can the model mislead?	Guardrails and limits
Decision	What do we do now and why?	Defensible action

Per orientarti sulla situazione di partenza, la stessa lettura cambia a seconda di quanto è solida la baseline: un dato che migliora con baseline debole va confermato prima di scalare, una metrica che cambia in un solo segmento nasconde eterogeneità, un costo operativo che aumenta chiede una soglia economica esplicita, e numeri incoerenti impongono di correggere ownership e controlli prima ancora di leggere il risultato.

Lab

Al livello base, descrivi un caso in cui questi disegni vengono citati senza una decisione chiara alle spalle, poi riscrivi il problema in modo operativo e indica quale evidenza minima servirebbe per agire. Al livello intermedio, usa il dataset pack del modulo per costruire una mini-analisi completa: definizioni, input, criterio di lettura, guardrail e output finale. Al livello research-grade, confronta due modi diversi di trattare lo stesso problema e mostra quali ipotesi cambiano, quali errori emergono e quale formulazione regge meglio davanti a una review rigorosa.

Il pacchetto di lavoro del modulo tiene l’esercizio sul concreto: un dataset realistico in cui query, modelli e assunzioni cambiano davvero il risultato, un notebook commentato per esplorazione e checkpoint, query SQL da adattare al proprio contesto e una soluzione guidata con checklist, rubric e confronto tra approccio corretto ed errore tipico.

L’errore tipico

L’errore più frequente è scambiare familiarità con comprensione. Quando un tema viene citato spesso, il team tende a credere che sia già stato definito abbastanza bene. In realtà proprio i concetti più usati sono quelli che richiedono più rigore, perché muovono più decisioni e più risorse. Il secondo errore è trattare il framework come una risposta invece che come uno strumento: se la formalizzazione non lascia spazio a ipotesi, eccezioni, limiti e possibili rotture del modello, stai costruendo un rituale invece di una pratica analitica.

Checkpoint

Per verificare di aver capito, prova a rispondere a queste domande:

1. Quale decisione cambia davvero quando il disegno viene scelto meglio?
2. Which guardrails prevent reading noisy signals as if they were proof?
3. At what point in the case does the team move from describing the phenomenon to a defensible recommendation?

Un buon controllo finale è scrivere 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 abbastanza stabile. Hai assimilato davvero questi disegni quando riesci a spiegarli senza gergo inutile, applicarli a un caso piccolo ma realistico, e difendere una raccomandazione includendo limiti e prossimi controlli.

Summary

Bayesian A/B, switchback test e geo-test servono quando il classico esperimento per utente non basta più. La scelta del disegno dipende dal tipo di interferenza, dalla scala dell’intervento e dalla decisione da prendere. La competenza non è nominare il metodo più sofisticato, ma scegliere il disegno meno fragile per il vincolo reale che hai davanti. La forma corretta del ragionamento resta sempre la stessa: decisione, segnale, baseline, rischio e azione.