import pandas as pd

Modellazione dati per warehouse

La modellazione dati per warehouse è una scelta operativa, non un esercizio di eleganza. La stessa domanda, “quanti clienti attivi abbiamo?”, cambia risposta a seconda che il grain sia utente, account, contratto o workspace. La modellazione serve a rendere queste scelte visibili prima che entrino in dashboard e KPI, e lavora su fatti, dimensioni e definizioni che reggono nel tempo. Il punto non è accumulare definizioni, ma capire quale decisione cambia quando il dato diventa più affidabile.

Quando il problema diventa concreto

Il problema non è conoscere la modellazione in astratto, ma decidere cosa fare quando il grain è ambiguo, quando due tabelle danno risposte diverse alla stessa domanda o quando un join genera doppi conteggi che nessuno aveva previsto. Conviene leggere ogni scelta chiedendosi quale processo genera il fatto, quale entità lo descrive e quale domanda deve restare semplice. Un modello buono non è quello con più tabelle eleganti, ma quello che impedisce join ambigui, doppi conteggi e metriche instabili.

Come ragionare sulla scelta

La sequenza utile parte dalla decisione e finisce con un controllo. Prima chiarisci cosa cambia se il modello migliora, poi quale segnale osservabile riduce l’incertezza, rispetto a quale baseline leggi il risultato, cosa può falsare la lettura e infine quale passo operativo segue.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se modelliamo meglio i dati?	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

Ogni passaggio rende più chiaro il costo di una decisione di modellazione sbagliata, che di solito si paga mesi dopo, quando le metriche divergono.

La gerarchia della modellazione

Un modello maturo si costruisce a strati, e ogni strato ha un compito preciso. Il livello staging, o raw, è la copia 1:1 delle tabelle sorgente, come arrivano, senza trasformazioni. Il livello cleansed applica pulizia, standardizzazione e deduplicazione: i dati sono corretti ma ancora normalizzati. Il livello dimensional, lo star schema, contiene fatti e dimensioni ed è il modello che il business interroga. Il livello aggregated tiene summary table pre-calcolate per le query frequenti.

Fact table: granularità e tipi

La decisione più importante è la granularità: cosa rappresenta UNA riga nella fact table. Una fact table transactional ha una riga per evento, per esempio sales_fact con una riga per ogni item venduto in ogni transazione, e offre massimo dettaglio e massima flessibilità. Una periodic snapshot ha una riga per periodo, per esempio inventory_snapshot con una riga per prodotto per giorno: meno dettaglio, query più veloci. Una accumulating snapshot ha una riga per evento con molte date, per esempio order_fulfillment con order_date, ship_date e deliver_date, utile per l’analisi di funnel e pipeline.

Anche le misure hanno tipi diversi e vanno trattate di conseguenza. Le misure additive si sommano su tutte le dimensioni, come amount. Le semi-additive si sommano su alcune dimensioni ma non su altre, come l’inventory level, che sommi per prodotto ma non per data. Le non-additive non si possono sommare affatto, come price o rate.

Dimensioni: conformed e degenerate

Una conformed dimension è usata da più fact table, per esempio dim_date condivisa da sales_fact e inventory_fact, e garantisce coerenza tra analisi cross-dominio. Una degenerate dimension invece vive dentro la fact table senza una tabella propria: order_number è un identificatore che non ha attributi suoi, ma serve per raggruppare. Tenere chiara questa distinzione evita di proliferare dimensioni inutili e di perdere coerenza tra report.

Gestire le gerarchie

Un cliente appartiene a una città, che appartiene a una regione, che appartiene a un paese. Ci sono due approcci. Lo snowflake usa tabelle separate per ogni livello, dim_city, dim_region, dim_country: accademicamente puro, ma con query complesse. Lo star denormalizzato mette tutto in dim_customer, con city, region e country nella stessa tabella: query semplici e ridondanza controllata. Lo star denormalizzato resta preferito nel 90% dei casi reali, perché la semplicità delle query vale più della purezza dello schema.

Leggere la modellazione come sistema

In un progetto reale la modellazione 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 alle prime armi è trattare il tema come una definizione: imparare il nome, ricordare due regole, applicare un template. Il lavoro professionale è diverso, perché bisogna capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni non valgono.

La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico. Un buon modo per impostare il lavoro è definire il problema in linguaggio business, identificare l’unità di analisi corretta tra utente, account, evento, sessione, ordine o campagna, controllare se i dati misurano davvero il fenomeno o solo una sua ombra, costruire una metrica interpretabile, segmentare per evitare che la media nasconda pattern opposti e trasformare il risultato in una raccomandazione verificabile.

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, ma che il dato non viene trattato come ornamento, bensì 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. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma distruggono valore nel lungo. Lo stesso vale per la modellazione, che deve essere collegata a un outcome: se il modello non aiuta a scegliere tra due azioni alternative, è incompleto.

Esempio SQL: una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea 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 fatta di trend, segmenti, differenze tra canali e 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 un’indagine. In azienda questo tipo di analisi alimenta alert, review settimanali e retrospettive di prodotto.

Esercizio

Al livello base scrivi una scheda di una pagina sul modello che stai progettando: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale è confermato. Al livello intermedio costruisci una tabella con tre segmenti, periodi o scenari, e per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione. Al livello research-grade prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio.

Per i dati usa warehouse, SQL, modelli dimensionali, dati ordini, eventi e tabelle anagrafiche. 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. Un caso pratico realistico è modellare revenue, usage e rinnovi per un’analisi SaaS: la scelta critica è separare fatto transazionale, snapshot mensile e dimensioni lentamente variabili, così che una domanda sull’MRR non venga risolta ogni volta con una query diversa.

L’errore tipico

L’errore più comune è usare la modellazione 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.

Tre errori di analisi ricorrono spesso. 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: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità, perché se gli utenti che usano una feature convertono di più non significa che la feature causi conversione. Per ridurre questi rischi ogni analisi dovrebbe includere una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Riepilogo

La modellazione dati va trattata come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando le scelte di grain, fatti e dimensioni restano stabili abbastanza da reggere nel tempo. 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.

---

Riferimento: Kimball, R. & Ross, M. (2013). The Data Warehouse Toolkit, 3rd ed. Wiley.