Well-Formulated Causal Questions and Business Hypotheses

Molti esperimenti partono da una variante già decisa e solo dopo cercano una metrica favorevole. Una domanda causale ben formulata ribalta l’ordine: prima chiarisci quale comportamento vuoi cambiare, perché dovrebbe cambiare e quale decisione prenderai se l’evidenza arriva. La categoria di questa lezione è Analisi, quindi il punto non è accumulare definizioni ma capire quale scelta cambia quando il dato diventa più affidabile. Una buona ipotesi rende falsificabile la storia business e impedisce di cambiare domanda quando il risultato non piace.

Il problema reale

Il problema non è conoscere il tema in astratto, ma decidere cosa fare quando il team lavora con dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura. Una lezione utile deve separare il segnale dal rumore, indicare quale baseline usare e mostrare quale azione diventa più difendibile dopo l’analisi.

Il fallimento più comune nasce quando tutti riconoscono che la formulazione conta, ma nessuno sa dire quale decisione dipenda davvero da questo tema. 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 subito caro. Le priorità cambiano al rumore del momento, le letture non sono confrontabili nel tempo e la responsabilità si sposta appena il risultato delude. Per questo conviene partire da una domanda concreta: come formulare una domanda causale in modo che il team prenda una decisione migliore, non solo una discussione più elegante.

Il modello di lavoro

Conviene leggere una domanda causale come un ponte tra contesto, misura e azione, separando 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. La domanda corretta non è solo “cosa misuro?”, ma anche quale ipotesi sto assumendo, quale rischio sto introducendo e quale output mi aspetto alla fine.

Una sequenza operativa aiuta a non trasformare il tema in un rituale vuoto. Ogni passaggio dovrebbe rendere più chiaro il costo di una decisione sbagliata.

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

La formalizzazione

Formalizzare non significa complicare. Serve a rendere visibili le assunzioni, così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità. Una buona formalizzazione 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. Quando questo non succede, il problema non è lo strumento ma la formalizzazione.

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 può restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

Il caso del banner

La richiesta iniziale è “testiamo il nuovo banner”. L’ipotesi ben formulata diventa invece “rendere più esplicito il valore riduce l’abbandono tra utenti nuovi prima del primo progetto”. Il caso mostra come una buona domanda causale renda misurabile il meccanismo, non solo la variante. Il valore non sta nel singolo numero, ma nella catena logica che collega contesto, misura e decisione: allenare questo passaggio significa trasformare una situazione opaca in un output che si può discutere, correggere e difendere.

Per leggere un caso conviene tenere a mente alcune situazioni ricorrenti e la decisione che ciascuna suggerisce.

Situation	Cautious interpretation	Decision
Il dato migliora ma la baseline è debole	Il segnale potrebbe essere reale o dipendere dal campione	Rafforzare il confronto prima di scalare
La metrica cambia in un solo segmento	The average effect hides heterogeneity	Separate cohorts or use cases
Il costo operativo aumenta	Il beneficio va valutato sul margine	Applicare una soglia economica esplicita
Il sistema produce numeri incoerenti	La fiducia nel dato è parte della decisione	Correggere ownership e controlli

Per analizzare un caso conviene seguire quattro passaggi: chiarire quale decisione vogliamo migliorare, individuare definizioni e variabili che contano davvero, cercare dove il modello potrebbe ingannare e infine scegliere cosa fare e perché.

Lab a tre livelli

Al livello base, descrivi un caso in cui una domanda causale viene citata senza una decisione chiara alle spalle. Riscrivi il problema in modo operativo e indica quale evidenza minima servirebbe per agire. Indica metrica, unità di analisi, baseline e rischio principale: se non riesci a nominare la decisione, la lezione è ancora troppo astratta.

Al livello intermedio, usa il dataset pack del modulo per costruire una mini analisi con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Inserisci almeno un caso in cui il segnale da solo non basta per decidere.

Al livello research-grade, confronta due modi diversi di trattare la stessa domanda causale e mostra quali ipotesi cambiano, quali errori emergono e quale formulazione regge meglio davanti a una review rigorosa. Trasforma poi l’esercizio in un memo decisionale con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione.

Per i materiali puoi usare 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 un dataset realistico, query SQL, un notebook commentato per esplorazione e checkpoint, e una soluzione guidata con checklist e rubric, utile per allenare il modulo senza restare nel solo piano teorico.

L’errore tipico da evitare

L’errore più frequente è scambiare familiarità con comprensione. Quando un tema viene citato spesso, il team tende a crederlo già definito abbastanza bene, mentre proprio i concetti più usati 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. In pratica l’errore appare quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. In quel caso il dato sembra preciso ma non guida l’azione.

Checkpoint

1. Quale decisione cambia davvero quando la domanda causale viene formulata meglio?
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. At what point in the case does the team move from describing the phenomenon to a defensible recommendation?

Practice deep dive

Per consolidare il tema, trattalo come una piccola prova di lavoro dentro una decisione sperimentale in cui effetto, rumore, potenza e rischio business vanno letti insieme. Non basta dire di aver capito la lezione: devi produrre un piano o un memo di esperimento con ipotesi, MDE, guardrail, lettura e limite dichiarato. Questo obbliga a separare contesto, misura, azione e limite, e rende la conoscenza trasferibile.

Parti da una domanda semplice: quale scelta diventerebbe migliore se applicassi bene questa lezione? La risposta deve sempre collegare 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.

Per il checkpoint di lavoro, scrivi la decisione che la lezione dovrebbe migliorare usando un verbo operativo come allocare, fermare, correggere, lanciare, misurare o investigare. Definisci poi il segnale principale e almeno un guardrail: il segnale dice dove guardi, il guardrail evita che una scelta localmente buona rovini il sistema. Aggiungi una baseline, perché senza non sai se il numero è alto, basso, stabile o solo raccontato male. Esplicita il rischio più probabile, cioè trasformare un p-value, una soglia o una curva di potenza in una sentenza più forte del disegno, e scrivilo prima della raccomandazione. Chiudi con un output consegnabile che un reviewer possa aprire e criticare.

Summary

Una domanda causale ben scritta evita che l’esperimento diventi una raccolta di metriche interessanti ma inutili. La domanda deve dire quale comportamento vuoi cambiare, quale meccanismo ipotizzi e quale decisione prenderai se il segnale regge. Senza questa disciplina, anche un test tecnicamente corretto può rispondere a una domanda che nessuno aveva davvero bisogno di porre. La forma corretta della lezione resta decisione, segnale, baseline, rischio e azione, e tutto il resto serve solo se rende più affidabile uno di questi passaggi. Hai assimilato il tema quando riesci a spiegarlo senza gergo inutile, applicarlo a un caso piccolo ma realistico e difendere una raccomandazione includendo limiti e prossimi controlli.