Correlazione, proxy metric e lettura causale dei KPI

Una proxy metric può essere utilissima e pericolosa nello stesso momento: click, visite o tempo speso spesso anticipano valore, ma possono anche sostituirlo in modo pigro. Correlazione, proxy metric e lettura causale dei KPI aiuta a capire quando un indicatore è un ponte verso l’outcome e quando diventa una scorciatoia.

Una scena da cui partire

Leggi la lezione come una serie di controlli rapidi: qual è l’outcome reale, quale proxy lo rappresenta, quale comportamento indesiderato può incentivare e quale prova servirebbe per fidarti del collegamento. La causalità non si improvvisa guardando due linee che salgono insieme.

• Contesto: Quale intuizione deve restare dopo la lettura?
• Metodo: Quale esempio rende concreto il concetto?
• Applicazione: Quale errore diventa più facile evitare?

Il Miraggio della Correlazione: Quando i Dati Mentono con Onestà

Nel nostro campo, l’affermazione “correlazione non implica causalità” è un mantra così ripetuto da rischiare di perdere il suo potere. Eppure, ignorarlo è la via più rapida per prendere decisioni disastrose basate sui dati. Una correlazione statistica, in termini formali, indica semplicemente che due o più variabili si muovono insieme secondo uno schema riconoscibile. Se la variabile A aumenta, anche la variabile B tende ad aumentare (correlazione positiva), o a diminuire (correlazione negativa). Il coefficiente di correlazione di Pearson, ad esempio, ci fornisce un valore tra -1 e +1 che quantifica la forza e la direzione di questa relazione lineare. Un valore di +0.8 indica un’associazione positiva molto forte. Il problema sorge quando il nostro cervello, biologicamente programmato per riconoscere pattern e costruire narrazioni causa-effetto, osserva questo +0.8 e conclude immediatamente che A provoca B.

La realtà è quasi sempre più complessa, e le ragioni per cui una forte correlazione può non avere alcun significato causale sono principalmente tre. La prima è la pura coincidenza, specialmente in dataset con migliaia di variabili. Su un numero sufficientemente grande di confronti, è statisticamente garantito trovare correlazioni spurie e assurde, come quella, celebre, tra il consumo pro capite di formaggio negli Stati Uniti e il numero di persone morte per essersi aggrovigliate nelle lenzuola. La seconda, più insidiosa, è la causalità inversa: potremmo osservare che i clienti che usano la feature X di un software hanno una retention più alta e concludere che X aumenta la retention. Ma potrebbe essere vero il contrario: i clienti più fidelizzati e soddisfatti sono quelli che esplorano di più il prodotto e finiscono per scoprire e usare la feature X.

Il terzo e più comune colpevole è la presenza di una variabile confondente (o lurking variable). Si tratta di un terzo fattore, C, che influenza sia A sia B, creando l’illusione di una relazione diretta tra loro. L’esempio classico è la correlazione tra vendite di gelati (A) e attacchi di squali (B). Un’analisi superficiale potrebbe suggerire di vietare i gelati per motivi di sicurezza pubblica. La variabile confondente, ovviamente, è la temperatura estiva (C): quando fa caldo, più persone comprano gelati e più persone fanno il bagno in mare, aumentando la probabilità di incontri con gli squali. La correlazione tra A e B svanisce se controlliamo per C. In un contesto aziendale, potremmo notare che i clienti che contattano il supporto clienti (A) hanno un tasso di churn più basso (B). L’ipotesi causale è che il supporto sia eccellente e salvi i clienti. La variabile confondente potrebbe essere il livello di engagement del cliente (C): i clienti più coinvolti e che traggono più valore dal prodotto sono sia più propensi a chiedere aiuto per ottimizzare il loro uso, sia meno propensi ad andarsene. Il supporto non sta “salvando” clienti a rischio, sta semplicemente interagendo con i clienti migliori.

Le Proxy Metric: Navigare a Vista nell’Oceano dei Dati

Non sempre è possibile misurare direttamente ciò che ci interessa. Concetti come la “soddisfazione del cliente”, la “salute del brand” o l‘“innovazione del team” sono astratti, multidimensionali e difficili da quantificare con un singolo numero. In questi casi, ricorriamo a una proxy metric (o metrica surrogato): una misura indiretta, più facile da osservare e quantificare, che crediamo sia strettamente correlata al fenomeno di nostro interesse. Se non possiamo misurare direttamente la soddisfazione, possiamo usare il Net Promoter Score (NPS) o il tasso di riacquisto come proxy. Se non possiamo misurare l’engagement di un utente con un’app, possiamo usare il numero di sessioni giornaliere (DAU/MAU ratio) o il tempo trascorso in-app.

L’uso delle proxy è una necessità pratica, ma apre la porta a un rischio ben definito dalla Legge di Goodhart: “Quando una misura diventa un obiettivo, cessa di essere una buona misura”. Nel momento in cui l’intera organizzazione inizia a ottimizzare ossessivamente per una proxy, le persone troveranno il modo di influenzare quella metrica, spesso a discapito del risultato reale che essa dovrebbe rappresentare. Se un team di supporto viene incentivato unicamente sulla base del “numero di ticket chiusi”, inizierà a chiudere i ticket il più velocemente possibile, anche senza risolvere il problema del cliente, peggiorando la soddisfazione reale. Se un team di prodotto è valutato solo sull’aumento del “tempo speso in-app”, potrebbe introdurre meccaniche di navigazione complesse o contenuti auto-play che gonfiano la metrica, ma frustrano l’utente.

Caso di Studio: Spotify e la Proxy dell’Ascolto Spotify vuole massimizzare la soddisfazione e la retention a lungo termine dei suoi utenti. Misurare direttamente la “soddisfazione musicale” è impossibile. Una proxy storicamente importante per loro è il “total listening time” (tempo totale di ascolto). L’ipotesi è semplice: più una persona ascolta, più valore trae dal servizio. Questa proxy ha guidato lo sviluppo di feature di successo come le playlist personalizzate (Discover Weekly, Release Radar) che, effettivamente, aumentano il tempo di ascolto e la retention. Tuttavia, il team di Spotify è ben consapevole dei limiti di questa proxy. Un utente potrebbe addormentarsi con una playlist in riproduzione, generando ore di ascolto a “valore zero”. Oppure, un utente potrebbe usare Spotify come sottofondo musicale in un locale affollato, dove la qualità della raccomandazione è irrilevante. Per mitigare questi rischi, Spotify non si affida a una singola proxy. Integra il tempo di ascolto con altre metriche-segnale: il numero di brani salvati, la creazione di playlist personali, la varietà di artisti e generi ascoltati, la percentuale di skip delle canzoni. Un utente che ascolta per 3 ore, salvando 5 canzoni e aggiungendole a una playlist, è un segnale di engagement molto più forte di un utente che ascolta passivamente per 8 ore la stessa playlist. La scelta di un buon paniere di proxy, che bilancino quantità e qualità dell’interazione, è fondamentale per evitare le trappole della Legge di Goodhart.

Dall’Associazione all’Inferenza Causale: La Gerarchia delle Evidenze

Per un analista, il compito non è trovare correlazioni, ma fornire un livello di confidenza affidabile su una potenziale relazione causale per informare una decisione. Non tutte le evidenze sono uguali. Esiste una gerarchia, dal segnale più debole alla prova più forte.

1. Correlazione Grezza: È il livello più basso di evidenza. “Abbiamo notato che gli utenti che usano la feature A churnano il 30% in meno”. È un punto di partenza, un’ipotesi da investigare, ma non è una base sufficiente per decidere di investire migliaia di ore di sviluppo per spingere la feature A a tutti.

2. Correlazione con Precedenza Temporale: Un piccolo passo avanti. Se vogliamo sostenere che A causa B, A deve accadere prima di B. Se un utente adotta la feature A il 10 Maggio e il suo engagement aumenta a partire dall’11 Maggio, l’ipotesi causale è plausibile. Se l’engagement era già in aumento nelle settimane precedenti all’adozione, è più probabile che sia l’engagement a causare l’adozione (causalità inversa).

3. Analisi di Segmentazione e Controllo: Qui iniziamo a fare sul serio. Invece di confrontare il gruppo di utenti che ha adottato la feature A con tutti gli altri, lo confrontiamo con un gruppo di controllo più simile. Potremmo confrontare gli “adotters” con un gruppo di utenti che ha caratteristiche demografiche e comportamentali identiche (stessa anzianità sulla piattaforma, stesso livello di attività iniziale), ma che, per qualche ragione, non ha ancora adottato la feature. Se la differenza di churn persiste anche in questo confronto più equo, la nostra fiducia nell’ipotesi causale aumenta. Stiamo, in effetti, tentando di “controllare” manualmente per le variabili confondenti più ovvie.

4. Quasi-Esperimenti: A volte non possiamo eseguire un esperimento controllato, ma la natura ci offre un’opportunità. Un esempio è l’analisi difference-in-differences. Immaginiamo di lanciare una campagna marketing solo in una regione (es. Lombardia). Non possiamo sapere come si sarebbero comportati i clienti lombardi senza la campagna. Possiamo però confrontare l’andamento delle vendite in Lombardia prima e dopo la campagna con l’andamento delle vendite in un’altra regione simile (es. Piemonte) nello stesso periodo. La “differenza delle differenze” ci dà una stima dell’impatto causale della campagna, al netto dei trend di mercato generali.

5. Randomized Controlled Trial (A/B Test): È il gold standard per l’inferenza causale in ambito industriale. L’idea è semplice ed elegante: prendiamo un gruppo di utenti idonei e li assegniamo casualmente a due o più varianti. Al gruppo di controllo (A) viene mostrata l’esperienza attuale. Al gruppo di trattamento (B) viene mostrata la nuova esperienza (es. con la feature A in evidenza). Poiché l’assegnazione è casuale, le uniche differenze sistematiche tra i due gruppi (in media) sono dovute al trattamento stesso. Tutte le possibili variabili confondenti — motivazione, età, livello di attività, paese — sono distribuite equamente tra i gruppi. Se, alla fine del test, osserviamo una differenza statisticamente significativa nella metrica di interesse (es. retention, conversione), possiamo concludere con un alto grado di confidenza che la nostra modifica ha causato quella differenza.

Caso di Studio Applicato: La Causalità dietro l’Engagement di Stripe

Stripe, la piattaforma per i pagamenti online, offre una suite di prodotti molto vasta. Uno di questi è Radar, un tool avanzato basato su machine learning per la prevenzione delle frodi. Il team di prodotto di Radar nota un dato impressionante: i clienti che attivano e utilizzano Radar hanno un life-time value (LTV) superiore del 70% e un tasso di churn inferiore del 40% rispetto ai clienti che non lo usano. La narrazione è potente: Radar, proteggendo le aziende dalle frodi, le rende più sane e profittevoli, e quindi più fedeli a Stripe. L’azione proposta potrebbe essere quella di offrire Radar gratuitamente per un periodo o di integrarlo in modo più aggressivo nei piani base per spingerne l’adozione.

Un analista esperto, tuttavia, applicherebbe la gerarchia delle evidenze.

• Ipotesi Iniziale (basata su correlazione): L’uso di Radar causa un aumento dell’LTV.
• Ipotesi Alternativa (basata su confondente): Esiste una variabile latente, che potremmo chiamare “sofisticazione del business”. Le aziende più grandi, strutturate, con team tecnici dedicati e volumi di transazioni elevati sono intrinsecamente più propense ad avere un LTV alto e un churn basso. Queste stesse aziende sono anche quelle che più probabilmente sentono il bisogno di un tool anti-frode avanzato e hanno le risorse per implementarlo. Radar non sarebbe la causa del successo, ma un indicatore di un successo pre-esistente.
• Passo Analitico Successivo (Segmentazione): Per testare questa ipotesi, l’analista non confronta chi usa Radar con chi non lo usa. Segmenta l’intera base clienti per volume di transazioni mensili (Monthly Processing Volume). Ad esempio: <€10k/mese, €10-100k/mese, >€100k/mese. A questo punto, ripete l’analisi all’interno di ogni segmento. Confronta gli utenti di Radar con i non-utenti solo nel bucket <€10k, poi solo nel bucket €10-100k, e così via.
• Risultato Probabile: L’analista scoprirebbe che all’interno di ogni fascia di volume, la differenza di LTV tra chi usa Radar e chi non lo usa si riduce drasticamente, magari dal 70% a un più modesto 10-15%. Questo non significa che l’effetto sia nullo, ma dimostra che la maggior parte della correlazione osservata era spuria, guidata dalla variabile confondente “dimensione/sofisticazione del business”. La decisione strategica cambia: invece di una spinta indiscriminata, l’azienda potrebbe decidere di progettare un A/B test per misurare quel 10-15% di effetto causale reale e capire se giustifica l’investimento.

Laboratorio Pratico: Ingegnerizzare la Causalità con SQL

Passiamo dalla teoria alla pratica. Immaginiamo di lavorare per un’azienda SaaS e di avere una tabella user_engagement che traccia l’attività degli utenti nei loro primi 90 giorni. La tabella ha questa struttura:

• user_id: Identificativo utente
• signup_date: Data di registrazione
• used_collaboration_feature: (BOOLEAN) TRUE se l’utente ha usato la nuova feature di collaborazione, FALSE altrimenti.
• initial_team_size: (INTEGER) Numero di utenti invitati nel team durante la prima settimana.
• ninety_day_retention: (BOOLEAN) TRUE se l’utente è ancora attivo dopo 90 giorni.

La nostra ipotesi è che la collaboration_feature aumenti la retention.

Esercizio 1: L’Analisi Correlazionale Ingenua

Il primo passo è calcolare la retention media per gli utenti che hanno usato la feature e per quelli che non l’hanno usata. La query SQL sarebbe la seguente:

SELECT
    used_collaboration_feature,
    COUNT(user_id) AS total_users,
    AVG(CASE WHEN ninety_day_retention THEN 1.0 ELSE 0.0 END) AS retention_rate
FROM
    user_engagement
GROUP BY
    1
ORDER BY
    1;

Ipotizziamo che questo ci dia un risultato sorprendente:

used_collaboration_feature	total_users	retention_rate
FALSE	8000	0.35
TRUE	2000	0.70

La retention per chi usa la feature è doppia (70% vs 35%)! Un product manager entusiasta potrebbe già chiedere di investire per rendere la feature obbligatoria.

Esercizio 2: Controllare per una Variabile Confondente

Sospettiamo che la dimensione iniziale del team (initial_team_size) sia una variabile confondente. I team più grandi sono naturalmente più “collaborativi” e quindi più propensi a usare la feature, ma sono anche più “sticky” e meno propensi al churn a prescindere. Controlliamo questa ipotesi segmentando la nostra analisi per dimensione del team. Creiamo dei bucket: “Solo” (1 utente), “Small Team” (2-5 utenti), “Large Team” (>5 utenti).

WITH user_segments AS (
    SELECT
        user_id,
        used_collaboration_feature,
        ninety_day_retention,
        CASE
            WHEN initial_team_size = 1 THEN '1_Solo'
            WHEN initial_team_size BETWEEN 2 AND 5 THEN '2_Small_Team'
            ELSE '3_Large_Team'
        END AS team_size_segment
    FROM
        user_engagement
)
SELECT
    team_size_segment,
    used_collaboration_feature,
    COUNT(user_id) AS total_users,
    AVG(CASE WHEN ninety_day_retention THEN 1.0 ELSE 0.0 END) AS retention_rate
FROM
    user_segments
GROUP BY
    1, 2
ORDER BY
    1, 2;

Il risultato di questa query sarebbe molto più illuminante:

team_size_segment	used_collaboration_feature	total_users	retention_rate
1_Solo	FALSE	4900	0.20
1_Solo	TRUE	100	0.25
2_Small_Team	FALSE	2500	0.50
2_Small_Team	TRUE	900	0.58
3_Large_Team	FALSE	600	0.80
3_Large_Team	TRUE	1000	0.85

Questa vista cambia completamente la storia.

1. La retention di base è enormemente influenzata dalla dimensione del team (20% per i solo-user, 80% per i team grandi). Questa era la nostra variabile confondente.
2. All’interno di ogni segmento, l’uso della feature è ancora associato a una retention più alta, ma l’effetto è molto più contenuto: un lift di 5-8 punti percentuali, non un raddoppio. Questo è l’impatto causale stimato della feature, una volta depurato dall’effetto confondente della dimensione del team. È un risultato ancora positivo, che potrebbe giustificare un A/B test, ma ridimensiona drasticamente le aspettative iniziali.

Riepilogo Operativo

L’analisi dei dati non è una caccia a correlazioni suggestive, ma una disciplina rigorosa per ridurre l’incertezza decisionale. Il percorso dall’osservazione di un’associazione alla formulazione di una raccomandazione causale richiede scetticismo metodologico e un approccio stratificato. Le correlazioni sono il punto di partenza, il segnale che qualcosa merita di essere investigato, non il punto di arrivo. Le proxy metric sono strumenti indispensabili per misurare l’impalpabile, ma vanno maneggiate con la consapevolezza che possono essere manipolate e possono divergere dal risultato di business che intendono rappresentare. La vera abilità di un data analyst o di un data engineer non risiede nella capacità di calcolare un coefficiente di Pearson o di costruire una dashboard, ma nella capacità di porre la domanda giusta: “Qual è la spiegazione alternativa più probabile per questo pattern, e quale evidenza, la più forte possibile dato il contesto, possiamo raccogliere per confermare o smentire la nostra ipotesi causale?”. Passare da query che descrivono “cosa” è successo a esperimenti e analisi che spiegano “perché” è successo è il salto di qualità che distingue un reporter di dati da un partner strategico per il business.

References

1. Pearl, J. (2009). Causal inference in statistics: An overview. Statistics Surveys, 3, 96-146.
2. Kohavi, R., Longbotham, R., Sommerfield, D., & Henne, R. M. (2009). Controlled experiments on the web: survey and practical guide. Data Mining and Knowledge Discovery, 18(1), 140-181.

## Problema reale

Nel dominio di metriche e KPI tree, **Correlazione, proxy metric e lettura causale dei KPI** serve a risolvere questo problema: scegliere metriche che rappresentano una decisione e non solo un numero facile da mostrare. La lezione non va trattata come teoria isolata, ma come un modo per migliorare una scelta concreta con dati, assunzioni esplicite e controlli minimi.

Obiettivo operativo: Comprendere il problema analitico e il contesto decisionale; Applicare esempi, metriche e controlli a casi reali. Se alla fine non sai indicare quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora diventata competenza applicata.

## Modello concettuale

| Fase | Cosa chiarire | Output |
|---|---|---|
| Domanda | Quale scelta reale deve migliorare? | Decisione da prendere |
| Misura | Quale segnale osservabile rappresenta il problema? | Metrica o dato sorgente |
| Controllo | Quale baseline rende il risultato interpretabile? | Confronto credibile |
| Azione | Che cosa cambia dopo l'analisi? | Prossimo passo operativo |

Il modello concettuale è intenzionalmente semplice: decisione, dato, controllo, azione. Ogni approfondimento tecnico deve rafforzare almeno uno di questi quattro punti.

## Formalizzazione rigorosa

Per rendere **Correlazione, proxy metric e lettura causale dei KPI** analizzabile, definisci prima l'unità di lavoro: **metrica, driver, guardrail, segmento o coorte**. Poi collega questa unità a una metrica osservabile: **baseline, variazione, rumore, impatto economico e trade-off**. Infine dichiara la decisione attesa: **KPI tree, metrica primaria, guardrail e soglia decisionale**.

| Elemento | Specifica richiesta |
|---|---|
| Unita di analisi | metrica, driver, guardrail, segmento o coorte |
| Segnale principale | baseline, variazione, rumore, impatto economico e trade-off |
| Baseline | Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale |
| Decisione | KPI tree, metrica primaria, guardrail e soglia decisionale |
| Rischio | Scambiare un numero disponibile per una prova sufficiente |

La formalizzazione e solida quando un altro analista può riprodurre la logica, criticare le assunzioni e ottenere la stessa decisione partendo dagli stessi dati.

## Esempio o caso studio

Il team vede che gli utenti che usano una feature convertono di più e vuole investirci subito. Prima di decidere verifica se la feature causa conversione, se la usano solo utenti già motivati o se la proxy misura attenzione senza misurare valore.

| 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à |

## Lab / esercizio

### Livello base

Scrivi una scheda di una pagina per **Correlazione, proxy metric e lettura causale dei KPI**: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale e confermato.

### Livello intermedio

Costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa e plausibile e quale controllo useresti prima di raccomandare un azione.

### Livello research-grade

Prepara un decision memo: ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione.

### Dataset e materiali consigliati

Usa dati prodotto, CRM, transazioni, funnel, coorti e report finanziari. 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.

## Errore tipico da evitare

L'errore più comune e usare **Correlazione, proxy metric e lettura causale dei KPI** 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.

## Quiz o checkpoint

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 ingenua?
4. Quale errore tipico potrebbe cambiare la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

## Riepilogo operativo

**Correlazione, proxy metric e lettura causale dei KPI** diventa utile quando produce una decisione più chiara, non quando aggiunge terminologia. Usa il framework problema, modello, formalizzazione, esempio, lab e checkpoint per trasformare la lezione in pratica verificabile. Categoria: Analisi. Difficolta: beginner. Tempo stimato: 18 min.