KPI trees by function: differences and intersections

Marketing, prodotto, finance e operations usano KPI diversi, ma spesso influenzano la stessa decisione. Un KPI tree serve a costruire alberi metrici che mostrano dipendenze, conflitti e punti di raccordo, invece di lasciare ogni team chiuso nel proprio silo numerico. Letto bene, è l’architettura del linguaggio aziendale: diventa utile quando chiarisce come una metrica locale contribuisce a un risultato comune, e quando invece crea incentivi che si contraddicono.

Cos’è un KPI tree e perché ti serve

Un KPI tree è una decomposizione gerarchica di una metrica di outcome, tipicamente revenue o EBITDA, nei suoi driver operativi. Parti dalla metrica che guarda il CEO e la scomponi in pezzi sempre più piccoli, fino ad arrivare alle metriche che ogni team può influenzare direttamente. La domanda di fondo non è quale numero suoni meglio, ma quale funzione ottimizza una metrica che ne impatta altre, quale nodo collega il risultato ai driver operativi e come usare l’albero per risolvere un conflitto tra team.

Ecco come appare l’albero per un e-commerce:

Monthly Revenue
├── New Customers × Average Order × Gross Margin
│   ├── Traffic × Conversion Rate × AOV × GM
│   │   ├── Traffic
│   │   │   ├── Organic Traffic
│   │   │   ├── Paid Traffic
│   │   │   └── Direct Traffic
│   │   ├── Conversion Rate
│   │   │   ├── Visitors → Product Page: 45%
│   │   │   ├── Product Page → Cart: 12%
│   │   │   └── Cart → Purchase: 38%
│   │   ├── AOV (Average Order Value)
│   │   │   ├── Average Price × Units per Order
│   │   └── Gross Margin
│   │       └── (Revenue - COGS - Shipping) / Revenue
│   └── Customer Acquisition Cost (CAC)
└── Returning Customers × Average Order × Gross Margin
    ├── Total Customers × Return Rate
    │   ├── D30 Retention Rate
    │   ├── Purchase Frequency
    │   └── Remarketing Campaigns
    └── (Same AOV and GM subcomponents)

La forza del KPI tree è che ogni nodo ha un owner e un target. Senza owner resta un esercizio estetico; con un owner diventa un sistema operativo.

Come costruire un KPI tree in quattro passi

Il primo passo è selezionare la metrica North Star, quella che cattura insieme il valore che il prodotto porta ai clienti e il valore che i clienti portano all’azienda. Per Airbnb sono le notti prenotate, perché creano valore per host, guest e azienda; per Spotify è il tempo di ascolto, per utenti, artisti e azienda; per Stripe è il volume di pagamenti processati. Non usare il revenue come North Star se il prodotto è un marketplace multi sided o freemium, perché il revenue è un outcome, non il valore per l’utente.

Il secondo passo è decomporre la metrica nei driver operativi, chiedendoti per ogni nodo cosa deve succedere perché quel numero aumenti. La decomposizione deve essere MECE, cioè mutualmente esclusiva e collettivamente esaustiva: ogni componente è indipendente e insieme coprono tutto il nodo superiore. Per SaaS ed e-commerce la decomposizione più potente è quella basata sul customer lifecycle:

Revenue = New Customers × ARPU + Existing Customers × ARPU × (1 - Churn%)

Il terzo passo è assegnare owner e target a ogni foglia, cioè al livello più granulare. Ogni foglia ha un team owner, per esempio il Growth Team, un target numerico come “tasso di conversione superiore al 3.2%”, una frequenza di misurazione settimanale e una fonte dati, per esempio il funnel checkout_completed su Amplitude.

Il quarto passo è collegare gli alberi delle diverse funzioni. Ogni funzione (marketing, prodotto, sales, finance) può avere il proprio albero, ma le foglie devono connettersi: il tasso di conversione del funnel marketing è l’input del funnel sales, e l’MRR nell’albero finance è l’output degli alberi marketing e prodotto.

Come funziona in Intercom

Intercom, azienda di customer messaging da oltre 200M di ARR, ha documentato il proprio framework di metriche. La North Star è “conversazioni risolte con successo”, non il revenue e non gli utenti, perché rappresenta il valore reale per il cliente. Da questa decompongono l’albero:

Resolved Conversations
├── Conversations Started
│   ├── Active Users
│   └── Conversation Start Rate
├── Automated Resolution Rate (bot)
└── Human Agent Resolution Rate
    ├── Agent Response Time
    └── Response Quality (CSAT)

Ogni team ha un sotto albero e ogni sotto albero ha metriche che influenzano il revenue, perché i clienti soddisfatti rinnovano e si espandono. Il team marketing sa così che il suo lavoro non è generare lead, ma generare lead che inizieranno conversazioni risolte con successo. Questo allineamento verticale trasforma metriche astratte in missioni operative.

Gli errori più comuni

Il primo errore è mettere troppi livelli. Un albero con sette livelli è inutile: tre o quattro bastano, dall’outcome al driver alla leva fino all’azione operativa. Il secondo è scegliere metriche vanity invece che azionabili: “page views” non è azionabile, mentre “tasso di click dalla home alla pagina prodotto” lo è. Il terzo è non collegare gli alberi tra loro, così che marketing massimizza i lead, vendite massimizza il deal size e nessuno massimizza il profitto. Il quarto è dare metriche senza contesto temporale: “tasso di conversione 3%” non dice nulla se non si sa che il mese scorso era 2% o 4%, quindi ogni metrica deve avere un trend e un benchmark.

Controlli prima di decidere

Prima di usare un KPI tree in una decisione, controlla completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi. Molte analisi apparentemente sofisticate falliscono perché il dato di partenza misura un comportamento diverso da quello che il team crede di osservare. Ricorda che la media aggregata è solo il punto di partenza: se due segmenti si muovono in direzioni opposte, la media non rappresenta nessuno dei due. Per analizzare un albero conviene fissare l’unità di lavoro, il segnale principale, la baseline di confronto, la decisione attesa e il rischio.

Element	Requested specification
Unit of analysis	metrica, nodo, funzione, owner o foglia dell’albero
Primary signal	impatto sul revenue, conflitto tra team, qualità del dato
Baseline	periodo precedente, gruppo comparabile, benchmark o target
Decision	dove allocare, quale metrica far prevalere, quale conflitto risolvere
Risk	scambiare un numero disponibile per una prova sufficiente

L’esempio tipico chiarisce dove serve l’albero: il marketing ottimizza i lead, sales la pipeline, finance il margine e product l’activation. Il KPI tree diventa utile quando mostra dove queste metriche si rinforzano, dove si contraddicono e quale deve prevalere nella decisione specifica.

Esercizi e checkpoint

Al livello base, scrivi una scheda di una pagina su una metrica che ti interessa: la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione se il segnale è confermato. Al livello intermedio costruisci una tabella con tre nodi o funzioni e per ciascuno indica 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 materiale puoi usare dashboard, definizioni di metriche e stakeholder map; se non hai dati reali, costruisci un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione di segmento e una metrica di outcome.

Per chiudere, prova a rispondere: quale decisione concreta dovrebbe migliorare grazie all’albero, quale unità di analisi rende il problema misurabile, quale baseline useresti, quale errore potrebbe cambiare la conclusione e quale output consegneresti a uno stakeholder non tecnico.

Summary

Un KPI tree diventa utile quando produce una decisione più chiara, non quando aggiunge nodi. Si costruisce in quattro passi: scegliere la North Star, decomporre in modo MECE, assegnare owner e target a ogni foglia e collegare gli alberi delle diverse funzioni. Gli errori da evitare sono i troppi livelli, le metriche vanity, gli alberi scollegati e le metriche senza contesto temporale. Il caso di Intercom mostra come l’allineamento verticale trasformi metriche astratte in missioni operative. Categoria: Decisione. Difficoltà: advanced. Tempo stimato: 18 min.

---

References:

• Gibson, E. (2017). “How to Choose a North Star Metric.” Amplitude Blog.
• Intercom. (2021). “How We Structure Our Product Metrics.” Intercom Engineering Blog.
• McClure, D. (2007). “Pirate Metrics: AARRR!” 500 Startups.