import pandas as pd

Probability: axioms, events, conditioning

Questa lezione tratta la probabilità come una scelta operativa, non come un capitolo di teoria da memorizzare. La categoria è tecnica, ma il punto non è accumulare definizioni: è capire quale decisione cambia quando il dato diventa più affidabile. Parti da una dashboard con due numeri: il 12% degli utenti che visitano la pagina prezzi converte, il 3% degli altri converte. Sembra una storia semplice, finché non arriva la domanda scomoda: gli utenti convertono perché hanno visto la pagina prezzi, oppure visitano quella pagina perché erano già più intenzionati a comprare?

Dal problema alla decisione

Il problema vero non è conoscere la probabilità in astratto. È decidere cosa fare quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Una lezione utile separa il segnale dal rumore, dice quale baseline usare e indica quale azione diventa più difendibile dopo l’analisi.

La probabilità ti costringe a separare eventi, condizioni e assunzioni. Non serve a dire che un numero è alto o basso, serve a chiedere rispetto a quale informazione, dentro quale popolazione, con quale evento già osservato. 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.

Una sequenza di lavoro

Conviene seguire una sequenza fissa, così la nozione tecnica non si trasforma in un rituale vuoto. Ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo meglio la probabilità in gioco?	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

Formalizzare senza complicare

Formalizzare la lezione significa renderla una relazione tra decisione, evidenza e rischio. Non serve a complicare le cose: serve a rendere visibili le assunzioni, così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità.

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

The three Kolmogorov axioms (1933)

Andrey Kolmogorov gave probability a solid mathematical foundation with three simple axioms. For every event A in a sample space Ω:

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)

This is enough to build everything else. Probability is neither "what happens in the long run" (frequentism) nor "degree of belief" (Bayesianism): it is a mathematical measure that satisfies these axioms. How you interpret it is a philosophical choice, not a mathematical one.

Conditional probability: the most powerful concept

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

La domanda è: qual è la probabilità di A, sapendo che B è vero? Guida la maggior parte delle analisi dati:

• P(churn | no_login_30days) = ?
• P(conversion | visited_pricing_page) = ?
• P(fraud | transaction > €10,000 and unusual_country) = ?

Conditional probability is the mechanism ofbelief updating: you start from P(A) (prior probability), observe B, and move to P(A|B) (posterior probability).

Un caso reale è la diagnosi medica e la 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(disease | positive) = P(positive | disease) × P(disease) / P(positive)\n= 0.99 × 0.0001 / (0.99 × 0.0001 + 0.01 × 0.9999)\n≈ 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 vale lo stesso: modelli con alta accuracy su classi sbilanciate (per esempio frodi allo 0.1% delle transazioni) soffrono dello stesso problema. Un modello che dice sempre “nessuna frode” ha accuracy del 99.9%, e questo non significa che funzioni.

Independence: when knowing B tells you nothing about A

A and B are independent if P(A|B) = P(A), that is, 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.

---

References:

• 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.

La probabilità dentro un sistema

In un progetto reale la probabilità non vive isolata. Fa 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 è capire quale problema risolve il metodo, quali assunzioni contiene e cosa succede quando quelle assunzioni non sono vere.

La prima domanda 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. Per impostare il lavoro definisci il problema in linguaggio business, identifica l’unità di analisi corretta (utente, account, evento, sessione, ordine, campagna), controlla se i dati misurano davvero il fenomeno o solo una sua ombra, costruisci una metrica interpretabile, segmenta per evitare che la media nasconda pattern opposti e trasforma il risultato in una raccomandazione verificabile.

Real case: Netflix and the discipline of metrics

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, ma il metodo: il dato non viene trattato come ornamento, viene trattato come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o 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, mostra una soddisfazione implicita più alta. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma danneggiano valore nel lungo periodo. Lo stesso principio vale per la probabilità: il risultato deve essere collegato a un outcome. Se non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

SQL example: building a control view

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea una base analitica con metrica, segmento e finestra temporale, così puoi 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;

La query non pretende di essere la risposta finale. Crea una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui l’analista può formulare ipotesi più precise.

Python example: checking stability and anomalies

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

# 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 un’indagine. In azienda questo tipo di analisi può alimentare alert, review settimanali e retrospettive di prodotto.

Esercizio e lab

Al livello base scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie alla probabilità, indicando metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, la lezione è ancora troppo astratta. Al livello intermedio costruisci una tabella con quattro colonne (segnale osservato, interpretazione prudente, controllo necessario, azione consigliata) e includi almeno un caso in cui il segnale non basta per decidere. Al livello research-grade trasforma l’esercizio in un memo decisionale che includa assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa un export reale, una tabella sintetica, una dashboard interna o un notebook di studio, con almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto.

Common mistakes to avoid

L’errore più tipico è usare la probabilità come etichetta tecnica invece che come criterio di scelta. Succede quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto: il dato sembra preciso, ma non guida l’azione.

Ci sono poi tre errori ricorrenti nell’analisi. Il primo è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato, dato che eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa 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 un gruppo di controllo.

Per allenare la lettura, prova a rispondere a queste domande prima di chiudere un’analisi: quale decisione concreta dovrebbe migliorare, quale unità di analisi rende il problema misurabile, quale baseline useresti per evitare una lettura isolata, quale assunzione cambierebbe la conclusione se fosse falsa e quale controllo presenteresti prima di raccomandare un’azione.

Summary

La probabilità va trattata come strumento decisionale, non come argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non termina con il numero che sale o scende, termina con una frase operativa: quale decisione prendiamo, con quale livello di confidenza e quale metrica useremo per sapere se avevamo ragione. La forma corretta della lezione resta decisione, segnale, baseline, rischio e azione. Tutto il resto serve solo se rende più affidabile uno di questi passaggi.