import pandas as pd

Test d’ipotesi: logica, non rituale

Il test d’ipotesi non è un timbro di verità. È una procedura per decidere quanto sarebbe sorprendente osservare certi dati se l’ipotesi nulla fosse ragionevole. Usato bene, protegge il team da entusiasmi prematuri; usato male, dà una patina scientifica a decisioni già prese. La categoria della lezione è tecnica, quindi conta capire quale decisione cambia quando il dato diventa più affidabile, non accumulare definizioni.

Il problema da risolvere

Conoscere il test in astratto serve a poco. Il problema vero è 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.

Pensa a un A/B test che arriva in riunione con un p-value sotto soglia. Qualcuno dice “abbiamo vinto”. Qualcun altro chiede quante metriche sono state guardate, se il test è stato fermato prima del previsto e se l’effetto è abbastanza grande da valere una release. La discussione cambia subito qualità. Per questo conviene leggere la lezione cercando la logica, non il rituale: le formule contano, ma contano ancora di più le condizioni, cioè ipotesi predefinite, metrica primaria, potenza, campione, stopping rule e costo degli errori.

Una mappa di lavoro

Per non trasformare una nozione tecnica in un rituale vuoto, conviene seguire una sequenza fissa. Ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se capiamo meglio il test d’ipotesi?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

La domanda iniziale 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.

Formalizzazione rigorosa

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

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	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

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

La struttura logica del test

1. Ipotesi nulla (H₀): lo stato di default, l’assenza di effetto. “La variante B NON è diversa da A.”
2. Ipotesi alternativa (H₁): ciò che sospetti. “B è migliore di A.”
3. Statistica test: una funzione dei dati che misura la discrepanza tra ciò che osservi e H₀. (es. t-statistic)
4. p-value: P(statistica test almeno così estrema | H₀ vera). NON è P(H₀ vera | dati).
5. Livello di significatività α: soglia predefinita. Se p < α, rifiuti H₀.

La logica è popperiana: cerchi di falsificare H₀. Se i dati sono troppo improbabili sotto H₀, concludi che H₀ è probabilmente falsa e accetti provvisoriamente H₁.

Errori di Tipo I e Tipo II

	H₀ vera	H₀ falsa
Non rifiuto H₀	OK (1-α)	Errore Tipo II (β)
Rifiuto H₀	Errore Tipo I (α)	OK (1-β, potenza)

L’errore di Tipo I significa gridare “al lupo!” quando non c’è, cioè un falso positivo. L’errore di Tipo II significa non vedere il lupo quando c’è, cioè un falso negativo. In molti contesti di business l’errore di Tipo I è tollerabile, perché testare una modifica innocua costa poco, mentre in medicina è catastrofico. La scelta di α riflette il costo relativo dei due errori, non è un dogma.

I peccati capitali del p-value

1. p-hacking: provi molte segmentazioni, tieni quella con p<0.05.
2. HARKing (Hypothesizing After Results are Known): formuli l’ipotesi DOPO aver visto i dati.
3. Peeking: guardi il test ogni giorno, lo fermi quando p<0.05.
4. Confondere significatività con dimensione dell’effetto: p<0.001 non significa effetto grande.
5. Confondere p-value con probabilità dell’ipotesi: p=0.03 NON significa “probabilità del 3% che H₀ sia vera.”

Per un test onesto la checklist è questa:

• Ipotesi formulata PRIMA di vedere i dati
• Una primary metric dichiarata a priori
• Sample size calcolata a priori (power analysis)
• Correzione per test multipli (Bonferroni, FDR)
• Riportare sempre dimensione dell’effetto e intervallo di confidenza

---

Riferimenti:

• Wasserstein, R.L. & Lazar, N.A. (2016). “The ASA Statement on p-Values.” The American Statistician, 70(2).
• Neyman, J. & Pearson, E.S. (1933). “On the Problem of the Most Efficient Tests of Statistical Hypotheses.” Phil. Trans. R. Soc. Lond. A.

Il test dentro un sistema più ampio

In un progetto reale il test d’ipotesi non vive mai isolato. È parte di un sistema 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, perché bisogna capire quale problema risolve il metodo, quali assunzioni contiene e cosa succede quando quelle assunzioni non sono vere.

Un buon modo per impostare il lavoro segue 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.

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 che il dato non viene trattato come ornamento bensì come infrastruttura decisionale. Quando Netflix valuta una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato: misura anche se l’utente guarda davvero il contenuto, se torna nei giorni successivi, se riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma danneggiano valore nel lungo periodo. Lo stesso vale qui: il test deve essere collegato a un outcome, altrimenti 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 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.

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

Esercizio guidato

Comincia dal livello base: scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie al test d’ipotesi, 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. Usa almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade trasforma l’esercizio in un memo decisionale che include assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Per i dati usa un export reale, una tabella sintetica, una dashboard interna o un notebook di studio: serve almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto.

Come autovalutazione, prova a rispondere: quale decisione concreta dovrebbe migliorare questa lezione, quale unità di analisi rende il problema misurabile, quale baseline eviterebbe una lettura isolata, quale assunzione se falsa cambierebbe la conclusione, e quale controllo presenteresti prima di raccomandare un’azione.

Errori comuni da evitare

L’errore più frequente è usare il test d’ipotesi 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. In quel caso il dato sembra preciso, ma non guida l’azione. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Ci sono poi tre trappole ricorrenti nell’analisi dei dati. La prima è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. La seconda è non controllare la qualità del dato, dato che eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. La terza è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa che la feature causi conversione, perché potrebbero usarla proprio perché sono già più motivati. Per ridurre questi rischi, ogni analisi dovrebbe includere almeno la definizione esplicita della metrica, il confronto per segmento e la verifica contro un periodo precedente o gruppo di controllo.

Riepilogo

Il test d’ipotesi 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”, ma 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 è decisione, segnale, baseline, rischio e azione, e tutto il resto serve solo se rende più affidabile uno di questi passaggi.