Scopri come i modelli causali di Judea Pearl aiutano i team a spiegare il comportamento dell'IA, debuggare i guasti e prendere decisioni di prodotto più chiare oltre le correlazioni.
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.
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:
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.
Questo articolo si concentra su tre aree pratiche dove il riconoscimento di pattern spesso fallisce:
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:
Se hai mai rilasciato una modifica che “sembrava buona nei dati” ma non ha funzionato nella realtà, il pensiero causale è il tassello mancante.
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.
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.
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.
Questi strumenti hanno dato ai team un linguaggio condiviso per passare dal riconoscere pattern a rispondere a domande causali con chiarezza e disciplina.
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à.
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.
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’è.
Se ti senti a chiedere:
quando il verbo è cambiare, lanciare, rimuovere o ridurre, la correlazione è un indizio iniziale—non la regola decisionale.
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.
Lo scopo non è la verità perfetta; è una bozza condivisa di “come pensiamo funzioni il sistema” che tutti possono criticare.
Supponiamo di valutare se un nuovo tutorial di onboarding (T) aumenta la attivazione (A).
Un riflesso comune nell’analisi è “controllare tutte le variabili disponibili”. In termini di DAG, questo può significare aggiustare per:
Con un DAG, aggiusti per le variabili per una ragione—tipicamente per bloccare i percorsi di confondimento—piuttosto che semplicemente perché esistono.
Inizia con una lavagna e tre passaggi:
Anche un DAG approssimativo allinea prodotto, dati e engineering sulla stessa domanda causale prima di eseguire i numeri.
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”.
Pearl spesso etichetta questa differenza così:
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.
La maggior parte del lavoro di prodotto è a forma di intervento:
Queste azioni mirano a cambiare gli esiti, non solo a descriverli. Il pensiero causale mantiene la domanda onesta: “Se facciamo questo, cosa cambierà?”
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.
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?”
I controfattuali emergono ogni volta che qualcuno chiede una via per ottenere un risultato diverso:
Queste domande sono a livello utente. Sono anche abbastanza concrete da guidare cambi di prodotto, policy e spiegazioni.
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.
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.
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.
Alcuni colpevoli ricorrenti appaiono nei team:
Questi problemi possono sembrare “ok” nei dashboard aggregati perché la correlazione può restare alta anche quando la ragione per cui il modello è corretto è cambiata.
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).
Invece di ispezionare solo le predizioni, prova interventi controllati:
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.
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.
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:
Questo conta perché una feature “importante” può essere un proxy—utile per predizione, pericolosa per l’azione.
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.
Le spiegazioni causali sono particolarmente preziose quando le decisioni hanno conseguenze e responsabilità:
Quando devi agire, non solo interpretare, la spiegazione ha bisogno di una struttura causale.
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.
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.
Anche i team bravi non possono sempre fare test randomizzati puliti:
In questi casi, puoi comunque pensare causalmente—ma devi essere esplicito sulle assunzioni e sull’incertezza.
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.
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.
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.
Cambio di prezzo: invece di “Il fatturato è aumentato dopo l’aumento di prezzo?”, chiedi:
Modifica onboarding: invece di “I nuovi utenti completano più spesso l’onboarding ora,” chiedi:
Cambio ranking di raccomandazione: invece di “La CTR è migliorata,” chiedi:
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:
Una sezione utile del PRD può intitolarsi letteralmente “Domande causali” e includere:
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.
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.
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.
Per fare progressi, raccogli quattro input all’inizio:
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.
Se vuoi un ripasso sugli esperimenti, vedi /blog/ab-testing-basics. Per trappole comuni nelle metriche che imitano “effetti”, vedi /blog/metrics-that-mislead.
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.
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.
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.
La correlazione ti aiuta a predire o rilevare (ad es., “quando X aumenta, Y spesso aumenta”). La causalità risponde a una domanda decisionale: “Se cambiamo X intenzionalmente, Y cambierà?”
Usa la correlazione per forecasting e monitoraggio; usa il pensiero causale quando stai per lanciare una modifica, definire una policy o allocare budget.
Perché la correlazione può essere guidata da confondimento. Nell’esempio delle notifiche, gli utenti molto coinvolti sia generano/ricevono più notifiche sia tornano più spesso.
Se aumenti le notifiche per tutti, cambi l’esperienza (un’intervento) senza cambiare l’engagement di base—quindi la retention potrebbe non migliorare e può perfino peggiorare.
Un DAG (Directed Acyclic Graph) è un diagramma semplice dove:
È utile perché rende esplicite le assunzioni, aiutando il team a decidere cosa aggiustare, cosa non aggiustare e quale esperimento risponderebbe davvero alla domanda.
Un errore comune è “controllare tutto”, che può accidentalmente aggiustare per mediatori o collisori e introdurre bias.
“See” è osservare ciò che è accaduto naturalmente (gli utenti si sono attivati, un punteggio era alto). “Do” è impostare attivamente una variabile (rilasciare una funzionalità, forzare un default).
L’idea chiave: un intervento rompe le solite ragioni per cui una variabile assume un valore, e per questo può rivelare causa‑effetto più affidabilmente dell’osservazione da sola.
Un controfattuale chiede: per questo caso specifico, cosa sarebbe successo se avessimo fatto qualcosa di diverso.
È utile per:
Richiede un modello causale, altrimenti potresti proporre cambi impossibili.
Concentrati su cosa è cambiato a monte e su cosa il modello potrebbe sfruttare:
Una mentalità causale ti spinge a testare interventi mirati (ablazioni, perturbazioni) invece di inseguire movimenti di metriche coincidenti.
Non sempre. L’importanza delle feature spiega cosa ha influenzato la previsione, non cosa dovresti cambiare.
Una feature molto “importante” può essere un proxy o un sintomo (es., i ticket di supporto predicono il churn). Intervenire sul proxy (“ridurre i ticket rendendo il supporto meno accessibile”) può ritorcersi contro. Le spiegazioni causali collegano l’importanza a leve valide e agli effetti attesi sotto intervento.
I test A/B randomizzati sono l’ideale quando possibile, perché l’assegnazione casuale simula “do(variant = B)” e rende credibile attribuire le differenze all’intervento.
Se non puoi randomizzare, considera approcci quasi-sperimentali (difference-in-differences, regression discontinuity, strumenti, matching/pesatura) e sii esplicito sulle assunzioni.
Aggiungi una sezione breve che richieda chiarezza prima dell’analisi:
Questo mantiene il team allineato su una domanda causale invece che su narrazioni post-hoc basate sui dashboard.
