Introduzione alla product analytics

Product analytics nasce quando il team deve capire se il prodotto crea valore per utenti reali, non solo se genera traffico o iscrizioni. Introduzione alla product analytics definisce il mestiere: leggere comportamento, formulare ipotesi, misurare outcome e guidare decisioni di roadmap.

Una scena da cui partire

Leggi questa lezione come cambio di prospettiva: dal report sul prodotto alla diagnosi del comportamento. Il product analyst deve collegare eventi, utenti, valore e decisioni.

• Contesto: Quale decisione rende utile il concetto?
• Metodo: Quale conflitto tra team o metriche devi anticipare?
• Applicazione: Quale frase useresti per spiegarlo in riunione?

Le 5 domande del product analyst

1. Attivazione: qual è il momento in cui l’utente sperimenta il valore del prodotto? Come misuriamo se ci arriva?
2. Retention: perché gli utenti tornano? Quali comportamenti predicono il ritorno e quali l’abbandono?
3. Engagement: quali azioni sono segnali di salute? Quali sono vanity?
4. Monetization: quale percorso porta alla conversione? Quali segmenti sono disposti a pagare?
5. Growth: quali canali portano utenti che restano? Quali portano utenti che scappano dopo 1 giorno?

Metriche prodotto fondamentali

Metrica	Formula	Significato operativo	Benchmark
Attivazione	% utenti che completano evento chiave entro N giorni	L’onboarding funziona?	>60% entro D7
DAU/MAU	Daily Active / Monthly Active	Stickiness: quanto è essenziale il prodotto?	20-50% (app), 10-25% (SaaS)
Retention D7/D30	% utenti attivi dopo N giorni dal signup	Il prodotto ha valore duraturo?	20-40% D1, 10-20% D7, 5-10% D30
Feature Adoption	% utenti attivi che usano feature X	Le nuove feature sono rilevanti?	>10% primo mese
Time to Value	Tempo dal signup al momento “aha”	L’onboarding è efficiente?	<5 min (consumer), <1 giorno (SaaS)

Il funnel AARRR (Pirate Metrics)

Coniato da Dave McClure (2007), rimane il framework più utile per strutturare l’analisi di prodotto:

Acquisition → Activation → Retention → Revenue → Referral

Ogni fase ha metriche specifiche e un team owner:

• Acquisition: da dove arrivano gli utenti? (Marketing)
• Activation: hanno una buona prima esperienza? (Product + Design)
• Retention: tornano? (Product)
• Revenue: pagano? (Product + Finance)
• Referral: raccomandano ad altri? (Product + Marketing)

Il funnel è un framework di ownership tanto quanto di misurazione. Se la retention è bassa ma è il team marketing a darne conto, il problema non verrà mai risolto — perché il marketing non controlla il prodotto.

Product analytics vs marketing analytics

	Product Analytics	Marketing Analytics
Domanda	”Perché l’utente usa/non usa questa feature?"	"Quale canale porta più clienti?”
Metrica chiave	Retention, Engagement, Feature Adoption	CAC, ROAS, CVR
Dati	Eventi in-app, sessioni, feature usage	Campagne, UTM, touchpoint
Stakeholder	PM, Designer, Engineer	CMO, Growth, Performance marketer
Ciclo	Sprint (2 settimane)	Campagna (giorni/settimane)

Nelle aziende sotto 200 persone, spesso il product analyst è anche marketing analyst. Sopra i 200, i ruoli si separano perché le domande diventano troppo diverse.

Caso reale: il product analytics stack di Spotify

Spotify usa un framework chiamato “DIBBs” (Data, Insight, Belief, Bet) per tutte le decisioni di prodotto. Ogni modifica all’app segue 4 fasi:

1. Data: cosa mostrano i dati attuali? (es. “il 30% degli utenti non crea mai una playlist”)
2. Insight: cosa suggeriscono? (es. “la creazione playlist è troppo complessa per nuovi utenti”)
3. Belief: formulo un’ipotesi su come risolvere (es. “se pre-popoliamo playlist basate sul gusto, più utenti ascolteranno musica”)
4. Bet: lancio un esperimento per testare l’ipotesi

Il punto chiave: ogni “bet” è legata a un “belief” che può essere verificato. Non è “facciamo X e vediamo”: è “credo che X causi Y, ecco come lo testo”.

Il product analytics stack

Event Tracking (Amplitude/Mixpanel/PostHog) → Warehouse (Snowflake/BigQuery)
    → dbt Models (int_product_usage, mrt_product__feature_adoption)
    → BI (Looker/Tableau) + A/B Testing Platform (Statsig/Eppo)

La tendenza moderna è spostare l’analisi complessa da Amplitude/Mixpanel al warehouse (via dbt), mantenendo i tool di product analytics solo per query rapide e funnel interattivi.

Checklist per iniziare come product analyst

1. Impara a memoria le 4 metriche core: DAU/MAU, Retention D7/D30, Feature Adoption, Time to Value
2. Impara a costruire una matrice di coorte in SQL (query di base)
3. Impara a disegnare un funnel e identificare il punto di drop-off
4. Impara a formulare ipotesi falsificabili (“se cambio X, Y aumenta del Z%”)
5. Impara a comunicare insight a PM e designer: non “la retention è 12%” ma “la retention è 12% ed è in calo del 3% rispetto al mese scorso. Il calo è concentrato su Android dopo l’ultimo update. Raccomando di investigare il nuovo onboarding flow su Android.”

---

Riferimenti:

• McClure, D. (2007). “Startup Metrics for Pirates: AARRR!” 500 Startups.
• Croll, A. & Yoskovitz, B. (2013). Lean Analytics. O’Reilly.
• Gauthier, M. (2021). “Data-Informed Decision Making at Spotify.” Spotify R&D Blog.

Problema reale

Nel dominio di product analytics, Introduzione alla product analytics serve a risolvere questo problema: capire dove il prodotto crea valore reale e dove invece produce solo attività apparente. 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 Introduzione alla product analytics analizzabile, definisci prima l’unità di lavoro: utente, coorte, evento prodotto, feature o journey. Poi collega questa unità a una metrica osservabile: activation, retention, frequenza, conversione, churn e valore per coorte. Infine dichiara la decisione attesa: diagnosi prodotto, esperimento, prioritizzazione o intervento UX.

Elemento	Specifica richiesta
Unità di analisi	utente, coorte, evento prodotto, feature o journey
Segnale principale	activation, retention, frequenza, conversione, churn e valore per coorte
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	diagnosi prodotto, esperimento, prioritizzazione o intervento UX
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

Un team guarda utenti attivi, funnel e retention ma non ha ancora definito quale evento rappresenta valore ricevuto. Il caso mostra la prima responsabilità della product analytics: trasformare attività misurabile in outcome di prodotto.

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 Introduzione alla product analytics: 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 eventi prodotto, funnel, sessioni, survey, CRM, ticket supporto e esperimenti. 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 Introduzione alla product analytics 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

Introduzione alla product analytics 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: Decisione. Difficoltà: advanced. Tempo stimato: 22 min.