Il pensiero causale di Judea Pearl: IA migliore, debugging e decisioni

Perché causa‑effetto è meglio del semplice riconoscimento di pattern

Un team nota qualcosa di “ovvio” nella dashboard: gli utenti che ricevono più notifiche tornano più spesso. Allora aumentano il volume delle notifiche. Una settimana dopo, la retention cala e aumentano i reclami. Cosa è successo?

Il pattern originale era reale—ma fuorviante. Gli utenti più coinvolti naturalmente attivano più notifiche (perché usano di più il prodotto) e tornano più spesso. Le notifiche non causavano la retention; l’engagement causava entrambi. Il team ha agito sulla correlazione e ha involontariamente creato un’esperienza peggiore.

Cosa significa “pensiero causale” (in parole semplici)

Pensare in termini causali è l’abitudine di chiedersi: cosa causa cosa, e come lo sappiamo? Invece di fermarsi a “queste due cose si muovono insieme”, provi a separare:

• Segnali che osservi (ciò che vedi nei log, nelle metriche e nei grafici)
• Leve che puoi muovere (ciò che puoi cambiare nel mondo reale)
• Effetti collaterali e influenze nascoste (altri fattori che spingono entrambe le variabili)

Non è scetticismo dei dati: è precisione nella domanda. “Le notifiche sono correlate con la retention?” è diverso da “Inviare più notifiche aumenterà la retention?” La seconda è una domanda causale.

Dove aiuta subito

Questo articolo si concentra su tre aree pratiche dove il riconoscimento di pattern spesso fallisce:

1. Sistemi AI: capire se un modello usa le ragioni giuste (o solo scorciatoie) quando fa predizioni.
2. Debugging: trovare la vera causa quando metriche peggiorano o accadono incidenti, invece di inseguire la coincidenza più rumorosa.
3. Decisioni di prodotto: scegliere cambiamenti che muovono gli esiti, non solo che “assomigliano” ai segmenti ad alte prestazioni.

Cosa aspettarsi da questo articolo

Non è un tour pesante di matematica sull’inferenza causale. Non devi imparare la notazione del do‑calculus per ottenere valore qui. L’obiettivo è una serie di modelli mentali e un workflow che il tuo team può usare per:

• formulare domande migliori,
• evitare trappole comuni come il confondimento,
• decidere quando serve un esperimento rispetto a un ragionamento osservazionale attento.

Se hai mai rilasciato una modifica che “sembrava buona nei dati” ma non ha funzionato nella realtà, il pensiero causale è il tassello mancante.

Chi è Judea Pearl e cosa ha cambiato?

Judea Pearl è un informatico e filosofo della scienza il cui lavoro ha rimodellato il modo in cui molti team pensano ai dati, all’IA e alle decisioni. Prima della sua rivoluzione causale, gran parte dell’“imparare dai dati” in informatica si concentrava sulle associazioni statistiche: trovare pattern, adattare modelli, prevedere il prossimo evento. Questo approccio è potente—ma spesso si rompe quando si pone una domanda di prodotto o ingegneria che contiene la parola perché.

La svolta chiave di Pearl è stata trattare la causalità come un concetto di prima classe, non come un’intuizione vaga sopra le correlazioni. Invece di chiedere solo “quando X è alto, anche Y è alto?”, il pensiero causale chiede “se cambiamo X, Y cambierà?” Questa differenza sembra piccola, ma separa la previsione dal decision‑making.

Dalle associazioni alle domande causali

L’associazione risponde a “cosa tende a co‑occorre”. La causalità mira a rispondere “cosa succederebbe se intervenissimo”. Questo conta in informatica perché molte decisioni reali sono interventi: rilasciare una feature, cambiare ranking, aggiungere un guardrail, alterare un dataset di addestramento o modificare una policy.

Non è magia: assunzioni che si possono dichiarare e discutere

Pearl ha reso la causalità più pratica inquadrandola come una scelta di modello più assunzioni esplicite. Non “scopri” la causalità automaticamente dai dati in generale; proponi una storia causale (spesso basata sulla conoscenza del dominio) e poi usi i dati per testarla, stimarla e raffinarla.

I principali artefatti che Pearl ha reso popolari

• Grafi causali (DAG): diagrammi semplici che codificano le relazioni causa‑effetto assunte.
• Interventi (“do”): ragionare su cosa cambia quando si imposta attivamente una variabile, non solo quando la si osserva.
• Controfattuali: “cosa sarebbe successo in questo caso specifico se avessimo fatto qualcosa di diverso?”

Questi strumenti hanno dato ai team un linguaggio condiviso per passare dal riconoscere pattern a rispondere a domande causali con chiarezza e disciplina.

Correlazione vs causalità: la domanda che stai davvero ponendo

La correlazione significa che due cose si muovono insieme: quando una aumenta, l’altra tende ad aumentare (o diminuire). È estremamente utile—soprattutto nei team guidati dai dati—perché aiuta con previsioni e rilevamento.

Se le vendite di gelati crescono quando aumenta la temperatura, un segnale correlato (temperatura) può migliorare le previsioni. Nel lavoro di prodotto e AI, le correlazioni alimentano modelli di ranking (“mostra di più quello che utenti simili hanno cliccato”), il rilevamento di anomalie (“questa metrica di solito segue quell’altra”) e diagnosi rapide (“gli errori aumentano quando la latenza aumenta”).

Il problema inizia quando trattiamo la correlazione come risposta a una domanda diversa: cosa succede se cambiamo qualcosa di proposito? Quella è causalità.

Perché la correlazione fallisce per “se cambiamo X?”

Una relazione correlata può essere guidata da un terzo fattore che influisce su entrambe le variabili. Cambiare X non implica necessariamente cambiare Y—perché X potrebbe non essere la ragione per cui Y si muoveva.

Un semplice esempio di confondimento: spesa marketing vs vendite

Immagina di tracciare la spesa settimanale in marketing contro le vendite settimanali e vedere una forte correlazione positiva. È facile concludere “più spesa causa più vendite”.

Ma supponi che entrambe salgano durante le feste. La stagione (un confonditore) genera maggiore domanda e scatena anche budget più grandi. Se aumenti la spesa in una settimana non festiva, le vendite potrebbero non salire molto—perché la domanda sottostante non c’è.

Segnali che stai davvero facendo una domanda causale

Se ti senti a chiedere:

• “Se aumentiamo/diminuiamo X, cosa succederà a Y?”
• “Dovremmo lanciare questa feature o mantenere la vecchia?”
• “Quale cambiamento ridurrà il churn, non solo lo predirà?”
• “Questa campagna ha funzionato, o le vendite sarebbero comunque salite?”
• “Qual è l’impatto di rimuovere un passaggio, aggiungere un avviso o cambiare prezzi?”

quando il verbo è cambiare, lanciare, rimuovere o ridurre, la correlazione è un indizio iniziale—non la regola decisionale.

Diagrammi causali (DAG) come linguaggio condiviso del team

Un diagramma causale—spesso disegnato come un DAG (Directed Acyclic Graph)—è un modo semplice per rendere visibili le assunzioni del team. Invece di litigare in termini vaghi (“probabilmente è il modello” o “forse l’UI”), metti la storia su un foglio.

Nodi e frecce: la grammatica di base

• Nodi sono variabili che ti interessano: email marketing inviata, intenzione dell’utente, score del modello, acquisto.
• Frecce dirette rappresentano un’influenza causale: se cambiare A cambierebbe B, disegna A → B.

Lo scopo non è la verità perfetta; è una bozza condivisa di “come pensiamo funzioni il sistema” che tutti possono criticare.

Confonditori, mediatori e collisori (con un piccolo esempio)

Supponiamo di valutare se un nuovo tutorial di onboarding (T) aumenta la attivazione (A).

• Confonditore: motivazione dell’utente (M) influisce sia sul completamento del tutorial sia sull’attivazione: M → T e M → A. Ignorando M, potresti attribuire al tutorial ciò che era dovuto alla motivazione.
• Mediatore: il tutorial potrebbe migliorare la comprensione del prodotto (U), che poi aumenta l’attivazione: T → U → A. U fa parte del meccanismo.
• Collisore: immagina di analizzare solo gli utenti che contattano il supporto (S), dove sia la confusione sia la motivazione aumentano i ticket: U → S ← M. Condizionare su S può creare una connessione fuorviante tra U e M, distorcendo la stima dell’effetto di T su A.

Perché “aggiustare per tutto” può ritorcersi contro

Un riflesso comune nell’analisi è “controllare tutte le variabili disponibili”. In termini di DAG, questo può significare aggiustare per:

• Mediatori (che possono nascondere parte dell’effetto che cerchi di misurare), o
• Collisori (che possono introdurre bias dal nulla).

Con un DAG, aggiusti per le variabili per una ragione—tipicamente per bloccare i percorsi di confondimento—piuttosto che semplicemente perché esistono.

Come schizzare un primo grafo in riunione

Inizia con una lavagna e tre passaggi:

1. Scrivi l’esito a destra (es., attivazione), e la causa proposta a sinistra (es., tutorial).
2. Chiedi: “Cosa rende entrambi più probabili?” (confonditori) e “Cosa sta nel mezzo?” (mediatori).
3. Segna ciò su cui stai condizionando nell’analisi (filtri, coorti, regole di eleggibilità). Quelli spesso nascondono collisori.

Anche un DAG approssimativo allinea prodotto, dati e engineering sulla stessa domanda causale prima di eseguire i numeri.

Interventi: pensare in termini di “Do”, non di “See”

Una grande svolta nel pensiero causale di Judea Pearl è separare osservare qualcosa dall’intervenire su di essa.

Se osservi che gli utenti che abilitano le notifiche hanno una retention migliore, hai imparato un pattern. Ma ancora non sai se le notifiche causano la retention, o se gli utenti coinvolti sono semplicemente più propensi ad attivarle.

Un intervento è diverso: significa che imposti attivamente una variabile a un valore e guardi cosa succede dopo. In termini di prodotto, non è “gli utenti hanno scelto X”, è “abbiamo rilasciato X”.

“Do” vs “See” (senza la matematica)

Pearl spesso etichetta questa differenza così:

• See: “Abbiamo notato che le notifiche sono ON.”
• Do: “Abbiamo impostato le notifiche su ON (o le abbiamo rese default) e ora misuriamo l’effetto.”

L’idea del “do” è sostanzialmente un promemoria mentale che stai rompendo le ragioni abituali per cui una variabile prende un valore. Quando intervieni, le notifiche non sono ON perché gli utenti coinvolti le hanno attivate; sono ON perché hai forzato l’impostazione (o hai fatto un nudge). Questo è il punto: gli interventi aiutano a isolare causa‑effetto.

Gli interventi sono come avvengono realmente le decisioni di prodotto

La maggior parte del lavoro di prodotto è a forma di intervento:

• lancio di feature e cambi UI
• modifiche di policy di ranking o raccomandazione
• aggiornamenti di prezzo e packaging
• regole antifrode, soglie di moderazione o policy di credito

Queste azioni mirano a cambiare gli esiti, non solo a descriverli. Il pensiero causale mantiene la domanda onesta: “Se facciamo questo, cosa cambierà?”

Il trucco: gli interventi richiedono comunque assunzioni

Non puoi interpretare un intervento (o progettare un buon esperimento) senza assunzioni su cosa influisce su cosa—il tuo diagramma causale, anche informale.

Per esempio, se la stagionalità influenza sia la spesa marketing sia le iscrizioni, allora “fare” un cambiamento di spesa senza tener conto della stagionalità può ancora fuorviare. Gli interventi sono potenti, ma rispondono a domande causali solo quando la storia causale sottostante è almeno approssimativamente corretta.

Controfattuali: rispondere al “E se?” per un singolo caso

Un controfattuale è un tipo specifico di domanda “e se?”: per questo caso esatto, cosa sarebbe successo se avessimo preso un’azione diversa (o se un input fosse stato diverso)? Non è “cosa succede in media?”—è “questo risultato sarebbe cambiato per questa persona, questo ticket, questa transazione?”

Perché i team ci tengono: ricorso, equità e support

I controfattuali emergono ogni volta che qualcuno chiede una via per ottenere un risultato diverso:

• Ricorso utente: “Cosa dovrei cambiare per essere approvato?”
• Indagini di equità: “Se questo candidato avesse qualifiche identiche ma un attributo sensibile diverso, la decisione cambierebbe?”
• Support e debugging: “Questo utente dice che il sistema ‘non aveva senso’— quale cambiamento di input avrebbe ribaltato la previsione?”

Queste domande sono a livello utente. Sono anche abbastanza concrete da guidare cambi di prodotto, policy e spiegazioni.

Un esempio concreto per l’AI

Immagina un modello di prestiti che respinge una richiesta. Una spiegazione basata su correlazioni potrebbe dire: “Il basso risparmio è correlato al rifiuto.” Un controfattuale chiede:

Se i risparmi del richiedente fossero stati 3.000$ più alti (per il resto uguale), il modello lo avrebbe approvato?

Se la risposta è “sì”, hai imparato qualcosa di azionabile: una modifica plausibile che capovolge la decisione. Se la risposta è “no”, eviti di dare consigli fuorvianti come “aumenta i risparmi” quando il vero ostacolo è debito/guada‑reddito o impiego instabile.

Il limite chiave: i controfattuali non sono “nei dati”

I controfattuali dipendono da un modello causale—una storia su come le variabili si influenzano—non solo da un dataset. Devi decidere cosa può realisticamente cambiare, cosa cambierebbe di conseguenza e cosa deve restare fisso. Senza quella struttura causale, i controfattuali possono diventare scenari impossibili (“aumenta i risparmi senza cambiare reddito o spese”) e produrre raccomandazioni inutili o ingiuste.

Pensiero causale per affidabilità AI e debugging

Quando un modello ML fallisce in produzione, la causa radice raramente è “l’algoritmo è peggiorato”. Più spesso qualcosa nel sistema è cambiato: i dati che raccogli, come vengono prodotti i label, o il comportamento degli utenti. Il pensiero causale ti aiuta a smettere di indovinare e iniziare a isolare quale cambiamento ha causato il degrado.

Modalità di fallimento comuni (e perché ingannano le metriche)

Alcuni colpevoli ricorrenti appaiono nei team:

• Scorciatoie spurie: il modello impara un proxy facile (watermark, colore di sfondo, formulazione) che è correlato al label in training ma non è il vero segnale.
• Dataset shift: il processo che genera i dati cambia (nuovi segmenti di utenti, nuova UI, stagionalità), quindi la relazione di training non vale più.
• Leakage: le feature includono accidentalmente informazioni a valle del label (o del processo di etichettatura), gonfiando le prestazioni offline.

Questi problemi possono sembrare “ok” nei dashboard aggregati perché la correlazione può restare alta anche quando la ragione per cui il modello è corretto è cambiata.

Come un grafo causale espone la scorciatoia

Un semplice DAG trasforma il debugging in una mappa. Ti costringe a chiedere: questa feature è causa del label, conseguenza di esso, o conseguenza di come lo misuriamo?

Per esempio, se Policy di etichettatura → Feature engineering → Input del modello, potresti aver costruito una pipeline dove il modello predice la policy piuttosto che il fenomeno sottostante. Un DAG rende visibile quel percorso così puoi bloccarlo (rimuovere la feature, cambiare l’instrumentazione o ridefinire il label).

Interventi per il debugging (pensa “cambia X e vedi Y”)

Invece di ispezionare solo le predizioni, prova interventi controllati:

• Modifiche mirate ai dati: sostituisci gli sfondi, rimuovi watermark, perturbare timestamp—poi riesegui l’inferenza.
• Ablazioni: elimina le feature sospette e misura l’impatto causale sugli errori.
• Slice controfattuali: mantieni tutto fisso tranne un fattore (tipo dispositivo, località) per testare la sensibilità.

Checklist: domande causali quando la performance degrada

• Quale cambiamento a monte potrebbe aver causato questo (prodotto, logging, comportamento utente, policy di label)?
• Quali feature potrebbero essere a valle del label o del processo di etichettatura (rischio di leakage)?
• Quale confonditore potrebbe spiegare sia la feature sia l’esito (es., la regione influenza lingua e conversione)?
• Quale intervento possiamo eseguire in sicurezza per isolare il fattore sospetto?
• Se rimuoviamo la scorciatoia, esiste ancora un percorso causale da segnale reale → previsione?

Dalle spiegazioni alle cause: cosa manca alle “explainability” dell’AI

Molti strumenti di “explainability” rispondono a una domanda ristretta: Perché il modello ha prodotto questo punteggio? Spesso lo fanno evidenziando input influenti (importanza delle feature, mappe di salienza, valori SHAP). Questo può essere utile—ma non è la stessa cosa che spiegare il sistema in cui il modello sta.

Spiegare una previsione vs spiegare un sistema

Una spiegazione della previsione è locale e descrittiva: “Questo prestito è stato rifiutato principalmente perché il reddito era basso e l’utilizzo alto.”

Una spiegazione di sistema è causale e operativa: “Se aumentassimo il reddito verificato (o riducessimo l’utilizzo) in modo che rappresenti un intervento reale, la decisione cambierebbe—e gli esiti a valle migliorerebbero?”

La prima aiuta a interpretare il comportamento del modello. La seconda aiuta a decidere cosa fare.

Perché i modelli causali cambiano il significato di “spiegazione”

Il pensiero causale lega le spiegazioni agli interventi. Invece di chiedere quali variabili sono correlate al punteggio, chiedi quali variabili sono leve valide e quali effetti producono quando cambiate.

Un modello causale ti costringe a essere esplicito su:

• Cosa si può intervenire (prezzi, messaggi, soglie, UI)
• Cosa è solo osservato (intenzione dell’utente, condizioni economiche)
• Cosa è confuso (un fattore nascosto che guida input e outcome)

Questo conta perché una feature “importante” può essere un proxy—utile per predizione, pericolosa per l’azione.

Il rischio delle spiegazioni post‑hoc che tracciano correlazione

Le spiegazioni post‑hoc possono sembrare persuasive pur restando puramente correlazionali. Se “numero di ticket di supporto” predice fortemente il churn, un grafico di importanza potrebbe tentare il team a “ridurre i ticket” rendendo il supporto meno accessibile. Quell’intervento potrebbe aumentare il churn, perché i ticket erano un sintomo di problemi di prodotto—not la causa.

Le spiegazioni basate su correlazioni sono anche fragili durante i cambi di distribuzione: quando il comportamento degli utenti cambia, le stesse feature evidenziate possono non significare più la stessa cosa.

Dove le spiegazioni causali ripagano

Le spiegazioni causali sono particolarmente preziose quando le decisioni hanno conseguenze e responsabilità:

• Audit: giustificare decisioni in termini di interventi plausibili e percorsi sensibili all’equità.
• Incident review: separare cause radice da segnali correlati quando qualcosa si rompe.
• QA e monitoring: testare “e se” (soglie, policy, UX) prima di rilasciare e dopo il drift.

Quando devi agire, non solo interpretare, la spiegazione ha bisogno di una struttura causale.

Esperimenti, test A/B e quando non puoi randomizzare

Il test A/B è inferenza causale nella sua forma più semplice e pratica. Quando assegni utenti in modo casuale alla variante A o B, stai eseguendo un intervento: non osservi solo cosa hanno scelto le persone, stai impostando ciò che vedono. In termini di Pearl, la randomizzazione rende reale “do(variant = B)”—così le differenze negli esiti possono essere attribuite alla modifica, non a chi l’ha ricevuta.

Perché la randomizzazione è così potente

L’assegnazione casuale spezza molti legami nascosti tra tratti degli utenti ed esposizione. Power user, nuovi utenti, ora del giorno, tipo di dispositivo—questi fattori esistono ancora, ma sono (in media) bilanciati tra i gruppi. Quel bilanciamento trasforma un gap di metriche in un’affermazione causale.

Quando gli esperimenti sono difficili (o inappropriati)

Anche i team bravi non possono sempre fare test randomizzati puliti:

• Campioni piccoli: basso traffico rende i risultati rumorosi e lenti.
• Effetti a lungo termine: retention, fiducia e churn possono impiegare mesi.
• Interferenza: il trattamento di un utente influisce su un altro (condivisione sociale, dinamiche di marketplace).
• Etica e sicurezza: non puoi testare casualmente esperienze dannose o politiche ingiuste.
• Vincoli operativi: limiti di piattaforma, regole legali o dipendenze da partner.

In questi casi, puoi comunque pensare causalmente—ma devi essere esplicito sulle assunzioni e sull’incertezza.

Alternative quasi‑sperimentali (a livello alto)

Opzioni comuni includono difference‑in‑differences (confrontare cambi nel tempo tra gruppi), regression discontinuity (usare una soglia come “solo utenti con punteggio > X”), strumenti (una spinta naturale che cambia l’esposizione senza cambiare direttamente l’esito) e matching/pesatura per rendere i gruppi più comparabili. Ogni metodo scambia la randomizzazione con assunzioni; un diagramma causale può aiutarti a enunciare chiaramente quelle assunzioni.

Pre‑registra cosa significa “successo”

Prima di lanciare un test (o uno studio osservazionale), scrivi: la metrica primaria, i guardrail, la popolazione target, la durata e la regola decisionale. La pre‑registrazione non elimina i bias, ma riduce il metric shopping e rende le affermazioni causali più affidabili—e più facili da discutere in team.

Decisioni di prodotto migliori con domande causali

La maggior parte dei dibattiti di prodotto suona come: “La metrica X è aumentata dopo che abbiamo lanciato Y—quindi Y ha funzionato.” Il pensiero causale traduce questo in una domanda più chiara: “La modifica Y ha causato lo spostamento della metrica X, e di quanto?” Questo trasforma le dashboard da prova a punto di partenza.

Tre decisioni comuni, riscritte come domande causali

Cambio di prezzo: invece di “Il fatturato è aumentato dopo l’aumento di prezzo?”, chiedi:

• “Qual è l’effetto di aumentare il prezzo del 10% su conversione a pagamento, churn e ticket di supporto, tenendo costante la stagionalità?”

Modifica onboarding: invece di “I nuovi utenti completano più spesso l’onboarding ora,” chiedi:

• “Se accorciamo l’onboarding da 6 a 4 passi, cosa succede all’attivazione e alla retention a 4 settimane per nuovi utenti?”

Cambio ranking di raccomandazione: invece di “La CTR è migliorata,” chiedi:

• “Se riordiniamo i risultati per promuovere la freschezza, qual è l’effetto sulla soddisfazione a lungo termine (ritorni, nascondi, disiscrizioni), non solo sui click?”

Come il confondimento si insinua nelle dashboard

Le dashboard spesso mescolano “chi ha ricevuto la modifica” con “chi sarebbe andato bene comunque”. Un esempio classico: lanci un nuovo flusso di onboarding, ma è mostrato per primo agli utenti con la versione app più recente. Se le versioni più nuove sono adottate da utenti più coinvolti, il tuo grafico può mostrare un aumento dovuto in parte (o completamente) all’adozione della versione, non all’onboarding.

Altri confonditori frequenti in analytics di prodotto:

• Stagionalità e campagne (una promo muove iscrizioni e conversione)
• Cambiamenti nella composizione utenti (più lead enterprise questo mese)
• Carico del supporto (outage aumentano i ticket e riducono retention)

Aggiungi domande causali nei PRD (per mantenere l’allineamento)

Una sezione utile del PRD può intitolarsi letteralmente “Domande causali” e includere:

• Primaria: “Quale cambiamento stiamo facendo e quale esito dovrebbe causare?”
• Guardrail: “Cosa NON dovrebbe peggiorare se funziona?”
• Confonditori: “Cos’altro potrebbe muovere la metrica nello stesso periodo?”
• Piano di misurazione: “Esperimento, holdout, rollout graduale o confronto abbinato?”

Se usi un ciclo di sviluppo rapido (soprattutto con sviluppo assistito da LLM), questa sezione diventa ancora più importante: evita che “possiamo rilasciare velocemente” si trasformi in “abbiamo rilasciato senza sapere cosa ha causato”. I team che costruiscono su Koder.ai spesso inseriscono queste domande causali nella fase di planning e poi implementano varianti feature‑flagged rapidamente, con snapshot/rollback per mantenere sicura la sperimentazione quando i risultati (o gli effetti collaterali) sorprendono.

Allinea PM, data, engineering e support

I PM definiscono la decisione e i criteri di successo. I data partner la traducono in stime causali misurabili e controlli di plausibilità. Engineering assicura che il cambiamento sia controllabile (feature flag, logging pulito dell’esposizione). Support condivide segnali qualitativi—i cambi di prezzo spesso “funzionano” mentre aumentano silenziosamente cancellazioni o ticket. Quando tutti concordano sulla domanda causale, il rilascio diventa apprendimento—not solo deployment.

Un workflow pratico: aggiungi la causalità agli strumenti del team

Il pensiero causale non richiede un rollout da dottorato. Trattalo come un’abitudine di team: scrivi la tua storia causale, mettila alla prova, poi lascia che i dati (e gli esperimenti quando possibile) la confermino o la correggano.

Cosa ti serve (prima di discutere i risultati)

Per fare progressi, raccogli quattro input all’inizio:

• Un grafo: un rapido diagramma causale (DAG) delle variabili chiave.
• Assunzioni: cosa credi che guidi cosa e cosa stai scegliendo di ignorare.
• Fonti dati: da dove viene ogni variabile (log, CRM, survey), più gap noti.
• Piano di validazione: come verificherai le assunzioni (A/B test, esperimento naturale, controlli di sensibilità o revisione di esperti).

Un processo leggero: schizza → critica → testa → iter.

1. Schizza il diagramma più semplice che risponde a una domanda (es., “Le email di onboarding aumenteranno la retention a 4 settimane?”).
2. Critica con il team: analytics, PM, engineering e qualcuno vicino agli utenti.
3. Testa le assunzioni: cerca confondimento, effetti di selezione e “frecce mancanti”. Se possibile, progetta un piccolo esperimento.
4. Itera: aggiorna il diagramma e il piano di misurazione man mano che impari.

Nella pratica, la velocità conta: prima trasformi una domanda causale in un cambiamento controllato, meno tempo perdi a discutere pattern ambigui. Per questo i team adottano piattaforme come Koder.ai per passare da “ipotesi + piano” a un’implementazione strumentata funzionante (web, backend o mobile) in giorni anziché settimane—mantenendo comunque rigore tramite rollout a fasi, deploy e rollback.

Un template di revisione del diagramma causale (copia/incolla)

• Decisione / intervento: Quale azione potremmo intraprendere?
• Esito: Cosa stiamo cercando di cambiare?
• Percorso causale principale: Come arriva l’intervento all’esito?
• Confonditori: Cosa influenza sia intervento sia esito?
• Mediatori: Cosa sta nel mezzo (non controllare questi accidentalmente)?
• Collisori / filtri di selezione: Dove condizionare potrebbe creare relazioni false?
• Note di misurazione: Come sono osservate le variabili; cosa manca o è rumoroso?
• Controllo proposto: Esperimento? Quasi‑esperimento? Analisi di sensibilità?

Se vuoi un ripasso sugli esperimenti, vedi /blog/ab-testing-basics. Per trappole comuni nelle metriche che imitano “effetti”, vedi /blog/metrics-that-mislead.

Punti chiave e prossimi passi

Il pensiero causale è uno spostamento da “cosa tende a muoversi insieme?” a “cosa cambierebbe se intervenissimo?” Quel cambio—reso popolare in computing e statistica da Judea Pearl—aiuta i team a evitare storie convincenti che non reggono quando si interviene davvero.

Riepilogo principale (4–6 righe)

La correlazione è un indizio, non una risposta.

I diagrammi causali (DAG) rendono le assunzioni visibili e discutibili.

Gli interventi (“do”) sono diversi dalle osservazioni (“see”).

I controfattuali aiutano a spiegare casi singoli: “cosa sarebbe successo se questa cosa fosse stata diversa?”

Un buon lavoro causale documenta incertezza e spiegazioni alternative.

Inizia questa settimana: una checklist pratica

• Una riunione (45 minuti): Scegli una domanda importante (es., “Questa feature ridurrà il churn?”) e riscrivila come intervento: “Se facciamo X, cosa cambia in Y?”
• Un diagramma (15–30 minuti): Schizza un DAG semplice su una lavagna: intervento, esito e 3–6 cause probabili che influenzano entrambi. Segna cosa puoi misurare e cosa manca.
• Un test (in questo sprint): Scegli il controllo più fattibile—un test A/B se puoi randomizzare, o un confronto quasi‑sperimentale se non puoi. Decidi in anticipo quale risultato cambierebbe la tua decisione.

Non confondere diagrammi ordinati con verità

La causalità richiede cura: confonditori nascosti, errori di misurazione ed effetti di selezione possono ribaltare le conclusioni. L’antidoto è la trasparenza—scrivi le assunzioni, mostra i dati usati e indica cosa falsificherebbe la tua affermazione.

Se vuoi approfondire, leggi altri articoli su /blog e confronta approcci causali con altri metodi di analytics e “explainability” per capire dove ciascuno aiuta—e dove può fuorviare.