import pandas as pd

OKR e KPI: dalle metriche agli obiettivi

Un team può avere KPI perfetti e obiettivi confusi, oppure OKR ambiziosi senza metriche capaci di guidare il lavoro. Questa lezione chiarisce come collegare direzione strategica, indicatori operativi e responsabilità di decisione. Appartiene alla categoria Decisione: il punto non è accumulare definizioni, ma capire quale scelta cambia quando il dato diventa più affidabile.

Il problema che la lezione risolve

Conoscere OKR e KPI in astratto non serve. Il problema vero è decidere cosa fare quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Una lezione utile separa il segnale dal rumore, dice quale baseline usare e indica quale azione diventa più difendibile dopo l’analisi.

Leggi questa lezione come un allineamento tra ambizione e misura. Un buon KPI non è solo misurabile: orienta il comportamento senza creare incentivi perversi. Prima di iniziare conviene fissare tre cose: quale decisione rende utile il concetto, quale conflitto tra team o metriche dovrai anticipare, e con quale frase lo spiegheresti in riunione.

Una sequenza di lavoro

Per non trasformare una nozione tecnica in un rituale vuoto, conviene seguire una sequenza che renda visibile il costo di una scelta sbagliata a ogni passaggio.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se capiamo meglio obiettivi e indicatori?	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 prima domanda da fare resta quale decisione dovrà essere presa grazie all’analisi. Una dashboard, una query o un set di OKR hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, restano documentazione o teatro analitico.

OKR e KPI a confronto

OKR e KPI rispondono a domande diverse e non vanno confusi. Gli OKR servono a guidare il cambiamento verso un obiettivo ambizioso, i KPI a monitorare lo stato di salute del business.

	OKR	KPI
Scopo	Guidare il cambiamento verso un obiettivo ambizioso	Monitorare lo stato di salute del business
Domanda	”Dove vogliamo arrivare?"	"Come stiamo andando?”
Misura	Key Results specifici e time-bound	Metriche continue, soglie di allerta
Aspirazione	Ambiziosi (60-70% di achievement è successo)	Stabili (100% di achievement atteso)
Esempio	O: Dominare il mercato EU. KR: 500K nuovi clienti Q1	KPI: MRR, Churn Rate, CAC, LTV/CAC

Come scrivere buoni OKR

L’Objective è qualitativo, ispirazionale e memorabile. “Diventare lo standard per l’analisi dati in Europa” funziona, “aumentare il revenue del 15%” no. I Key Results sono da tre a cinque risultati misurabili, ognuno con numero, baseline e target: “crescere da 120 a 400 aziende clienti enterprise entro Q4” è un buon KR, “aumentare i clienti enterprise” non lo è. La regola che separa i due casi è la distinzione tra attività e risultato. “Lanciare 3 webinar” è attività, “generare 200 MQL da webinar” è risultato.

KPI: quali scegliere

Un buon set di KPI ha tre qualità. È limitato, da cinque a dieci indicatori e non cinquanta, perché oltre i dieci il focus si perde. È bilanciato, perché tiene insieme leading indicator predittivi come la pipeline sales e lagging indicator storici come il revenue. Ed è azionabile: se il KPI si muove, sai cosa fare. “Tempo medio sul sito” non è azionabile, “tasso di conversione checkout” sì.

---

Riferimento: Doerr, J. (2018). Measure What Matters. Portfolio.

Formalizzare la relazione tra decisione, evidenza e rischio

Una formalizzazione non serve a complicare la lezione. Serve a rendere visibili le assunzioni, così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità. È solida quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati.

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

Un caso concreto

Un team ha KPI di output molto buoni ma OKR di outcome fermi. Il caso costringe a distinguere attività, risultato e comportamento incentivato, per evitare che una metrica comoda diventi il modo più rapido per allontanarsi dall’obiettivo. La domanda non è “qual è la definizione corretta?” ma “quale scelta diventa meno rischiosa se questa analisi è fatta bene?”.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmento
Un segmento cambia più degli altri	La media aggregata nasconde una differenza	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	L’impatto va letto sul margine	Stimare trade-off e sostenibilità

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. Il punto è metodologico: il dato non viene trattato come ornamento, ma come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, come 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 ma danneggiano valore nel lungo periodo. Lo stesso principio vale per OKR e KPI: se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

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 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 e collegarle ai Key Results che sta seguendo.

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 investigazione. In azienda questo tipo di analisi può alimentare alert, review settimanali e retrospettive di prodotto.

Esercizio pratico

Parti da un livello base. Scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a OKR e KPI, indicando metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il tema è ancora troppo astratto.

Al livello intermedio costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario e azione consigliata. Usa almeno un caso in cui il segnale non basta per decidere. Al livello research-grade trasforma l’esercizio in un memo decisionale che includa assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale puoi usare OKR, decision log, roadmap, retrospettive e survey interne, oppure un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errori comuni da evitare

Il primo errore è lavorare su dati aggregati troppo presto. 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à: se gli utenti che usano una feature convertono di più, non significa che la feature causi conversione, perché potrebbero usarla proprio perché sono già più motivati.

C’è poi un errore di forma: usare OKR e KPI come etichetta tecnica invece che come criterio di scelta. 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 è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Per ridurre il rischio, ogni analisi dovrebbe includere almeno tre controlli: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Verifica di comprensione

1. Quale decisione concreta dovrebbe migliorare questa lezione?
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

OKR e KPI vanno trattati come strumenti decisionali, non come argomenti da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando distingui con chiarezza la direzione ambiziosa degli OKR dal monitoraggio stabile dei KPI. 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.