Cheat Sheet: direzioni analitica

Quando confronti ruoli analitici, il rischio è usare etichette vaghe. Data Analyst, Product Analyst, Business Analyst e Analytics Engineer suonano simili finché non guardi cosa fanno davvero. Questa scheda raccoglie distinzioni pratiche. Per ciascun ruolo trovi problemi tipici, stakeholder, metriche, deliverable e segnali di seniority. Usala come postazione rapida per orientare studio, portfolio o colloquio. La teniamo sul binario tabellare: ogni ruolo ha la sua riga, ogni confronto la sua colonna.

Di cosa parla questa scheda

Questa scheda collega ciascun ruolo analitico al problema che risolve, allo stakeholder che serve e alla decisione che rende possibile.

Come usarla in cinque mosse

1. Scegli il ruolo da valutare tra Product Analyst, Marketing Analyst, Financial Analyst e Analytics Engineer.
2. Scrivi la domanda guida del ruolo e il deliverable che lo rende riconoscibile.
3. Collega una metrica del ruolo a una decisione concreta che quella metrica rende possibile.
4. Indica la baseline rispetto a cui leggi la metrica e il rischio principale della lettura.
5. Verifica che il profilo racconti una decisione resa possibile e non un elenco di tool.

Come leggere la scheda

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

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é”

The 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. L’obiettivo è spiegare il perché e formulare ipotesi verificabili su come migliorare il prodotto.

Il ciclo di lavoro tipico è un loop continuo in quattro passi. 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. Poi si collabora con Product Manager e Designer per formulare un’ipotesi, del tipo «riducendo i campi nel form aumenteremo la conversione». Si progetta un A/B test per validarla. Infine si analizzano i risultati per decidere se estendere la modifica a tutti gli utenti. Gli strumenti sono piattaforme di event tracking come Amplitude o Mixpanel, utili per sequenze di azioni, e piattaforme di experimentation come Statsig o Optimizely. SQL resta la lingua franca per i dati grezzi. Python, con Pandas, Matplotlib e SciPy, serve per analisi statistiche più complesse come test di significatività o analisi di causalità.

Mappa rapida dei quattro ruoli

Per orientarti in fretta, fissa per ciascun ruolo la domanda guida e il deliverable 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 sui tool conosciuti. Si misura sulla capacità di passare da un segnale a una decisione difendibile. Un junior descrive cosa è successo. Un senior dice cosa conviene fare e perché.

Verdetto: il ruolo giusto è quello la cui domanda guida ti dà energia e il cui deliverable sai già produrre con prove, non quello con il titolo più alla moda.

Come usare la scheda in un colloquio

Davanti a chi ti valuta, la differenza è quasi sempre la stessa. Il candidato credibile 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 per questo. 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 e 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 ripongono nei numeri. In tutti i casi il segnale di seniority è nominare la decisione, non elencare i tool.

Errori tipici da evitare

L’errore più comune è usare l’etichetta del ruolo come decorazione invece che come criterio di scelta. Succede quando presenti 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 opposti. Non controllare la qualità del dato, perché duplicati, tracking incompleto, timezone incoerenti e definizioni cambiate producono conclusioni false. Confondere correlazione e causalità, perché gli utenti che usano una feature potrebbero convertire di più solo 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.

Un esempio che fa da sponda: Spotify e Discover Weekly

Un esempio magistrale di product analytics in azione è il team di Spotify, che ha lanciato la playlist Discover Weekly a luglio 2015. 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: non era solo una playlist, era un motore di product-led growth che suggeriva abitudini di ascolto in modo proattivo invece di aspettare che l’utente le costruisse. 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.

Domande per chiudere la lezione

1. Quale domanda guida distingue il Product Analyst dagli altri tre ruoli e quale deliverable lo rende riconoscibile?
2. Come colleghi una metrica del tuo ruolo a una decisione concreta in un colloquio?
3. Quale baseline rende interpretabile il segnale che presenti e cosa cambia se la modifichi?
4. Quale dei tre errori sui dati invalida più spesso la tua analisi e come lo intercetti?