import pandas as pd

Caso studio: costruire un data warehouse

Questo caso costruisce un warehouse partendo da sorgenti operative disordinate: eventi prodotto, pagamenti, CRM e anagrafiche account. L’obiettivo non è solo caricare tabelle, ma creare layer, modelli e metriche che altri team possano usare senza reinterpretare tutto da capo. Leggilo come una review end-to-end che attraversa ingestione, staging, core model, mart, test, documentazione e accesso. Ogni scelta dovrebbe chiarire quale domanda diventa più semplice e quale rischio viene controllato.

Il problema vero

Il problema non è conoscere il data warehousing in astratto, ma decidere cosa fare quando hai dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura di un fenomeno. Una base analitica utile separa il segnale dal rumore e indica quale azione diventa più difendibile dopo l’analisi. La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questi dati: se non cambia una scelta, una dashboard è solo documentazione o teatro analitico.

Come ragionare sul progetto

Conviene tenere a mente una sequenza che lega la decisione al dato e al rischio, così una scelta tecnica non diventa un rituale vuoto. Ogni passaggio dovrebbe rendere più chiaro quanto costa una decisione sbagliata.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se il warehouse è progettato bene?	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

Rendere esplicite le assunzioni

Una formalizzazione minima rende visibili le assunzioni, così uno stakeholder può discutere il criterio invece di fidarsi del risultato per autorità. Definisci l’unità di analisi, la variabile osservata, la baseline, la soglia che fa cambiare l’azione e il rischio che resta.

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

Fase 1: requisiti di business

Tutto parte dalle domande degli stakeholder, perché lo schema deve rispondere a loro. Il CFO vuole revenue e margine per negozio, categoria e mese. Il Category Manager chiede quali prodotti vendono di più per regione e quali sono in declino. Il Marketing vuole sapere chi sono i clienti del top 20% e qual è la loro frequenza di acquisto.

Fase 2: progettazione dello star schema

Al centro c’è la fact table sales_fact, con granularità di una riga per item venduto in ogni scontrino. Le misure sono quantity, amount, cost e margin, mentre le foreign key sono date_key, store_key, product_key, customer_key e transaction_id come degenerate dimension.

Attorno ci sono quattro dimensioni. La dim_product porta product_name, category, subcategory, brand e package_size. La dim_store raccoglie store_name, city, region, country e opening_date. La dim_customer, alimentata dal CRM della loyalty card, contiene customer_name, signup_date, segment, city e age_group. La dim_date espone date, year, month, quarter, day_of_week e is_holiday.

Fase 3: query di validazione

Prima di considerare lo schema affidabile, lo metti alla prova con le domande di business reali.

-- Revenue mensile per categoria
SELECT d.year, d.month, p.category,
       SUM(s.amount) AS revenue, SUM(s.margin) AS margin
FROM sales_fact s
JOIN dim_date d ON s.date_key = d.date_key
JOIN dim_product p ON s.product_key = p.product_key
GROUP BY d.year, d.month, p.category;

-- Top 20% clienti (per revenue)
SELECT c.customer_id, c.customer_name,
       SUM(s.amount) AS total_spent,
       NTILE(5) OVER (ORDER BY SUM(s.amount) DESC) AS quintile
FROM sales_fact s JOIN dim_customer c ON s.customer_key = c.customer_key
GROUP BY c.customer_id, c.customer_name;

Fase 4: evoluzione futura

Lo schema iniziale è una base, non un punto d’arrivo. Più avanti puoi aggiungere una dim_supplier per le analisi di supply chain, una fact table inventory_snapshot per lo stock e materializzare le aggregazioni per dashboard con refresh <1 secondo. La consegna minima del progetto resta però chiara: uno star schema con una fact table e quattro dimensioni disegnato, almeno tre query di business funzionanti e un documento di design che spieghi granularità e logica ETL.

Il warehouse come parte del sistema

In un progetto reale il warehouse non vive mai isolato. 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 da memorizzare. Il lavoro vero è capire quale problema risolve una certa scelta di modellazione, quali assunzioni porta con sé e cosa succede quando quelle assunzioni saltano. Un buon modo per impostare il lavoro è seguire una sequenza ordinata:

1. definire il problema in linguaggio business;
2. identificare l’unità di analisi corretta tra 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.

Cosa insegna la disciplina di Netflix

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. Non si tratta di copiare Netflix. Il punto è metodologico: il dato non è ornamento, è infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, che sia una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Guarda 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 periodo ma erodono valore nel lungo. Lo stesso vale per il warehouse: ogni tabella e ogni mart deve essere collegato a un outcome, altrimenti l’analisi resta incompleta.

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ì 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 è la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da lì l’analista formula ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare cambiamenti reali. In Python puoi controllare le 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 è pratico: eviti di reagire a ogni oscillazione casuale, ma ti accorgi quando una variazione merita un’indagine. In azienda questo tipo di controllo alimenta alert, review settimanali e retrospettive di prodotto.

Lab ed esercizi

Al livello base scrivi una scheda di una pagina sul tuo warehouse: 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, indicando per ciascuno 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. Come materiali usa warehouse, SQL, modelli dimensionali, dati ordini, eventi e tabelle anagrafiche; se non hai dati reali, generane uno con almeno 200 righe, una dimensione temporale, una di segmento e una metrica di outcome.

Un caso concreto: il team deve consegnare un warehouse per metriche SaaS comuni come activation, MRR, churn, expansion e usage. Prima di pubblicare dashboard che sembrano autorevoli ma non hanno fondamenta condivise, deve definire grain, layer, test e mart finali.

Errori comuni da evitare

L’errore più frequente è usare il warehouse come etichetta invece che come processo: si mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza dire quale assunzione potrebbe invalidarla. 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.

Sul piano dei dati tornano gli stessi tre inciampi. Aggregare troppo presto, perché una media globale nasconde due segmenti che vanno in direzioni opposte. Non controllare la qualità, perché eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Confondere correlazione e causalità. Per ridurre questi rischi, ogni analisi dovrebbe avere almeno tre controlli: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Riepilogo

Il caso studio va trattato come uno strumento decisionale, non come un esercizio di modellazione fine a se stesso. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non finisce con “il numero è salito” o “è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione. La forma corretta resta sempre la stessa, decisione, segnale, baseline, rischio e azione, e tutto il resto serve solo se rende più affidabile uno di questi passaggi.