Operating model of product analytics

Sul binario tabellare anche un “operating model” si descrive con tabelle, rituali e owner assegnati. Strutturare il modo in cui un team fa product analytics è una scelta operativa, non un esercizio teorico. La categoria di questa lezione è Decisione: il punto non è accumulare definizioni, ma capire quale scelta cambia quando il dato diventa più affidabile. Il product analytics funziona quando eventi, roadmap, rituali di review e ownership delle metriche si tengono insieme. Un operating model serve a organizzare il lavoro tra product manager, design, engineering e data senza trasformare l’analista in un semplice produttore di dashboard.

La definizione in una frase

L’operating model del product analytics è il sistema di eventi, metriche, ownership e rituali che porta l’analisi dentro discovery, delivery e roadmap. Da qui parte tutto il resto della lezione.

La sequenza da seguire

1. Parti dalle domande di comportamento su acquisizione, attivazione, retention e monetizzazione.
2. Strumenta eventi e definizioni con owner e tracciamento stabile.
3. Fissa poche metriche con benchmark interno e finestra temporale dichiarata.
4. Assegna ownership, riti di review e soglie di intervento per ogni metrica.
5. Separa risposte rapide su behaviour tracking e analisi cross-dominio su warehouse.

Il problema che devi risolvere

Conoscere l’operating model in astratto non basta: serve decidere cosa fare quando hai dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Letta come disegno del sistema di lavoro del product analyst, la lezione mostra che il valore emerge quando discovery, instrumentation, analisi, esperimenti e decisioni di roadmap hanno un ritmo condiviso. Tre domande aiutano a impostarlo: quale rito di prodotto dovrebbe includere l’analytics, quale ownership evita metriche senza manutenzione, come proporresti un operating model a un team prodotto.

Una mappa di lavoro

Usa questa sequenza per evitare che una nozione tecnica diventi un rituale vuoto. Ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se organizziamo meglio l’analytics?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Capire il comportamento, non solo contarlo

Il product analyst parte sempre da una domanda sul comportamento umano, non su un numero: la domanda è “perché gli utenti abbandonano il carrello?”, non “quanto è il tasso di abbandono?”. Il numero è il punto di partenza, il comportamento è la domanda. Quattro domande organizzano tutto il lavoro. Acquisition: come scoprono il prodotto, qual è il canale più efficiente. Activation: qual è il momento “aha” che trasforma un visitatore in utente. Retention: perché gli utenti tornano e cosa li fa scappare. Monetization: quale comportamento porta alla conversione e qual è il modello di pricing ottimale.

These four questions form the funnel AARRR (Pirate Metrics), coniato da Dave McClure nel 2007, che rimane il framework di riferimento.

Verdetto: quattro domande di comportamento prima dei numeri, altrimenti misuri tutto e non spieghi nulla.

Le metriche di prodotto

Quando dici di “misurare il prodotto”, in pratica osservi un insieme ristretto di metriche, ciascuna con la sua formula e i suoi benchmark.

Metric	Formula	Why it matters	Benchmark
DAU/MAU	Daily ÷ Monthly Active Users	Stickiness	20-50% (app), 10-20% (web)
Retention D7/D30	% active users after N days	Product loyalty	20% D1, 10% D7, 5% D30 (mobile)
Session Length	Average session time	Engagement	Depends on category
Feature Adoption	% users using feature X	Feature relevance	New feature: 5-15% first month
Time to Value	Time between signup and “aha” moment	Onboarding effectiveness	<5 minutes is excellent
NPS / CSAT	Satisfaction survey	Perceived quality	NPS >30 is good (SaaS)
Conversion Rate	Completions ÷ Attempts	Funnel effectiveness	2-5% (e-commerce), 20-40% (freemium → paid)

La trappola del DAU/MAU merita attenzione: un DAU/MAU del 20% significa cose diverse in contesti diversi. Per un’app di messaggistica come WhatsApp i valori normali stanno tra 50% e 70%, perché l’uso quotidiano è la norma; per un’app di banking siamo intorno al 10-15%, con uso settimanale; per il food delivery si scende al 3-5%, con uso occasionale. Confrontare il DAU/MAU senza la categoria è inutile: il benchmark giusto è il tuo stesso prodotto nel trimestre precedente, non un numero generico.

Verdetto: confronta DAU/MAU e retention solo dentro la stessa categoria e contro il tuo trimestre precedente.

The product analyst’s tools

Il product analyst moderno lavora con quattro categorie di strumenti. Le product analytics platform come Amplitude, Mixpanel, PostHog e Heap tracciano eventi lato client e permettono analisi di funnel, retention e coorti senza SQL, ma dipendono dal tracking implementato. L’analytics warehouse-native, basata su dbt più un BI tool, è più potente e flessibile ma richiede competenze SQL; molte aziende stanno migrando da Amplitude al warehouse-native per i casi d’uso complessi, mantenendo Amplitude per le query rapide. Le piattaforme di A/B testing come Optimizely, LaunchDarkly, Eppo e Statsig gestiscono il ciclo completo dell’esperimento: assegnazione, tracking, analisi statistica. Gli strumenti qualitativi come UserTesting, Maze e le session recording (Hotjar, FullStory) catturano il “perché” dietro il “cosa”.

L’evoluzione del product analytics di Notion è un caso utile. Notion ha documentato il passaggio da un modello Amplitude-only a un modello ibrido. Fino al 2022 ogni domanda di prodotto passava da Amplitude, ma i limiti emersero quando il team iniziò a fare analisi cross-funzionali, per esempio il LTV degli utenti che avevano adottato la feature database, che richiedevano dati finanziari non presenti in Amplitude. La soluzione fu un modello a due livelli: Amplitude per le risposte rapide su behaviour tracking, cioè funnel, retention e coorti; dbt più Snowflake più Metabase per le analisi cross-dominio che uniscono dati di prodotto, finanziari e marketing.

Verdetto: risposte rapide su piattaforma eventi e analisi cross-dominio su warehouse, senza inseguire un unico strumento per tutto.

Product analyst e product data scientist

La linea tra product analyst e product data scientist è sempre più sottile, e una distinzione pratica si gioca sulla domanda di partenza. Il product analyst chiede “cosa sta succedendo?” e lavora in modo descrittivo e diagnostico, con SQL, dashboard, funnel e retention. Il product data scientist chiede “cosa succederebbe se?” e lavora in modo predittivo e causale, con causal inference, forecasting e modelli statistici. La differenza non è gerarchica ma di focus, e nelle aziende sotto i 200 dipendenti spesso una sola persona copre entrambi i ruoli.

Vale la pena chiedersi se è la direzione giusta per te. Lo è se sei ossessionato dal comportamento umano e dal perché le persone fanno ciò che fanno, se ti piace lavorare in team cross-funzionali con designer, PM ed engineer, se vuoi vedere l’impatto del tuo lavoro nel prodotto che usano milioni di persone e se sei a tuo agio con l’ambiguità, dato che le metriche di prodotto sono spesso segnali, non verità. Non lo è se preferisci la certezza dei numeri finanziari alla fuzziness delle metriche comportamentali, se non sopporti la discussione sulle definizioni delle metriche o se vuoi lavorare in isolamento tecnico senza interazione con stakeholder non tecnici.

Verdetto: analyst per descrivere e diagnosticare il presente, data scientist per stimare effetti causali e futuri.

Errore tipico e laboratorio

L’errore più comune è usare l’operating model 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. Un caso ricorrente è il team prodotto che lancia feature senza definire prima evento, metrica di successo e rituale di review; l’operating model diventa necessario proprio quando l’analytics deve entrare nel ciclo di discovery e delivery invece di arrivare dopo come spiegazione retrospettiva.

Livello base: scrivi una scheda di una pagina con decisione, metrica primaria, baseline, rischio principale e azione se il segnale è confermato. Livello intermedio: costruisci una tabella con tre segmenti, periodi o scenari, indicando per ciascuno cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione. 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.

References:

• McClure, D. (2007). “Startup Metrics for Pirates: AARRR!” 500 Startups.
• Spotify Engineering. (2019). “How We Measure Product Success at Spotify.” Spotify R&D Blog.
• Notion Engineering. (2023). “Our Data Stack: From Amplitude to the Modern Data Stack.” Notion Blog.
• Croll, A. & Yoskovitz, B. (2013). Lean Analytics. O’Reilly.

Il caso Notion del 2023

Notion ha documentato nel 2023 il passaggio dal modello Amplitude-only al modello ibrido a due livelli. Fino al 2022 ogni domanda di prodotto passava da Amplitude per funnel, retention e coorti veloci. Il limite emerse sulle analisi cross-funzionali come il LTV degli utenti che avevano adottato la feature database, che richiedeva dati finanziari assenti dalla piattaforma eventi. La soluzione unisce Amplitude per le risposte rapide e dbt con Snowflake e Metabase per le analisi cross-dominio. Il caso mostra che due livelli governati battono un unico strumento usato per tutto.

Domande per chiudere

1. Quale domanda di comportamento guida la tua metrica principale?
2. Quale benchmark interno usi invece di un numero generico?
3. Chi è l’owner della definizione e del rito di review?
4. Quando sposti un’analisi dalla piattaforma eventi al warehouse?