Cheat Sheet — Analisi di Prodotto

Quando devi analizzare un prodotto sotto pressione, serve una sequenza chiara: definire evento di valore, leggere funnel, segmentare coorti, controllare retention, ascoltare utenti e trasformare tutto in priorità. Cheat Sheet — Analisi di Prodotto raccoglie questa sequenza operativa.

Una scena da cui partire

Usa questa pagina come checklist per review prodotto, discovery e prioritizzazione. Il valore non è ricordare tutte le metriche, ma sapere quale guardare in base alla domanda.

• Contesto: Quale regola serve sotto pressione?
• Metodo: Quale eccezione non devi dimenticare?
• Applicazione: Quale checklist useresti domani in un progetto reale?

Metriche core

Le metriche cambiano in base al tipo di prodotto, ma alcune famiglie ritornano sempre.

Engagement

• DAU: utenti attivi giornalieri.
• WAU: utenti attivi settimanali.
• MAU: utenti attivi mensili.
• DAU/MAU: proxy di frequenza e abitudine.

Benchmark indicativi:

Prodotto	DAU/MAU tipico
Social / messaging	40-70%
Consumer app abitudinaria	20-50%
Productivity SaaS	10-30%
B2B usato occasionalmente	5-15%

Attenzione: DAU/MAU alto non è sempre meglio. Un software per dichiarazione fiscale non deve essere usato ogni giorno. La frequenza giusta dipende dal job-to-be-done.

Retention

Retention misura se gli utenti tornano. Le forme principali sono:

• N-day retention: l’utente torna esattamente nel giorno N.
• Unbounded retention: l’utente torna nel giorno N o dopo.
• Bracket retention: l’utente torna in una finestra, es. settimana 2 o mese 1.

Benchmark consumer app molto generici:

Metrica	Range debole	Range buono	Range forte
D1	<20%	25-40%	>45%
D7	<8%	10-20%	>25%
D30	<4%	5-10%	>15%

Per SaaS B2B, i benchmark giornalieri sono spesso meno utili; conta di più retention mensile o logo retention.

Activation

Activation misura se l’utente raggiunge il primo momento di valore. È spesso la metrica più importante nei prodotti in crescita.

Esempi di activation event:

• Notion: creare una pagina e modificarla
• Slack: inviare messaggi con almeno due colleghi
• Dropbox: caricare un file e accedervi da un altro dispositivo
• FitTrack: completare il primo allenamento e vedere progresso
• Shopify: pubblicare il primo prodotto nello store

Formula:

SELECT
  COUNT(*) AS new_users,
  COUNT(*) FILTER (WHERE activated_at IS NOT NULL) AS activated_users,
  ROUND(
    COUNT(*) FILTER (WHERE activated_at IS NOT NULL) * 100.0 / COUNT(*),
    1
  ) AS activation_rate
FROM users
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days';

Monetizzazione

Metriche comuni:

• Trial start rate: nuovi utenti che iniziano trial.
• Trial conversion rate: trial che diventano paganti.
• ARPU: Average Revenue Per User.
• ARPA: Average Revenue Per Account.
• LTV: Lifetime Value.
• Churn revenue: ricavo perso per cancellazioni.
• NRR: Net Revenue Retention, cruciale nel SaaS.

Formula NRR:

NRR = (Revenue iniziale + Expansion - Contraction - Churn) / Revenue iniziale

NRR >100% significa che i clienti esistenti crescono abbastanza da compensare perdite e downgrade.

Framework AARRR

AARRR, introdotto da Dave McClure, divide il funnel in cinque fasi:

1. Acquisition: come arrivano gli utenti?
2. Activation: raggiungono il primo valore?
3. Retention: tornano?
4. Referral: invitano altri?
5. Revenue: pagano?

Il framework è utile perché impedisce di ottimizzare solo acquisition. Molte startup muoiono non perché non sanno portare traffico, ma perché portano traffico in un prodotto che non trattiene.

Query funnel base:

WITH funnel AS (
  SELECT
    user_id,
    MAX(CASE WHEN event_type = 'signup' THEN 1 ELSE 0 END) AS signup,
    MAX(CASE WHEN event_type = 'activation_event' THEN 1 ELSE 0 END) AS activated,
    MAX(CASE WHEN event_type = 'returned_d7' THEN 1 ELSE 0 END) AS retained_d7,
    MAX(CASE WHEN event_type = 'referral_sent' THEN 1 ELSE 0 END) AS referred,
    MAX(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) AS purchased
  FROM events
  GROUP BY user_id
)
SELECT
  COUNT(*) FILTER (WHERE signup = 1) AS signups,
  COUNT(*) FILTER (WHERE activated = 1) AS activated,
  COUNT(*) FILTER (WHERE retained_d7 = 1) AS retained_d7,
  COUNT(*) FILTER (WHERE referred = 1) AS referred,
  COUNT(*) FILTER (WHERE purchased = 1) AS purchased
FROM funnel;

Product-market fit: segnali pratici

Il product-market fit non è una sensazione. Non esiste una metrica unica perfetta, ma esistono segnali convergenti.

Segnali quantitativi:

• retention curve che si appiattisce invece di andare a zero
• miglioramento cohort-over-cohort
• crescita organica significativa
• referral spontanei
• NRR >100% nel SaaS
• utenti che tollerano difetti pur di continuare a usare il prodotto

Segnali qualitativi:

• utenti molto delusi se il prodotto sparisse
• casi d’uso ripetuti non inventati dal team
• vendita più facile nel segmento target
• clienti che chiedono integrazioni e profondità, non spiegazioni base

Sean Ellis test:

“How would you feel if you could no longer use this product?”

Se oltre il 40% risponde “very disappointed”, è un forte segnale di PMF. Non è una legge universale, ma è un buon indicatore.

Behavioral cohorts

Le coorti comportamentali segmentano utenti in base a ciò che fanno, non a chi sono.

Esempi:

• power users: attivi 20+ giorni al mese
• creators: creano contenuto, non solo consumano
• collaborators: invitano altri utenti
• explorers: usano molte feature diverse
• dormant: attività minima recente

Query base:

WITH behavior AS (
  SELECT
    user_id,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(*) AS total_events,
    COUNT(DISTINCT event_type) AS event_types,
    MAX(CASE WHEN event_type = 'invite' THEN 1 ELSE 0 END) AS invited_someone
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'
  GROUP BY user_id
)
SELECT
  CASE
    WHEN active_days >= 20 AND invited_someone = 1 THEN 'champion'
    WHEN active_days >= 20 THEN 'power_user'
    WHEN active_days >= 10 THEN 'regular'
    WHEN active_days >= 3 THEN 'casual'
    ELSE 'dormant'
  END AS segment,
  COUNT(*) AS users,
  ROUND(AVG(total_events), 1) AS avg_events
FROM behavior
GROUP BY 1;

La domanda più importante non è quanti utenti ci sono in ogni segmento, ma come si muovono: casual → regular, regular → power, power → dormant.

A/B testing: regole minime

Un A/B test valido richiede:

• ipotesi chiara prima del lancio
• metrica primaria definita
• durata minima stabilità
• sample size stimato
• guardrail metrics
• randomizzazione corretta
• niente stop appena p < 0.05

Anti-pattern:

• cambiare metrica primaria dopo aver visto risultati
• guardare 20 metriche e celebrare quella significativa
• fermare il test al primo giorno positivo
• ignorare effetti per segmento
• lanciare esperimenti che rompono la fiducia utente

SQL per risultato semplice:

SELECT
  variant,
  COUNT(DISTINCT user_id) AS users,
  COUNT(DISTINCT CASE WHEN converted THEN user_id END) AS conversions,
  ROUND(
    COUNT(DISTINCT CASE WHEN converted THEN user_id END) * 100.0 /
    COUNT(DISTINCT user_id),
    2
  ) AS conversion_rate
FROM experiment_assignments
WHERE experiment_id = 'onboarding_v2'
GROUP BY variant;

Prioritizzazione roadmap

RICE

RICE = (Reach × Impact × Confidence) / Effort

Usalo per confrontare iniziative con impatti misurabili. Non trattarlo come verità assoluta; trattalo come linguaggio comune per discutere trade-off.

Kano

Classifica feature in:

• Basic: se mancano, causano insoddisfazione; se presenti, non entusiasmano.
• Performance: più migliorano, più aumenta soddisfazione.
• Delighters: inattese, generano entusiasmo ma possono diventare basic nel tempo.

Cost of Delay

WSJF = Cost of Delay / Job Size

Utile quando il tempo cambia il valore: compliance, clienti enterprise, finestre di mercato, rischio operativo.

Pattern diagnostici ricorrenti

MAU cresce, DAU/MAU scende

Possibile interpretazione: acquisition cresce, abitudine no. Controlla qualità delle coorti e canali di acquisizione.

Activation bassa, retention degli attivati alta

Il problema è onboarding. Non serve cambiare core product finché più utenti non arrivano al primo valore.

Feature usage alto, retention invariata

La feature è usata ma non crea valore incrementale. Potrebbe essere obbligatoria, cosmetica o sostitutiva di un comportamento già esistente.

Retention D1 buona, D30 pessima

Il prodotto incuriosisce ma non diventa abitudine. Serve analisi di lifecycle, reminder, valore ricorrente, progress loop.

NPS alto, crescita bassa

Gli utenti soddisfatti potrebbero essere pochi o in segmento troppo stretto. Controlla mercato indirizzabile, referral e distribuzione.

Esempio di diagnosi in 10 righe

Un buon product analyst dovrebbe saper sintetizzare così:

Negli ultimi 6 mesi i MAU sono cresciuti del 22%, ma DAU/MAU è sceso da 24% a 18%. La retention D30 delle nuove coorti è passata da 8.1% a 5.0%, soprattutto nei canali paid TikTok. Gli utenti che completano l’activation event entro 30 minuti hanno D7 retention 4x rispetto agli altri. Il problema principale non è engagement dei power user, ma qualità acquisition + onboarding. Raccomando di ridurre time to activation, riallocare budget dai canali peggiori e testare onboarding guidato con metrica primaria activation rate.

Questa sintesi collega trend, causa probabile e decisione.

Riferimenti essenziali

• Croll, A. & Yoskovitz, B. (2013). Lean Analytics. O’Reilly.
• Kohavi, R., Tang, D., Xu, Y. (2020). Trustworthy Online Controlled Experiments. Cambridge University Press.
• McClure, D. (2007). AARRR Startup Metrics for Pirates.
• Ellis, S. materiali sul Sean Ellis PMF test.
• Kano, N. et al. (1984). Attractive Quality and Must-Be Quality.
• Reforge essays su retention, activation e growth loops.

Riepilogo

L’analisi di prodotto è l’arte di collegare comportamento utente, outcome business e decisioni roadmap. Le metriche non servono a decorare dashboard: servono a scegliere dove investire.

Se ricordi solo una cosa: non ottimizzare medie aggregate. Segmenta per coorte, comportamento, canale e fase del lifecycle. Il prodotto reale vive nelle differenze tra segmenti, non nella media.

Problema reale

Nel dominio di product analytics, Cheat Sheet — Analisi di Prodotto 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 Cheat Sheet — Analisi di Prodotto 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

Prima di una product review, la cheat sheet guida il controllo: definizione dell’utente attivo, funnel critico, coorti, segmenti, guardrail e insight qualitativi. Il valore è arrivare alla riunione con una diagnosi ordinata, non con una collezione di grafici.

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 Cheat Sheet — Analisi di Prodotto: 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 Cheat Sheet — Analisi di Prodotto 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

Cheat Sheet — Analisi di Prodotto 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: Sintesi Operativa. Difficoltà: advanced. Tempo stimato: 10 min.