import pandas as pd

Progetto: infrastruttura dati completa

Questo caso studio parte da un ambiente dati che funziona finché resta piccolo: script lanciati a mano, costi che nessuno attribuisce, alert assenti e deploy fatti con cautela perché nessuno sa davvero cosa potrebbe rompersi. Il progetto consiste nel trasformare quel sistema in una piattaforma con owner chiari, controlli e rituali operativi. Va letto come una sequenza di decisioni infrastrutturali: cosa gestire, cosa comprare, cosa monitorare, cosa automatizzare e cosa documentare. La qualità del progetto si vede quando un incidente può essere diagnosticato senza ricostruire tutto da zero.

Il problema da risolvere

Il punto non è conoscere l’architettura dati in astratto. Il punto è decidere cosa fare quando il team ha dati incompleti, costi non attribuiti e vincoli tecnici che rendono fragile l’intero sistema. Una buona progettazione separa ciò che va presidiato subito da ciò che può aspettare, dichiara rispetto a quale baseline misura il miglioramento e indica quale azione diventa difendibile dopo l’analisi.

Nel contesto dell’infrastructure ops, la prima domanda non è quale metrica calcolare, ma quale decisione dovrà essere presa grazie a quel dato. Una dashboard, una query o un alert hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.

Una mappa per impostare il progetto

Conviene seguire una sequenza che lega ogni scelta infrastrutturale a un esito misurabile, invece di accumulare strumenti.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se la piattaforma è progettata 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

La sequenza serve a non trasformare la progettazione in un rituale vuoto: ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Rendere visibili le assunzioni

Per rendere analizzabile il progetto, definisci prima l’unità di lavoro, che qui è il job, la pipeline, il servizio, l’alert, il deploy o la risorsa cloud. Poi collega quell’unità a una metrica osservabile come SLA, MTTR, costo, failure rate, freshness e qualità dati. Infine dichiara la decisione attesa, che può essere un runbook, un alert, una policy di costo, una pipeline CI/CD o un piano di recovery.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	Job, pipeline, servizio, alert, deploy o risorsa cloud	Definizione stabile e tracciabile
Variabile osservata	SLA, MTTR, costo, failure rate, freshness	Definizione condivisa con il team
Baseline	Periodo precedente, benchmark o scenario controfattuale	Confronto credibile
Soglia decisionale	Punto in cui scatta un alert o un intervento	Criterio scritto prima dell’incidente
Rischio residuo	Errore che resta anche dopo il presidio	Sensitivity check o revisione

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

I requisiti degli stakeholder

Il caso parte da richieste reali e tra loro in tensione, che la piattaforma deve soddisfare insieme.

• CEO: report mensile di revenue e profitto per paese entro 3 giorni dalla fine del mese.
• Marketing: dashboard di campagne in tempo reale, con meno di 5 minuti di delay e ROAS per canale.
• Prodotto: funnel di conversione e retention D30 per coorte.
• Finance: riconciliazione delle transazioni con il gateway di pagamento.
• Compliance: GDPR, con dati EU conservati solo in data center EU.

Cosa devi consegnare

Il deliverable del progetto è un disegno completo che risponde a cinque domande.

1. Architettura ad alto livello: quali strumenti scegli, come li connetti e perché.
2. Stima dei costi annuali, con breakdown per componente.
3. Team e competenze necessarie per gestire l’infrastruttura.
4. Piano di evoluzione a 12 mesi, con cosa fare nei primi 3, 6 e 12 mesi.
5. Rischi principali e relativa strategia di mitigazione.

In pratica il team deve portare in produzione una piattaforma con warehouse, orchestratore, CI/CD, monitoring e controllo costi. Il caso obbliga a definire owner, SLA, ambienti, runbook e budget guardrail prima di aggiungere nuovi workload.

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, 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. Guarda anche segnali di qualità, cioè se l’utente guarda davvero il contenuto, se torna nei giorni successivi e 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. Vale anche qui: se la piattaforma produce numeri che non aiutano a scegliere tra due azioni alternative, il progetto è incompleto.

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;

La 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, dalla quale formulare ipotesi più precise.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da segnalare i 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 del controllo è pratico: eviti di reagire a ogni oscillazione casuale, ma vedi subito quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive operative.

Errori tipici e come evitarli

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale nasconde 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 chi usa una feature converte di più, non significa che la feature causi la conversione, potrebbe attirare utenti già motivati.

C’è poi l’errore più insidioso per un progetto infrastrutturale, cioè trattarlo come una checklist di strumenti invece che come un insieme di decisioni con un owner. Per ridurre questi rischi, ogni analisi dovrebbe contenere la definizione esplicita della metrica, il confronto per segmento e la verifica contro un periodo precedente o un gruppo di controllo.

Esercizio applicato

Al livello base scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie al progetto, indicando metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il progetto è ancora troppo astratto.

Al livello intermedio costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario e azione consigliata. Inserisci almeno un caso in cui il segnale da solo non basta per decidere.

Al livello research-grade trasforma l’esercizio in un memo decisionale con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e proposta di monitoraggio. Come materiale usa log delle pipeline, metriche dell’orchestratore, cost explorer, dati CI/CD, incident report e dashboard ops. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione di segmento e una metrica di outcome.

Checkpoint

Prima di chiudere, verifica di saper rispondere a queste cinque domande.

1. Quale decisione concreta dovrebbe migliorare grazie a questo progetto?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura isolata?
4. Quale assunzione, se falsa, cambierebbe la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

Progettare un’infrastruttura dati completa è uno strumento decisionale, non un catalogo di tecnologie. Il valore nasce quando colleghi requisiti, costi, owner, metrica e azione, e quando ogni componente serve a soddisfare una richiesta reale degli stakeholder. Un buon progetto non si chiude con “la dashboard funziona”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza e quale metrica useremo per sapere se avevamo ragione.