Analisi di coorte e behavioral cohorts

Le nuove iscrizioni crescono, ma alcune coorti tornano dopo una settimana e altre spariscono subito. Analisi di coorte e behavioral cohorts serve a separare data di ingresso, comportamento iniziale e valore nel tempo, così la crescita non viene letta come salute del prodotto senza prove.

Una scena da cui partire

Leggi la lezione come strumento per distinguere volume e qualità. Le coorti diventano utili quando rivelano quale comportamento iniziale anticipa retention, espansione o abbandono.

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

Perché la segmentazione demografica non basta

La segmentazione demografica ha un difetto fondamentale: assume che persone simili si comportino in modo simile. Ma nel prodotto digitale, questa assunzione collassa.

Prendiamo tre utenti di un’app di fitness:

• Marco, 28 anni, Milano, Android: corre 5 km ogni mattina, usa l’app per tracciare il percorso, ha attivato il premium dopo 3 giorni.
• Giulia, 28 anni, Milano, Android: ha aperto l’app due volte, non ha mai completato un allenamento, è sparita dopo la prima settimana.
• Ahmed, 52 anni, Il Cairo, browser web: corre 8 km a giorni alterni, usa l’app per le statistiche settimanali, premium dopo 10 giorni.

Demograficamente, Marco e Giulia sono gemelli. Comportamentalmente, Marco e Ahmed sono gemelli. Se segmenti per demografia, mescoli power user e dormant nella stessa coorte e qualunque media che calcoli è rumore puro.

Ecco il confronto tra i due approcci:

Approccio	Variabile di raggruppamento	Esempio	Cosa risponde
Demografico	Chi È l’utente	Età, paese, device, acquisizione	”Gli utenti iOS spendono più di quelli Android?”
Comportamentale	Cosa FA l’utente	Frequenza, feature usate, profondità	”I power user hanno davvero un LTV 3x?”
Coorte temporale	QUANDO ha iniziato	Mese di iscrizione	”La retention sta migliorando nel tempo?”

La behavioral cohort risponde alla domanda che interessa davvero al prodotto: come si comportano gli utenti e come evolvono nel tempo?

Coorti temporali vs coorti comportamentali

Facciamo chiarezza su un equivoco comune. L’analisi di coorte “classica” — quella che trovi in ogni dashboard di Amplitude o Mixpanel — è quasi sempre temporale: raggruppi gli utenti per settimana di acquisizione e misuri la retention nel tempo.

-- Coorte temporale classica: retention per settimana di acquisizione
SELECT
  DATE_TRUNC('week', signup_date) AS cohort_week,
  COUNT(DISTINCT user_id) AS cohort_size,
  ROUND(COUNT(DISTINCT CASE WHEN week_1_active THEN user_id END) * 100.0 / COUNT(*), 1) AS week1_retention,
  ROUND(COUNT(DISTINCT CASE WHEN week_2_active THEN user_id END) * 100.0 / COUNT(*), 1) AS week2_retention,
  ROUND(COUNT(DISTINCT CASE WHEN week_4_active THEN user_id END) * 100.0 / COUNT(*), 1) AS week4_retention,
  ROUND(COUNT(DISTINCT CASE WHEN week_12_active THEN user_id END) * 100.0 / COUNT(*), 1) AS week12_retention
FROM user_cohorts
GROUP BY cohort_week
ORDER BY cohort_week;

Questa analisi è utile per rispondere a: “la retention sta migliorando con le nuove versioni del prodotto?” Ma non risponde affatto a: “perché certi utenti restano e altri se ne vanno?”

La behavioral cohort parte da una domanda diversa: “quali pattern di comportamento definiscono un utente di successo?” Raggruppi in base alle azioni compiute, non alla data di iscrizione.

Costruire behavioral cohorts in SQL

Costruiamo un sistema di segmentazione comportamentale su quattro dimensioni:

1. Frequenza: quanti giorni attivi negli ultimi 30
2. Ampiezza: quante feature diverse usa
3. Profondità: qual è il volume totale di attività
4. Segnali chiave: ha compiuto le azioni critiche (acquisto, invito, creazione)?

WITH user_behavior_30d AS (
  SELECT
    user_id,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(*) AS total_events,
    COUNT(DISTINCT event_type) AS unique_event_types,
    MAX(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) AS has_purchased,
    MAX(CASE WHEN event_type = 'invite' THEN 1 ELSE 0 END) AS has_invited,
    MAX(CASE WHEN event_type = 'create_project' THEN 1 ELSE 0 END) AS has_created,
    AVG(session_duration_seconds) AS avg_session_secs
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'
    AND user_id IS NOT NULL
  GROUP BY user_id
)
SELECT
  user_id,
  CASE
    WHEN active_days >= 20 AND has_purchased = 1 AND has_invited = 1
      THEN 'champion'
    WHEN active_days >= 20 THEN 'power_user'
    WHEN active_days >= 10 THEN 'regular'
    WHEN active_days >= 3 THEN 'casual'
    WHEN active_days >= 1 THEN 'dormant'
    ELSE 'dead'
  END AS behavior_segment,
  active_days,
  total_events,
  unique_event_types,
  has_purchased,
  has_invited,
  ROUND(avg_session_secs, 0) AS avg_session_secs
FROM user_behavior_30d;

La gerarchia ha sei livelli, dai champion (che generano referral e revenue) fino ai dead (30 giorni senza attività). Ogni livello ha implicazioni operative diverse:

Segmento	Caratteristica	Azione prodotto
Champion	Usa, paga, invita	Nurturing, community, early access
Power User	Quotidiano, tutte le feature	Retention, upsell, ambassador program
Regular	Più volte a settimana	Deepening: fargli scoprire più feature
Casual	3-9 giorni/mese	Activation: spingerlo verso abitudine
Dormant	1-2 giorni/mese	Re-engagement: notifiche, email, offerte
Dead	Zero attività	Win-back campaign o disinvestimento

Il valore di questa segmentazione non è l’etichetta, ma la possibilità di tracciare il movimento tra segmenti.

La matrice di transizione comportamentale

Gli utenti non sono statici. Un dormant può diventare regular dopo una campagna di re-engagement. Un power user può decadere a casual dopo un’esperienza negativa. La fotografia mensile dei segmenti è utile, ma la vera potenza analitica sta nella matrice di transizione: dove vanno gli utenti da un mese all’altro?

WITH current_month AS (
  SELECT user_id, behavior_segment AS current_segment
  FROM user_behavior_monthly
  WHERE month_key = '2025-01'
),
previous_month AS (
  SELECT user_id, behavior_segment AS previous_segment
  FROM user_behavior_monthly
  WHERE month_key = '2024-12'
)
SELECT
  COALESCE(p.previous_segment, 'new') AS from_segment,
  c.current_segment AS to_segment,
  COUNT(*) AS users,
  ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER (
    PARTITION BY COALESCE(p.previous_segment, 'new')
  ), 1) AS pct
FROM current_month c
LEFT JOIN previous_month p ON c.user_id = p.user_id
GROUP BY COALESCE(p.previous_segment, 'new'), c.current_segment
ORDER BY from_segment, to_segment;

Leggendo questa matrice, emergono i veri segnali di salute del prodotto:

• Tasso di decadimento dei power user: che percentuale di power user scende a regular o casual? Se è sopra il 15% mensile, il prodotto ha un problema di esperienza o di valore percepito.
• Tasso di resurrezione: che percentuale di dormant torna attivo? Se è sotto il 5%, il re-engagement non funziona.
• Tasso di deepening: che percentuale di casual sale a regular? È il motore di crescita a lungo termine.

Il caso Netflix: quando la matrice salvò il prodotto

Nel 2012, Netflix analizzò la propria matrice di transizione e scoprì un pattern allarmante: il 22% dei power user decadeva a regular entro 2 mesi. Scavando, trovarono la causa: gli utenti binge-watching finivano i contenuti di loro interesse in 3-4 settimane e, non trovando altro di rilevante, riducevano l’uso.

La soluzione non fu aggiungere più contenuti (già lo facevano). Fu introdurre la personalizzazione predittiva: se l’algoritmo anticipa cosa guarderai dopo, il binge non si esaurisce mai. Il tasso di decadimento scese al 9% in 6 mesi, traducendosi in centinaia di milioni di retention revenue.

Il behavioral lifecycle framework

Ogni prodotto ha un ciclo di vita comportamentale. Non è il customer journey del marketing (awareness → consideration → purchase), ma la traiettoria d’uso:

New User ──activation──▶ Activated ──deepening──▶ Engaged ───power──▶ Power User
                            │                       │                    │
                            ▼                       ▼                    ▼
                         Dormant ◀────decay────────┘                    │
                            │                                            │
                            │              re-engagement                 │
                            └────────────────────────────────────────────┘
                            │
                            ▼
                         Churned (60+ giorni inattivo)

Ogni freccia ha un tasso misurabile e un owner nel team prodotto:

Transizione	Metrica	Owner tipico	Benchmark B2C
New → Activated	Activation rate	Growth / Onboarding	20-40%
Activated → Engaged	Deepening rate	Feature team	30-50%
Engaged → Power	Power conversion	Core product	10-25%
Qualunque → Dormant	Decay rate	Retention team	5-15% mensile
Dormant → Active	Resurrection rate	CRM / Lifecycle	3-8% mensile

Il product team dovrebbe avere un dashboard con questi cinque tassi e target trimestrali per ciascuno. Non basta guardare la retention aggregata: devi sapere dove stai perdendo utenti e perché.

Behavioral cohorts nel codice: Python per analisi avanzata

I segmenti comportamentali non sono statici. Ecco come implementare un’analisi di coorte comportamentale in Python con clustering non supervisionato, utile quando non sai a priori quali pattern definiscono i tuoi utenti:

import pandas as pd
import numpy as np
from sklearn.cluster import KMeans
from sklearn.preprocessing import StandardScaler
from datetime import datetime, timedelta

def build_behavioral_features(events_df: pd.DataFrame,
                              reference_date: datetime) -> pd.DataFrame:
    """
    Costruisce feature comportamentali per ogni utente
    basate sugli ultimi 30 giorni di attività.
    """
    cutoff = reference_date - timedelta(days=30)
    recent = events_df[events_df['event_time'] >= cutoff]

    features = recent.groupby('user_id').agg(
        active_days=('event_time', lambda x: x.dt.date.nunique()),
        total_events=('event_id', 'count'),
        unique_event_types=('event_type', 'nunique'),
        avg_events_per_day=('event_id', lambda x: len(x) / max(x.dt.date.nunique(), 1)),
        has_purchase=('event_type', lambda x: (x == 'purchase').any().astype(int)),
        has_invite=('event_type', lambda x: (x == 'invite').any().astype(int)),
        has_content_create=('event_type',
                           lambda x: (x.isin(['create_post', 'upload', 'comment'])).any().astype(int)),
        weekend_ratio=('event_time',
                      lambda x: (x.dt.dayofweek >= 5).mean()),
        avg_session_minutes=('session_duration_seconds',
                            lambda x: x.mean() / 60 if x.notna().any() else 0)
    ).reset_index()

    return features

def cluster_behaviors(features_df: pd.DataFrame,
                      n_clusters: int = 5) -> pd.DataFrame:
    """
    Applica K-Means sulle feature comportamentali
    per identificare segmenti naturali.
    """
    feature_cols = [c for c in features_df.columns
                    if c not in ['user_id']]

    scaler = StandardScaler()
    X_scaled = scaler.fit_transform(features_df[feature_cols].fillna(0))

    kmeans = KMeans(n_clusters=n_clusters,
                    random_state=42,
                    n_init=10)
    features_df['cluster'] = kmeans.fit_predict(X_scaled)

    # Dai un nome ai cluster in base ai centroidi
    centroids = pd.DataFrame(
        scaler.inverse_transform(kmeans.cluster_centers_),
        columns=feature_cols
    )

    # Ordina per active_days (cluster 0 = più attivo)
    centroids['cluster'] = range(n_clusters)
    centroids = centroids.sort_values('active_days', ascending=False)

    labels = ['power_users', 'regulars', 'casuals',
              'dormant', 'dead'][:n_clusters]
    cluster_labels = dict(zip(centroids['cluster'], labels))

    features_df['behavior_segment'] = features_df['cluster'].map(cluster_labels)
    return features_df

# Esempio di utilizzo
# features = build_behavioral_features(events_df, datetime(2025, 1, 15))
# segmented = cluster_behaviors(features, n_clusters=5)
# print(segmented['behavior_segment'].value_counts())

Questo approccio basato su clustering è potente perché scopre i segmenti anziché imporli: se i tuoi utenti si dividono naturalmente in 4 gruppi invece che 5, K-Means con 5 cluster ti dà un risultato forzato. Ecco perché nella pratica si usa il metodo del gomito (elbow method) per determinare il numero ottimale di cluster.

Caso reale: behavioral cohorts in Spotify

Torniamo a Spotify. Il team di data science ha costruito behavioral cohorts basate su quattro dimensioni comportamentali:

1. Volume di ascolto: minuti totali ascoltati in 30 giorni
2. Diversità: numero di artisti unici ascoltati (proxy per esplorazione)
3. Creazione: numero di playlist create o modificate (proxy per investimento personale)
4. Social: numero di brani condivisi o ascolti collaborativi (proxy per rete)

Incrociando queste dimensioni, hanno identificato sei segmenti comportamentali. Il segmento più prezioso non era quello con più minuti di ascolto, ma quello con alta diversità e alta creazione: utenti che esplorano e curano. Il loro LTV era 2.3x rispetto ai “passive listeners” (alto volume, zero creazione), perché l’investimento nella creazione di playlist genera lock-in: nessuno abbandona 40 playlist curate in tre anni.

Questa scoperta ha cambiato la strategia prodotto: l’onboarding è stato ridisegnato per far creare una playlist personalizzata entro i primi 10 minuti (invece che entro la prima settimana), e il tasso di creazione precoce è diventato la metrica North Star del team onboarding.

Retention per coorte comportamentale

Una delle applicazioni più potenti delle behavioral cohorts è incrociarle con l’analisi di retention temporale. Invece di chiederti “qual è la retention della coorte di gennaio?”, chiediti “qual è la retention dei power user vs casual che si sono iscritti a gennaio?”

WITH user_first_month_behavior AS (
  -- Comportamento nei primi 30 giorni dopo il signup
  SELECT
    u.user_id,
    COUNT(DISTINCT DATE(e.event_time)) AS first_month_active_days,
    COUNT(DISTINCT e.event_type) AS first_month_event_types
  FROM users u
  JOIN events e ON u.user_id = e.user_id
    AND e.event_time BETWEEN u.signup_date AND u.signup_date + INTERVAL '30 days'
  GROUP BY u.user_id
),
user_monthly_activity AS (
  -- Attività in ciascun mese successivo
  SELECT
    u.user_id,
    DATE_TRUNC('month', u.signup_date) AS signup_cohort,
    DATE_TRUNC('month', e.event_time) AS activity_month,
    (DATE_TRUNC('month', e.event_time) - DATE_TRUNC('month', u.signup_date))
      / INTERVAL '1 month' AS month_number
  FROM users u
  JOIN events e ON u.user_id = e.user_id
)
SELECT
  CASE
    WHEN f.first_month_active_days >= 20 THEN 'high_engagement'
    WHEN f.first_month_active_days >= 10 THEN 'medium'
    WHEN f.first_month_active_days >= 3 THEN 'low'
    ELSE 'minimal'
  END AS initial_behavior_segment,
  a.month_number,
  COUNT(DISTINCT a.user_id) AS retained_users
FROM user_monthly_activity a
JOIN user_first_month_behavior f ON a.user_id = f.user_id
WHERE a.signup_cohort >= '2024-01-01'
GROUP BY initial_behavior_segment, a.month_number
ORDER BY initial_behavior_segment, a.month_number;

I risultati di questo tipo di analisi sono quasi sempre identici in ogni prodotto: la retention a 12 mesi degli utenti ad alto engagement iniziale è 3-5x quella degli utenti a basso engagement. Il che ci porta al punto cruciale: la retention non si fixa a valle, si costruisce a monte, nell’onboarding.

Quando le behavioral cohorts falliscono

Nessuno strumento è perfetto. Le behavioral cohorts hanno tre limiti da conoscere:

1. Richiedono volume di dati comportamentali: se il tuo prodotto ha pochi eventi per utente (es. un’app usata una volta al mese), la segmentazione comportamentale è rumorosa. Aspetta di avere almeno 5-10 eventi per utente attivo prima di segmentare.

2. Sono retrospettive per costruzione: classifichi un utente come “power user” dopo che lo è già diventato. Per l’intervento predittivo, ti servono modelli di propensity che anticipano il segmento futuro.

3. Ignorano l’intent: due utenti con lo stesso comportamento possono avere motivazioni opposte. Il team di Intercom scoprì che i “power user” del loro prodotto includevano sia evangelist entusiasti sia utenti frustrati che usavano il prodotto per lavoro ma lo odiavano. Le behavioral cohorts vanno sempre validate con qualitativo (NPS, interviste, ticket di supporto).

Riferimenti e approfondimenti

• Croll, A. & Yoskovitz, B. (2013). Lean Analytics: Use Data to Build a Better Startup Faster. O’Reilly Media. — Capitolo 7 sulla segmentazione comportamentale per prodotto.
• McClure, D. (2007). Pirate Metrics: AARRR Framework. — Il framework che ha introdotto l’attivazione come metrica separata dall’acquisizione.
• Chen, A. (2021). The Cold Start Problem. Harper Business. — Tratta le behavioral cohorts nel contesto degli effetti di rete; essenziale per prodotti marketplace e social.
• Amplitude (2023). The Behavioral Cohorts Playbook. — Guida operativa all’implementazione di behavioral cohorts in Amplitude, applicabile a qualunque tool di product analytics.
• Kohavi, R., Tang, D., & Xu, Y. (2020). Trustworthy Online Controlled Experiments. Cambridge University Press. — Capitolo 5: segmentazione per eterogeneità degli effetti negli A/B test.

Riepilogo

Le behavioral cohorts spostano l’analisi da “chi è l’utente” a “cosa fa l’utente”. Sono lo strumento per rispondere alla domanda che ogni product manager si pone: quali comportamenti predicono il successo a lungo termine?

La matrice di transizione comportamentale ti dice dove stai perdendo utenti e dove li stai guadagnando. Il behavioral lifecycle framework assegna un owner e un target a ogni transizione. E l’analisi combinata coorti temporali × coorti comportamentali ti mostra se la retention sta migliorando per tutti o solo per chi già era engaged.

Nella prossima lezione useremo questi segmenti comportamentali per personalizzare esperimenti A/B e misurare l’effetto delle feature non sulla media, ma su ciascun segmento.

Problema reale

Nel dominio di product analytics, Analisi di coorte e behavioral cohorts 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 Analisi di coorte e behavioral cohorts 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

Una coorte che completa il setup entro il primo giorno mantiene il doppio della retention a 30 giorni rispetto a chi rimanda. Il caso mostra come una behavioral cohort può trasformare una correlazione in ipotesi di prodotto: rendere il setup più chiaro, più breve o più guidato.

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 Analisi di coorte e behavioral cohorts: 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 Analisi di coorte e behavioral cohorts 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

Analisi di coorte e behavioral cohorts 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.