Probabilità: assiomi, eventi, condizionamento

Hai una dashboard con due numeri: il 12% degli utenti che visitano la pagina prezzi converte, mentre il 3% degli altri converte. Sembra una storia semplice. Poi arriva la domanda scomoda: gli utenti convertono perché hanno visto la pagina prezzi, o visitano quella pagina perché erano già più intenzionati a comprare?

La probabilità ti costringe a separare eventi, condizioni e assunzioni. Non serve per dire “questo numero è alto” o “questo numero è basso”. Serve per chiedere: rispetto a quale informazione? dentro quale popolazione? con quale evento già osservato?

Una scena da cui partire

Leggi questa lezione come un allenamento alla precisione. Ogni volta che dici “probabile”, devi poter indicare evento, condizione e universo di riferimento. Senza questi tre elementi, la probabilità diventa linguaggio vago travestito da matematica.

• Contesto: qual è l’evento che vuoi stimare davvero?
• Metodo: quale informazione stai condizionando e quale stai ignorando?
• Applicazione: quale decisione cambierebbe se la probabilità fosse letta al contrario?

I tre assiomi di Kolmogorov (1933)

Andrey Kolmogorov diede alla probabilità una fondazione matematica solida con tre assiomi semplici. Per ogni evento A in uno spazio campionario Ω:

1. Non negatività: P(A) ≥ 0
2. Normalizzazione: P(Ω) = 1
3. Additività: se A e B sono mutuamente esclusivi, P(A ∪ B) = P(A) + P(B)

Basta questo per costruire tutto il resto. La probabilità non è “ciò che succede nel lungo periodo” (frequentismo) né “grado di credenza” (bayesianismo): è una misura matematica che soddisfa questi assiomi. Come la interpreti è una scelta filosofica, non matematica.

Probabilità condizionale: il concetto più potente

P(A|B) = P(A ∩ B) / P(B), con P(B) >0.

“Qual è la probabilità di A, sapendo che B è vero?” Questa è la domanda che guida la maggior parte delle analisi dati:

• P(churn | no_login_30gg) = ?
• P(conversione | visitato_pagina_prezzi) = ?
• P(frode | transazione >10.000€ e paese_insolito) = ?

La probabilità condizionale è il meccanismo dell’aggiornamento delle credenze: parti da P(A) (probabilità a priori), osservi B, e passi a P(A|B) (probabilità a posteriori).

Caso reale: diagnosi medica e fallacia della probabilità condizionale

Un test per una malattia rara (1 su 10.000) ha accuratezza del 99%. Se risulti positivo, qual è la probabilità di avere davvero la malattia? NON è 99%.

P(malattia | positivo) = P(positivo | malattia) × P(malattia) / P(positivo) = 0.99 × 0.0001 / (0.99 × 0.0001 + 0.01 × 0.9999) ≈ 0.0098 = 0.98%

Un test accurato al 99% ti dà meno dell’1% di probabilità di essere malato se la malattia è rara. Questa è la potenza e la controintuitività della probabilità condizionale.

Nell’analisi dati: modelli con alta accuracy su classi sbilanciate (es. frodi: 0.1% delle transazioni) soffrono dello stesso problema. Un modello che dice “nessuna frode” sempre ha accuracy 99.9%. Non significa che funzioni.

Indipendenza: quando sapere B non ti dice nulla su A

A e B sono indipendenti se P(A|B) = P(A), cioè P(A ∩ B) = P(A) × P(B).

Questa è l’assunzione più usata e più abusata in statistica. I modelli Naive Bayes “assumono” indipendenza tra feature — non perché sia vera, ma perché il modello funziona sorprendentemente bene anche quando l’assunzione è violata.

---

Riferimenti:

• Kolmogorov, A.N. (1933). Foundations of the Theory of Probability. Chelsea Publishing.
• Blitzstein, J.K. & Hwang, J. (2019). Introduction to Probability, 2nd ed. CRC Press.

Approfondimento operativo: leggere ‘probabilità: assiomi, eventi, condizionamento’ come sistema

In un progetto reale, ‘probabilità: assiomi, eventi, condizionamento’ non vive mai isolato. È parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista principiante è trattare il tema come una definizione: imparare il nome, ricordare due formule, applicare un template. Il lavoro professionale è diverso: bisogna capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni non sono vere.

Nel contesto di matematica analisi dati, la prima domanda da fare non è “quale metrica calcolo?” ma: quale decisione dovrà essere presa grazie a questa analisi? Una dashboard, una query o un modello statistico hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.

Un buon modo per impostare il lavoro è usare questa sequenza:

1. definire il problema in linguaggio business;
2. identificare l’unità di analisi corretta: utente, account, evento, sessione, ordine, campagna;
3. controllare se i dati misurano davvero il fenomeno o solo una sua ombra;
4. costruire una metrica interpretabile;
5. segmentare per evitare che la media nasconda pattern opposti;
6. trasformare il risultato in una raccomandazione verificabile.

Caso reale: Netflix e la disciplina delle metriche

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è che ogni azienda debba copiare Netflix. Il punto è metodologico: il dato non viene trattato come ornamento, ma come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza — una nuova riga di raccomandazioni, una diversa immagine di copertina, un algoritmo di ranking — non misura solo il click immediato. Misura anche segnali di qualità: l’utente guarda davvero il contenuto? torna nei giorni successivi? riduce il tempo speso a cercare? aumenta la soddisfazione implicita? Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma danneggiano valore nel lungo periodo.

Lo stesso principio vale qui: ‘probabilità: assiomi, eventi, condizionamento’ deve essere collegato a un outcome. Se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. L’obiettivo è creare una base analitica con metrica, segmento e finestra temporale, così da poter confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

Questa query non pretende di essere la risposta finale. Serve a creare una superficie di osservazione: trend, segmenti, differenze tra canali, variazioni nel tempo. Da qui l’analista può formulare ipotesi più precise.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python possiamo controllare variazioni anomale settimana su settimana.

import pandas as pd

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il valore di questo controllo è pratico: evita di reagire a ogni oscillazione casuale, ma segnala quando una variazione merita investigazione. In un contesto aziendale, questo tipo di analisi può alimentare alert, review settimanali e retrospettive di prodotto.

Errori comuni da evitare

Il primo errore è lavorare su dati aggregati troppo presto. Una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo errore è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione possono produrre conclusioni false. Il terzo errore è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa automaticamente che la feature causi conversione. Potrebbero usarla perché sono già più motivati.

Per ridurre questi rischi, ogni analisi dovrebbe includere almeno tre controlli: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o gruppo di controllo.

Riepilogo

‘Probabilità: assiomi, eventi, condizionamento’ va trattato come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”. Termina con una frase operativa: quale decisione prendiamo, con quale livello di confidenza, e quale metrica useremo per sapere se avevamo ragione.

Problema reale

Nel dominio di matematica per analisi dati, ‘Probabilità: assiomi, eventi, condizionamento’ serve a risolvere questo problema: usare concetti matematici per capire incertezza, struttura e limiti delle analisi. La lezione non va trattata come teoria isolata, ma come un modo per migliorare una scelta concreta con dati, assunzioni esplicite e controlli minimi.

Obiettivo operativo: Comprendere il problema analitico e il contesto decisionale; Applicare esempi, metriche e controlli a casi reali. Se alla fine non sai indicare quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora diventata competenza applicata.

Modello concettuale

Fase	Cosa chiarire	Output
Domanda	Quale scelta reale deve migliorare?	Decisione da prendere
Misura	Quale segnale osservabile rappresenta il problema?	Metrica o dato sorgente
Controllo	Quale baseline rende il risultato interpretabile?	Confronto credibile
Azione	Che cosa cambia dopo l’analisi?	Prossimo passo operativo

Il modello concettuale è intenzionalmente semplice: decisione, dato, controllo, azione. Ogni approfondimento tecnico deve rafforzare almeno uno di questi quattro punti.

Formalizzazione rigorosa

Per rendere ‘Probabilità: assiomi, eventi, condizionamento’ analizzabile, definisci prima l’unità di lavoro: variabile, vettore, distribuzione, funzione, campione o matrice. Poi collega questa unità a una metrica osservabile: errore, distanza, varianza, stabilità, sensibilità e interpretabilità. Infine dichiara la decisione attesa: formalizzazione, controllo di assunzione, calcolo o interpretazione geometrica.

Elemento	Specifica richiesta
Unità di analisi	variabile, vettore, distribuzione, funzione, campione o matrice
Segnale principale	errore, distanza, varianza, stabilità, sensibilità e interpretabilità
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	formalizzazione, controllo di assunzione, calcolo o interpretazione geometrica
Rischio	Scambiare un numero disponibile per una prova sufficiente

La formalizzazione e solida quando un altro analista può riprodurre la logica, criticare le assunzioni e ottenere la stessa decisione partendo dagli stessi dati.

Esempio o caso studio

Il team deve ragionare su eventi incerti: conversione, churn, frode, errore di misura. La probabilità diventa linguaggio operativo quando separa evento, condizione, popolazione osservata e informazione disponibile, evitando conclusioni intuitive ma fragili.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmento
Un segmento cambia più degli altri	La media aggregata nasconde una differenza	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	L’impatto va letto sul margine	Stimare trade-off e sostenibilità

Lab / esercizio

Livello base

Scrivi una scheda di una pagina per ‘Probabilità: assiomi, eventi, condizionamento’: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale e confermato.

Livello intermedio

Costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa e plausibile e quale controllo useresti prima di raccomandare un azione.

Livello research-grade

Prepara un decision memo: ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione.

Dataset e materiali consigliati

Usa dataset numerici, simulazioni, matrici, campioni, notebook e problemi guidati. Se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errore tipico da evitare

L’errore più comune e usare ‘Probabilità: assiomi, eventi, condizionamento’ come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline, o una conclusione senza indicare quale assunzione potrebbe invalidarla.

La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Quiz o checkpoint

1. Quale decisione concreta dovrebbe migliorare questa lezione?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura ingenua?
4. Quale errore tipico potrebbe cambiare la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo operativo

‘Probabilità: assiomi, eventi, condizionamento’ diventa utile quando produce una decisione più chiara, non quando aggiunge terminologia. Usa il framework problema, modello, formalizzazione, esempio, lab e checkpoint per trasformare la lezione in pratica verificabile. Categoria: Tecnico. Difficoltà: advanced. Tempo stimato: 22 min.