Data-Driven Decision Making

Il punto di partenza di una decisione basata sui dati non è la metrica più bella: è la decisione stessa. Ogni passaggio del processo che vedremo si appoggia su tabelle, baseline e controlli, non su sensazioni, e il framework DECIDE ordina il tutto in sei passaggi. Prima di leggere qualsiasi numero, impari a fissare decisione, criteri e responsabilità.

L’idea in una frase

Decidere con i dati significa fissare decisione, criteri e responsabilita prima di leggere qualsiasi metrica.

La sequenza operativa

1. Scrivi la decisione come scelta tra alternative, con budget e scadenza espliciti.
2. Elenca le evidenze disponibili, i loro limiti e cosa non possono dimostrare.
3. Fissa criteri pesati e soglia di cambio scelta prima di guardare i numeri.
4. Analizza la tabella per segmenti e baseline, senza fermarti alla prima risposta.
5. Assegna la decisione a una sola persona, con data e controllo a 30, 60 e 90 giorni.

The DECIDE framework

La sequenza DECIDE ordina il processo in sei passaggi. Ogni passaggio collega decisione, evidenza e responsabilita.

1. Define: definisci la decisione esatta, non “migliorare il prodotto” ma investire 200K nella feature X oppure nella feature Y.
2. Evidence: raccogli i dati disponibili, indica cosa dicono e dichiara i limiti dell’evidenza.
3. Criteria: fissa i criteri pesati tra revenue, retention e time-to-market prima di guardare i dati.
4. Investigate: segmenta i dati, confronta i gruppi contro la baseline e verifica le alternative prima di concludere.
5. Decide: una sola persona decide, con data e responsabilita chiara.
6. Evaluate: a 30, 60 e 90 giorni controlla se la decisione ha prodotto l’effetto atteso e itera.

Tra opinione veloce e alibi del dashboard, vince solo la sequenza che nomina chi decide e cosa lo farebbe cambiare idea.

L’errore del gut feel mascherato

The gut feel e l’intuizione non verificata del manager. Molti manager chiedono un’analisi pur avendo gia deciso e cercano solo dati che confermino l’intuizione. Questo non e un processo data-driven, ma distorsione di conferma con un budget. L’antidoto e diretto: prima dell’analisi scrivi cosa ti farebbe cambiare idea. Se non esiste risposta, non vuoi farti guidare dai dati e cerchi solo una copertura.

Element	Operational Definition	Controllo minimo
Unit of analysis	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 puo restare anche dopo l’analisi	Controllo di sensitivita o revisione qualitativa

La vista di controllo in SQL

Per confrontare periodi e gruppi senza riscrivere la logica ogni volta, il pattern seguente crea una base analitica con metrica, segmento e finestra temporale.

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 costruisce la superficie di osservazione con trend, segmenti e differenze tra canali. Da qui nascono ipotesi verificabili.

Il controllo di stabilita in Python

Una metrica utile resta stabile per orientare le decisioni e sensibile per segnalare i cambiamenti reali.

# 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 controllo evita reazioni a oscillazioni casuali e alimenta alert, review settimanali e retrospettive di prodotto.

Gli errori tipici da evitare

Il primo errore e aggregare troppo presto. Una media globale nasconde segmenti che si muovono in direzioni opposte. Il secondo e ignorare la qualita del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo e confondere correlazione e causalita: se gli utenti di una feature convertono di piu, forse la usano proprio perche erano gia motivati. Ogni analisi deve includere definizione esplicita della metrica, confronto per segmento e controllo contro un periodo precedente o un gruppo di controllo.

Un caso reale: il Fire Phone di Amazon

Nel 2014 Amazon lancia il Fire Phone nonostante i dati mostrassero un mercato saturo di smartphone con poca differenziazione. Il prodotto si rivela un fallimento da 170 milioni di dollari di perdita. Jeff Bezos nella lettera agli azionisti del 2015 riconosce l’errore: i dati avevano ragione e l’azienda aveva scommesso su feature uniche che non hanno convinto i clienti. Il caso resta una lezione di processo: un manager data-driven dichiara prima cosa lo farebbe cambiare idea e dopo ammette quando l’evidenza aveva ragione.

Verdetto: tra opinione veloce e alibi del dashboard, vince solo la sequenza DECIDE che nomina chi decide e cosa lo farebbe cambiare idea: se prima dell’analisi non esiste risposta a quella domanda, non stai decidendo con i dati, stai cercando una copertura.

Domande per verificare la tua comprensione

1. Quale decisione stai prendendo e chi ne risponde con quale scadenza?
2. Cosa ti farebbe cambiare idea prima di guardare i numeri?
3. Quale baseline evita una lettura isolata del segnale?
4. Come controlli a 30, 60 e 90 giorni se la scelta ha funzionato?