Python for data analysis and dashboard

Questa lezione, sul binario ml-tabellare, ti porta dall’altra parte del banco: invece di interrogare dati con SQL, li lavori a tu per tu con Python, dall’analisi esplorativa al prototipo di dashboard.

Che cosa fa Python in questo contesto

Python per dashboard automatizza pulizia, controlli statistici e prototipi visivi su tabelle analitiche riproducibili. In pratica: ciò che una volta facevi con dieci notebook fragili, ora diventa un flusso riproducibile e controllato.

La sequenza da seguire

1. Carica la vista aggregata per utente, segmento e settimana con tipi e fusi orari verificati.
2. Calcola variazioni settimana su settimana con medie mobili e deviazioni standard mobili.
3. Isola le anomalie con soglie statistiche e confrontale per segmento prima di segnalarle.
4. Consegna grafico, tabella e nota interpretativa con baseline e data di refresh.

La vista di controllo che tiene tutto fermo

La base analitica aggrega gli eventi per utente, segmento e finestra temporale. Così confronti periodi e gruppi senza riscrivere la logica, perché ogni riga espone metrica, segmento e settimana di riferimento con definizioni stabili.

Campo	Description
user_id	Identificativo utente
account_id	Identificativo account
event_type	Tipo di evento
week	Settimana di riferimento con troncamento data
source	Canale o fonte dell’evento
device_type	Tipo di dispositivo
total_events	Numero totale di eventi
active_days	Giorni attivi con eventi
event_diversity	Diversità di eventi
reached_key_outcome	Indicatore di raggiungimento di un obiettivo chiave

Con questa struttura monitori trend, segmenti e anomalie senza riscrivere le query di base a ogni domanda.

Verdetto: una sola vista di controllo versionata batte dieci notebook non riproducibili.

Il flusso di lavoro in codice

Il primo passo è caricare la vista e verificare i tipi prima di qualsiasi calcolo. Il secondo è costruire la serie settimanale per segmento. Il terzo è calcolare media mobile e deviazione standard mobile su finestra di quattro settimane. Il quarto è marcare le anomalie con lo z-score.

import pandas as pd

df = pd.read_parquet("vista_controllo.parquet")
df["week"] = pd.to_datetime(df["week"])

weekly = (
    df.groupby(["segment", "week"])["total_events"]
    .sum()
    .reset_index()
    .sort_values(["segment", "week"])
)

weekly["mean_4w"] = weekly.groupby("segment")["total_events"].transform(
    lambda s: s.rolling(4, min_periods=4).mean()
)
weekly["std_4w"] = weekly.groupby("segment")["total_events"].transform(
    lambda s: s.rolling(4, min_periods=4).std()
)
weekly["z_score"] = (weekly["total_events"] - weekly["mean_4w"]) / weekly["std_4w"]

anomalie = weekly[weekly["z_score"].abs() > 2.5]

La soglia 2,5 su z_score non è un numero magico: va dichiarata prima di guardare i dati e va riportata nella nota interpretativa. Con una finestra di quattro settimane, una settimana anomala sposta la media mobile solo per un quarto del suo peso, quindi il segnale non si auto-cancella.

Separare il segnale dal rumore

Una metrica utile è stabile e sensibile insieme: le due proprietà sembrano opposte ma convivono. Le variazioni settimana su settimana con finestra mobile a quattro settimane separano il rumore dalle variazioni che meritano indagine. Lo z-score è la distanza dal comportamento atteso misurata in deviazioni standard: calcolato su finestra mobile, segnala le anomalie senza reagire a ogni oscillazione casuale. Ogni alert rimanda alla definizione della metrica e al segmento colpito.

Un esempio con numeri. Un segmento ha una media mobile di 1.000 eventi a settimana con deviazione standard mobile di 80. Una settimana a 1.300 eventi produce uno z-score di 3,75, oltre la soglia: merita indagine. Una settimana a 1.050 produce uno z-score di 0,63: è rumore, e segnalarla brucerebbe attenzione. La stessa soglia applicata a un segmento piccolo, con media 100 e deviazione 15, segnalerebbe una settimana a 150 eventi: lo z-score normalizza la scala, ma la decisione su cosa indagare resta umana.

Gli errori che falsano le conclusioni

Tre errori ricorrono spesso. L’aggregazione troppo precoce nasconde segmenti che si muovono in direzioni opposte. Duplicati, tracking incompleto e incoerenze temporali falsano qualsiasi conclusione se non controllati prima. E correlazione e causalità restano distinte: un’associazione tra due numeri non dimostra che una feature causi l’effetto osservato. Ogni analisi porta con sé definizione esplicita della metrica, confronto per segmento e verifica contro periodo precedente o gruppo di controllo.

Come riconoscere che stai sbagliando: se il grafico mostra un picco e nessuno sa dire quale segmento lo ha generato, hai aggregato troppo presto. Se due run dello stesso script danno totali diversi, hai un problema di duplicati o di finestra temporale, non di codice. Se la nota interpretativa dice “probabilmente la feature ha funzionato” senza un gruppo di controllo, stai confondendo associazione e causalità.

La consegna che fa la differenza

Il prodotto finale non è il grafico, è il pacchetto: grafico, tabella e nota interpretativa. La nota dice quale metrica è stata usata, quale baseline, quale soglia, quale segmento è stato colpito e quando i dati saranno aggiornati. Senza data di refresh, chi legge non sa se il numero è di ieri o di tre mesi fa. Senza baseline, non sa se il valore è alto o basso. La consegna si considera completa solo quando un collega può ricostruire la logica senza chiederti nulla.

La storia dietro lo strumento più usato

Nel 2008 Wes McKinney, analista del fondo AQR Capital, inizia a scrivere pandas perché gli strumenti disponibili non trattano bene le serie temporali finanziarie. Il progetto diventa open source nel 2009 e insieme a NumPy del 2006 e scikit-learn del 2010 forma la base su cui gira ancora oggi quasi tutta l’analisi dati in Python. La storia spiega il criterio di scelta degli strumenti: vince chi risolve dataframe etichettati e allineamento temporale meglio delle alternative, non chi è più elegante.

Domande per controllare la tua analisi

1. Quale vista di controllo alimenta la tua analisi Python?
2. Quale soglia statistica separa il rumore dalle anomalie vere?
3. Quale segmentazione evita che la media nasconda pattern opposti?
4. Quale controllo di qualità esegui prima di pubblicare un grafico?
5. Quale baseline e quale data di refresh accompagnano la tua consegna?