Caso studio: analisi prodotto completa

Un prodotto cresce in acquisizione, ma il team non capisce perché activation, retention e soddisfazione non migliorano insieme. Caso studio: analisi prodotto completa mette questi segnali nello stesso percorso: journey, coorti, frizioni, ipotesi e raccomandazione di roadmap.

Una scena da cui partire

Leggi il caso come una consegna da product review. Ogni analisi deve avvicinare il team a una scelta: che cosa correggere, per chi, con quale impatto atteso e quale evidenza residua manca.

• Contesto: Quale contesto rende il caso difficile?
• Metodo: Quale evidenza cambia davvero la decisione?
• Applicazione: Quale lezione resta valida fuori dal caso specifico?

Contesto aziendale

FitTrack ha avuto una crescita forte negli ultimi 18 mesi grazie a campagne paid su TikTok, partnership con influencer fitness e una libreria crescente di programmi di allenamento. I numeri headline sembrano positivi:

• 2.000.000 download cumulati
• 500.000 MAU
• 95.000 DAU medi
• 42.000 abbonati premium
• revenue mensile ricorrente: circa 630.000 euro
• rating app store: 4.5/5

Ma il management vede segnali contraddittori:

• il costo di acquisizione sta aumentando
• la conversione trial → paid sembra stabile ma non cresce
• molte persone completano il primo allenamento ma non tornano
• il team marketing celebra download record, mentre il team prodotto teme churn nascosto

La tua missione è capire se FitTrack sta costruendo valore sostenibile o solo riempiendo un secchio bucato.

Fase 1: Health dashboard

Una health dashboard di prodotto non deve contenere tutte le metriche possibili. Deve contenere le metriche che descrivono il ciclo vitale del prodotto.

Per FitTrack scegliamo cinque famiglie:

1. Engagement: DAU, MAU, DAU/MAU ratio
2. Retention: D1, D7, D30
3. Activation: primo allenamento completato e time to first workout
4. Monetizzazione: trial start, trial conversion, ARPU
5. Soddisfazione: NPS, recensioni, ticket support

La prima query costruisce una vista mensile di base.

WITH monthly_activity AS (
  SELECT
    DATE_TRUNC('month', event_time) AS month,
    COUNT(DISTINCT user_id) AS mau,
    COUNT(DISTINCT CASE
      WHEN DATE(event_time) = DATE_TRUNC('day', event_time)
      THEN user_id
    END) AS active_users_marker
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '6 months'
  GROUP BY 1
),
daily_activity AS (
  SELECT
    DATE_TRUNC('month', event_time) AS month,
    DATE(event_time) AS day,
    COUNT(DISTINCT user_id) AS dau
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '6 months'
  GROUP BY 1, 2
)
SELECT
  m.month,
  m.mau,
  ROUND(AVG(d.dau), 0) AS avg_dau,
  ROUND(AVG(d.dau) * 100.0 / m.mau, 1) AS dau_mau_ratio
FROM monthly_activity m
JOIN daily_activity d ON m.month = d.month
GROUP BY m.month, m.mau
ORDER BY m.month;

Supponiamo che il risultato sia:

Mese	MAU	DAU medio	DAU/MAU
Agosto	410.000	91.000	22.2%
Settembre	445.000	94.000	21.1%
Ottobre	470.000	96.000	20.4%
Novembre	490.000	97.000	19.8%
Dicembre	510.000	96.000	18.8%
Gennaio	500.000	95.000	19.0%

La lettura è già interessante: MAU cresce, ma DAU/MAU scende. Il prodotto sta acquisendo o riattivando utenti mensili, ma l’abitudine quotidiana non cresce proporzionalmente. Per un’app fitness, questo è un segnale importante: l’abitudine è il cuore del valore.

Fase 2: Retention e curva di coorte

La metrica successiva è retention per coorte di signup. Non basta sapere che 500.000 utenti sono attivi nel mese: dobbiamo sapere quanti nuovi utenti tornano dopo il primo giorno, la prima settimana e il primo mese.

WITH signups AS (
  SELECT
    user_id,
    DATE(created_at) AS signup_date,
    DATE_TRUNC('month', created_at) AS signup_month
  FROM users
  WHERE created_at >= CURRENT_DATE - INTERVAL '6 months'
),
activity AS (
  SELECT DISTINCT
    user_id,
    DATE(event_time) AS active_date
  FROM events
),
retention AS (
  SELECT
    s.signup_month,
    s.user_id,
    MAX(CASE WHEN a.active_date = s.signup_date + INTERVAL '1 day' THEN 1 ELSE 0 END) AS retained_d1,
    MAX(CASE WHEN a.active_date BETWEEN s.signup_date + INTERVAL '7 days'
                              AND s.signup_date + INTERVAL '8 days' THEN 1 ELSE 0 END) AS retained_d7,
    MAX(CASE WHEN a.active_date BETWEEN s.signup_date + INTERVAL '30 days'
                              AND s.signup_date + INTERVAL '31 days' THEN 1 ELSE 0 END) AS retained_d30
  FROM signups s
  LEFT JOIN activity a ON s.user_id = a.user_id
  GROUP BY s.signup_month, s.user_id
)
SELECT
  signup_month,
  COUNT(*) AS cohort_size,
  ROUND(AVG(retained_d1) * 100, 1) AS d1,
  ROUND(AVG(retained_d7) * 100, 1) AS d7,
  ROUND(AVG(retained_d30) * 100, 1) AS d30
FROM retention
GROUP BY signup_month
ORDER BY signup_month;

Risultato ipotetico:

Coorte	Utenti	D1	D7	D30
Agosto	140.000	34.2%	17.8%	7.1%
Settembre	155.000	32.9%	16.2%	6.5%
Ottobre	170.000	31.0%	15.1%	6.1%
Novembre	210.000	28.4%	13.0%	5.2%
Dicembre	260.000	25.7%	11.4%	4.6%
Gennaio	180.000	26.1%	11.8%	non maturo

Qui emerge il primo insight serio: la crescita dei download ha peggiorato la qualità delle coorti. Le campagne paid hanno portato più utenti, ma meno intenzionati. Il marketing può dire “abbiamo portato volume”; il prodotto deve rispondere “il volume ha retention più bassa”.

Fase 3: Activation e aha moment

Per FitTrack, l’aha moment potrebbe essere: completare il primo allenamento e vedere il riepilogo progresso. Non basta aprire l’app. Non basta scegliere un obiettivo. Il valore arriva quando l’utente sperimenta un ciclo completo: piano → azione → feedback.

Misuriamo il time to aha.

WITH first_workout AS (
  SELECT
    user_id,
    MIN(event_time) AS first_workout_completed_at
  FROM events
  WHERE event_type = 'workout_completed'
  GROUP BY user_id
),
signups AS (
  SELECT user_id, created_at
  FROM users
)
SELECT
  COUNT(*) AS new_users,
  COUNT(f.user_id) AS activated_users,
  ROUND(COUNT(f.user_id) * 100.0 / COUNT(*), 1) AS activation_rate,
  ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_workout_completed_at - s.created_at)) / 60
  ), 1) AS median_minutes_to_first_workout
FROM signups s
LEFT JOIN first_workout f ON s.user_id = f.user_id
WHERE s.created_at >= CURRENT_DATE - INTERVAL '30 days';

Supponiamo:

• activation rate: 38%
• tempo mediano al primo workout: 47 minuti
• D7 retention per attivati: 24%
• D7 retention per non attivati: 3%

Questa è la diagnosi centrale: FitTrack non ha un problema generico di retention. Ha un problema di activation. Chi completa il primo allenamento resta abbastanza bene; chi non lo completa sparisce.

Fase 4: Behavioral segmentation

Ora costruiamo segmenti comportamentali sugli ultimi 30 giorni. In un’app fitness, le dimensioni rilevanti sono:

• giorni attivi
• allenamenti completati
• varietà di programmi usati
• uso di tracking peso/misure
• interazioni social o challenge
• premium status

WITH behavior AS (
  SELECT
    user_id,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(*) FILTER (WHERE event_type = 'workout_completed') AS workouts,
    COUNT(DISTINCT metadata->>'program_id') FILTER (WHERE event_type = 'workout_completed') AS programs_used,
    COUNT(*) FILTER (WHERE event_type = 'progress_logged') AS progress_logs,
    COUNT(*) FILTER (WHERE event_type = 'challenge_joined') AS challenges_joined,
    MAX(CASE WHEN event_type = 'subscription_started' THEN 1 ELSE 0 END) AS is_premium_signal
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'
  GROUP BY user_id
)
SELECT
  CASE
    WHEN active_days >= 20 AND workouts >= 12 THEN 'athlete_power'
    WHEN active_days >= 10 AND workouts >= 6 THEN 'consistent_builder'
    WHEN active_days >= 3 THEN 'casual_mover'
    WHEN active_days >= 1 THEN 'curious_dormant'
    ELSE 'inactive'
  END AS segment,
  COUNT(*) AS users,
  ROUND(AVG(workouts), 1) AS avg_workouts,
  ROUND(AVG(progress_logs), 1) AS avg_progress_logs,
  ROUND(AVG(challenges_joined), 1) AS avg_challenges,
  ROUND(AVG(is_premium_signal) * 100, 1) AS premium_signal_rate
FROM behavior
GROUP BY 1
ORDER BY users DESC;

Risultato ipotetico:

Segmento	Utenti	Workout medi	Premium rate
curious_dormant	210.000	0.4	1.2%
casual_mover	160.000	2.1	3.8%
consistent_builder	85.000	7.4	13.5%
athlete_power	45.000	18.2	31.0%

Il segmento power è piccolo ma economicamente fondamentale. Gli athlete_power sono solo il 9% dei MAU, ma generano probabilmente una quota sproporzionata di abbonamenti, referral e contenuto sociale. La domanda strategica diventa: quale comportamento precoce predice il passaggio da casual_mover a consistent_builder?

Fase 5: Driver analysis

Per rispondere, confrontiamo utenti che diventano consistent_builder con utenti che restano casual. Guardiamo i comportamenti nei primi 7 giorni.

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler
from sklearn.pipeline import Pipeline

# Dataset ipotetico: una riga per utente
# target = 1 se l'utente diventa consistent_builder entro 30 giorni
features = [
    "completed_first_workout",
    "minutes_to_first_workout",
    "selected_goal",
    "enabled_notifications",
    "logged_weight",
    "joined_challenge",
    "viewed_progress_summary",
    "number_of_sessions_d7"
]

model = Pipeline([
    ("scaler", StandardScaler()),
    ("logit", LogisticRegression(max_iter=1000))
])

model.fit(df[features], df["became_consistent_builder"])

coefficients = pd.DataFrame({
    "feature": features,
    "coefficient": model.named_steps["logit"].coef_[0]
}).sort_values("coefficient", ascending=False)

print(coefficients)

Supponiamo che i driver più forti siano:

1. completare il primo workout entro 15 minuti
2. vedere il riepilogo progresso subito dopo
3. abilitare reminder personalizzati
4. unirsi a una challenge entro 7 giorni

Questo trasforma la diagnosi in azione. Non dobbiamo genericamente “migliorare retention”. Dobbiamo aumentare la percentuale di nuovi utenti che arriva al primo workout rapidamente e poi vede un feedback motivante.

Caso reale: Strava e il valore del ciclo sociale

Strava è un esempio reale utile perché il suo valore non nasce solo dal tracking, ma dal ciclo sociale: registra attività, ricevi kudos, confronti segmenti, torni a registrare. Nel fitness digitale, la retention cresce quando l’utente accumula storia personale e connessioni sociali.

Strava ha costruito nel tempo un prodotto in cui l’attività non è solo dato privato, ma oggetto sociale. Questo crea lock-in: abbandonare l’app significa perdere cronologia, segmenti, community e reputazione. FitTrack, nel nostro caso, sembra invece concentrata sul completamento individuale dell’allenamento. L’analisi potrebbe suggerire di introdurre challenge e feedback sociale non come feature accessoria, ma come meccanismo di retention.

Il punto non è copiare Strava. È capire il principio: nei prodotti fitness, la retention nasce da abitudine, progresso visibile e identità. Se l’utente si vede come “persona che si allena”, il prodotto diventa parte della sua routine.

Fase 6: Raccomandazioni operative

Una buona analisi prodotto termina con decisioni. Non con “monitorare la metrica”. Per FitTrack proponiamo tre iniziative.

Iniziativa 1: Quick win — onboarding orientato al primo workout

Ipotesi: riducendo il tempo al primo workout sotto 15 minuti, aumenteremo activation e D7 retention.

Intervento:

• eliminare passaggi non essenziali nel setup
• proporre un workout di 7 minuti immediato
• mostrare riepilogo progresso dopo il completamento
• rimandare personalizzazioni avanzate al secondo accesso

Metrica target:

• activation rate: da 38% a 48%
• median time to first workout: da 47 min a <15 min
• D7 retention nuovi utenti: da 11.8% a 15%

Effort: 1 sprint.

Confidence: alta, perché la driver analysis mostra forte relazione tra primo workout rapido e retention.

Iniziativa 2: Strategica — challenge sociali per casual_mover

Ipotesi: trasformare l’allenamento da attività solitaria a impegno sociale aumenterà il passaggio casual_mover → consistent_builder.

Intervento:

• challenge settimanali a bassa barriera
• invito amici dopo il primo workout completato
• badge visibili e progressi condivisibili
• reminder legati alla challenge, non notifiche generiche

Metrica target:

• transition casual_mover → consistent_builder: da 18% a 25%
• challenge join rate entro D7: 12% → 28%
• D30 retention: +2 punti percentuali

Effort: 1 quarter.

Confidence: media. Evidenza da benchmark e correlazioni interne, ma serve esperimento.

Iniziativa 3: Moonshot — coach adattivo basato sui dati

Ipotesi: un coach personalizzato che adatta intensità e suggerimenti ridurrà churn tra utenti che falliscono i primi obiettivi.

Intervento:

• modello che identifica rischio abbandono dopo workout saltati
• raccomandazioni adattive di intensità
• messaggi motivazionali basati su comportamento reale
• downgrade automatico del piano se l’utente fatica

Metrica target:

• decay consistent_builder → casual_mover: -20%
• retention D60 premium: +5 punti
• NPS utenti premium: +8 punti

Effort: 2 quarter.

Confidence: bassa-media. Alto potenziale, alta complessità.

Executive summary finale

Se dovessi presentare al CEO, diresti:

FitTrack cresce in MAU, ma la qualità delle coorti è peggiorata negli ultimi sei mesi. Il problema principale non è la monetizzazione né l’uso da parte dei power user: è l’activation dei nuovi utenti. Chi completa il primo workout resta molto di più; chi non lo completa abbandona quasi subito. La priorità dei prossimi 30 giorni dovrebbe essere ridurre drasticamente il time to first workout. In parallelo, dobbiamo trasformare i casual users in utenti consistenti attraverso challenge sociali e feedback di progresso. La roadmap proposta è: quick win su onboarding, iniziativa strategica su social challenge, moonshot su coach adattivo.

Questo è ciò che rende un’analisi utile: una diagnosi, una causa probabile, un piano e metriche di verifica.

Riferimenti

• Croll, A. & Yoskovitz, B. (2013). Lean Analytics. O’Reilly. Framework per scegliere metriche in base alla fase del business.
• Kohavi, R., Tang, D., Xu, Y. (2020). Trustworthy Online Controlled Experiments. Cambridge University Press. Metodi per validare iniziative con esperimenti online.
• McClure, D. (2007). AARRR Pirate Metrics. Framework acquisition, activation, retention, referral, revenue.
• Fogg, B.J. (2009). A Behavior Model for Persuasive Design. Persuasive Technology. Utile per comprendere motivazione, trigger e abilità nell’onboarding.
• Materiali pubblici di Strava su community, segmenti e social fitness come meccanismo di engagement.

Riepilogo

Un caso studio completo di product analytics parte dai numeri headline ma non si ferma lì. MAU e revenue dicono se il prodotto cresce; retention e activation dicono se cresce bene. La segmentazione comportamentale mostra quali utenti generano valore. La driver analysis collega comportamenti iniziali a risultati futuri. Le raccomandazioni trasformano l’analisi in roadmap.

Per FitTrack la diagnosi è chiara: il prodotto non deve semplicemente acquisire più utenti. Deve far arrivare più persone al primo ciclo di valore — allenamento completato, feedback ricevuto, motivazione rinforzata — nel minor tempo possibile.

Problema reale

Nel dominio di product analytics, Caso studio: analisi prodotto completa 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 Caso studio: analisi prodotto completa 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

Nel caso completo il team vede activation bassa tra utenti self-service, retention migliore tra utenti invitati da colleghi e NPS polarizzato. La raccomandazione deve collegare questi segnali: quale frizione correggere, quale segmento servire prima e quale esperimento usare per verificare l’ipotesi.

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 Caso studio: analisi prodotto completa: 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 Caso studio: analisi prodotto completa 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

Caso studio: analisi prodotto completa 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: Lab. Difficoltà: advanced. Tempo stimato: 28 min.