Cheat Sheet: direzioni analitica

Quando devi confrontare ruoli analitici il rischio è usare etichette vaghe: data analyst, product analyst, business analyst, analytics engineer suonano tutti simili finché non guardi cosa fanno davvero. Questa scheda raccoglie distinzioni pratiche, cioè i problemi tipici, gli stakeholder, le metriche, i deliverable e i segnali di seniority di ciascun ruolo. Usala come postazione rapida quando devi orientare studio, portfolio o colloquio.

Come leggere la scheda

Lo scopo non è memorizzare titoli, ma collegare le competenze tecniche a contesti di lavoro reali. Prima di decidere quale direzione raccontare conviene fissare poche domande. Quale decisione vuoi rendere possibile con il tuo profilo? Quale dato o quale progetto la rende osservabile a chi ti valuta? E rispetto a quale baseline, cioè a quali altri candidati, ti stai confrontando?

Area	Controllo da mantenere
Question	Quale scelta deve cambiare dopo l’analisi
Dato	Quale evento, tabella o metrica rende osservabile il problema
Qualità	Quale errore di raccolta, modellazione o interpretazione può alterare il risultato
Baseline	Quale confronto impedisce una lettura isolata
Action	Quale raccomandazione diventa più difendibile

Se un esempio, una formula o un frammento tecnico non chiarisce almeno una di queste aree, trattalo come dettaglio secondario.

Il Product Analyst e la domanda “perché”

Il Product Analyst vive ossessionato da una domanda: perché. Perché gli utenti si iscrivono ma non completano l’onboarding? Perché adottano la funzionalità A e ignorano la B? Perché una coorte di maggio ha una retention a 30 giorni superiore di 5 punti percentuali rispetto a quella di aprile? Il ruolo sta all’intersezione tra data science, user experience e strategia di prodotto. L’obiettivo non è descrivere cosa accade, ma spiegare il perché e formulare ipotesi verificabili su come migliorare il prodotto.

Il ciclo di lavoro tipico è un loop continuo. Si parte da un’analisi esplorativa per identificare un’opportunità o un problema, per esempio un drop-off del 40% in un funnel di checkout. Si collabora poi con Product Manager e Designer per formulare un’ipotesi, del tipo “riducendo il numero di campi nel form aumenteremo la conversione”. Si progetta un A/B test per validarla e infine si analizzano i risultati per decidere se estendere la modifica a tutti gli utenti. Gli strumenti del mestiere sono piattaforme di event tracking come Amplitude o Mixpanel, che permettono di analizzare sequenze di azioni, e piattaforme di experimentation come Statsig o Optimizely. SQL resta la lingua franca per accedere ai dati grezzi, mentre Python, con Pandas, Matplotlib e SciPy, serve per le analisi statistiche più complesse come i test di significatività o l’analisi di causalità.

Caso reale: Spotify e Discover Weekly

Un esempio magistrale di product analytics in azione è il team di Spotify. Agli inizi l’azienda si concentrava su metriche di acquisizione, ma capì presto che la vera sfida era la retention a lungo termine in un mercato affollato. Analizzando miliardi di stream, il team di product analytics notò una correlazione fortissima tra il numero di brani che un utente salvava nelle proprie playlist entro la prima settimana e la sua probabilità di restare attivo dopo 3 mesi.

Da questa intuizione è nata una delle funzionalità più iconiche della piattaforma, Discover Weekly. Non era solo una playlist, era un motore di product-led growth: invece di aspettare che l’utente costruisse le proprie abitudini, Spotify gliele suggeriva in modo proattivo. Secondo i dati interni rilasciati, Discover Weekly ha portato a un aumento del 15% della sessione media di ascolto per chi la utilizzava e ha contribuito a ridurre il churn rate mensile di quasi 2 punti percentuali nel primo anno, un valore enorme per un’azienda con centinaia di milioni di utenti. È il potere del product analytics, che non ottimizza i margini ma crea valore nel prodotto, un valore che poi si auto-alimenta.

Mappa rapida dei quattro ruoli

Per orientarti in fretta, conviene fissare per ciascun ruolo la domanda che lo guida e il deliverable che lo rende riconoscibile. Il Product Analyst parte dal perché di un comportamento e consegna ipotesi testabili e letture di esperimenti. Il Marketing Analyst parte dall’efficacia della spesa e consegna stime di impatto incrementale e attribuzione. Il Financial Analyst parte dalla sostenibilità economica e consegna modelli di KPI legati a margine e cash flow. L’Analytics Engineer parte dall’affidabilità del dato e consegna modelli, test e documentazione su cui gli altri costruiscono.

La seniority, in tutti e quattro, non si misura sulla quantità di tool conosciuti ma sulla capacità di passare da un segnale a una decisione difendibile. Un junior descrive cosa è successo, un senior dice cosa conviene fare e perché.

Come usare la scheda in un colloquio

Davanti a chi ti valuta, la differenza tra un candidato confuso e uno credibile è quasi sempre la stessa: il secondo collega una metrica a una decisione. Se ti chiedono di un progetto, non descrivere lo strumento usato, racconta quale scelta hai reso possibile. Il caso Spotify funziona proprio perché lega un segnale osservabile (i brani salvati nella prima settimana) a una decisione di prodotto (lanciare Discover Weekly) e a un outcome misurabile (più ascolto, meno churn).

Lo stesso schema vale per gli altri ruoli. Un Marketing Analyst lega la spesa di campagna all’impatto incrementale, un Financial Analyst lega un KPI operativo al cash flow, un Analytics Engineer lega un modello dati alla fiducia che i consumer possono riporre nei numeri. In tutti i casi il segnale di seniority è la capacità di nominare la decisione, non l’elenco dei tool.

Errori tipici da evitare

L’errore più comune è usare l’etichetta del ruolo come decorazione invece che come criterio di scelta, presentando un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. In quel caso il dato sembra preciso ma non guida l’azione.

Sul piano dei dati gli errori ricorrenti sono tre. Lavorare su aggregati troppo presto, perché una media globale nasconde segmenti che si muovono in direzioni opposte. Non controllare la qualità del dato, perché duplicati, tracking incompleto, timezone incoerenti e definizioni cambiate producono conclusioni false. E confondere correlazione e causalità, perché gli utenti che usano una feature potrebbero convertire di più semplicemente perché erano già più motivati. Il caso Spotify è onesto su questo punto: parte da una correlazione e la trasforma in valore solo dopo averla testata con una funzionalità reale.

Summary

Questa scheda è utile quando riduce l’incertezza su una scelta reale di carriera o di analisi, non quando elenca titoli. La forma corretta resta sempre la stessa: quale decisione, quale segnale la rende osservabile, rispetto a quale baseline la leggi, quale rischio accetti e quale azione fai dopo. Product Analyst, Marketing Analyst, Financial Analyst e Analytics Engineer cambiano negli strumenti, ma condividono questo modo di ragionare, e il caso Spotify è l’esempio più chiaro di come un segnale ben scelto diventi una decisione che paga.