Data collection: fondamenti e strategia
Come progettare una strategia di raccolta dati robusta: event tracking, ETL, qualità alla fonte.
Cosa imparerai
- Comprendere il problema analitico e il contesto decisionale
- Applicare esempi, metriche e controlli a casi reali
Collegamenti
Data collection: fondamenti e strategia
Una dashboard può sembrare precisa e contenere dati inutili, se nessuno ha deciso prima quali comportamenti osservare, con quale dettaglio e per quale decisione. La raccolta dati non comincia dal tool ma da un tracking plan che separa gli eventi necessari, le proprietà critiche e il rumore. Questa lezione costruisce quella base.
Il problema da risolvere
Nel dominio della raccolta dati il problema è ottenere eventi affidabili prima che dashboard e modelli amplifichino errori invisibili. Non è teoria astratta, è il modo in cui si migliora una scelta concreta con dati, assunzioni esplicite e qualche controllo minimo.
L’obiettivo operativo resta lo stesso, comprendere il problema analitico e il contesto decisionale, e applicare esempi, metriche e controlli a casi reali. Se non sai indicare quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora diventata competenza.
Un modello di lavoro
| 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 è semplice, decisione, dato, controllo, azione. Ogni approfondimento tecnico deve rafforzare almeno uno di questi punti.
Come formalizzare l’analisi
Per analizzare la raccolta dati definisci prima l’unità di lavoro, cioè evento, proprietà, utente, sessione o fonte dati. Collega questa unità a una metrica osservabile come completezza, duplicati, consistenza semantica o copertura dei casi. Infine dichiara la decisione attesa, dal tracking plan al contratto evento, dalla QA alla correzione prioritaria.
| Elemento | Specifica richiesta |
|---|---|
| Unità di analisi | evento, proprietà, utente, sessione o fonte dati |
| Segnale principale | completezza, duplicati, consistenza semantica, copertura |
| Baseline | periodo precedente, gruppo comparabile, benchmark, scenario controfattuale |
| Decisione | tracking plan, contratto evento, QA, correzione prioritaria |
| Rischio | scambiare un numero disponibile per una prova sufficiente |
La formalizzazione regge quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione con gli stessi dati.
Un caso pratico
Un team deve rifare le dashboard marketing perché i numeri non tornano tra CRM, analytics e warehouse. Prima di costruire nuovi report ricostruisce il percorso del dato dalla fonte alla metrica finale e decide quali eventi devono diventare un contratto condiviso.
| 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 differenze | Separare coorti o casi d’uso |
| Il costo cresce insieme al risultato | L’impatto va letto sul margine | Stimare trade-off e sostenibilità |
Lab ed esercizi
Al livello base scrivi una scheda di una pagina per la lezione, con la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione se il segnale è confermato.
Al livello intermedio costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione.
Al 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. Come materiale usa un tracking plan, un log eventi, GA4, un CDP, il warehouse o un dataset sintetico di sessioni. Se non hai dati reali, creane uno con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.
L’errore tipico da evitare
L’errore più comune è usare la raccolta dati come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza dire quale assunzione potrebbe invalidarla.
La domanda di controllo è semplice. Se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.
Domande di verifica
- Quale decisione concreta dovrebbe migliorare questa lezione?
- Quale unità di analisi rende il problema misurabile?
- Quale baseline useresti per evitare una lettura ingenua?
- Quale errore tipico potrebbe cambiare la conclusione?
- Quale output consegneresti a uno stakeholder non tecnico?
Una scena da cui partire
Ogni evento raccolto dovrebbe avere un responsabile, una definizione chiara, le proprietà minime, dei criteri di validazione e un uso previsto. Se un dato non sostiene una domanda reale, aggiunge solo manutenzione senza valore. Prima di tracciarlo chiediti quale vincolo tecnico guida il disegno, quale controllo ne garantisce l’affidabilità e quale compromesso racconteresti prima di metterlo in produzione.
I tre pilastri della data collection
Tre scelte fondano tutto il resto. La prima è cosa raccogliere, cioè quali eventi, proprietà ed entità, partendo dai requisiti di business e non dall’idea di “tracciare tutto”. La seconda è come raccogliere, tra client-side con SDK e pixel, server-side con API e webhook, e database con CDC ed ETL. La terza è la qualità alla fonte, fatta di validazione, schema enforcement e deduplicazione, perché dati sporchi a monte generano insight sbagliati a valle.
Il framework di tracking
Un tracking plan risponde a quattro domande. Quali eventi servono, per esempio page_view, add_to_cart, purchase. Quali proprietà per ogni evento, dato che page_view porta page_url e referrer mentre purchase porta order_id, amount e currency. Quali entità e utenti, con identificativi univoci e proprietà statiche e dinamiche. E quale granularità temporale, distinguendo event time e server time e decidendo se il batching è consentito. Il tracking plan è un documento vivo, versionato e con ownership chiara, non un foglio Excel dimenticato in una cartella.
Client-side e server-side a confronto
| Client-side | Server-side | |
|---|---|---|
| Come funziona | SDK nel browser/app invia eventi a un collector | Il server invia eventi via API/webhook |
| Vantaggi | Facile da implementare, dati ricchi (DOM, click, scroll) | Affidabile, non bloccato da ad-blocker, controllo completo |
| Svantaggi | Bloccato da ad-blocker, dati mancanti, latenza extra | Richiede più sviluppo backend, meno dati visuali |
| Ideale per | Web analytics, heatmap, A/B testing | Transazioni, eventi business-critical |
Un’architettura matura usa entrambi, il client-side per i dati comportamentali e il server-side per quelli transazionali, con una riconciliazione tra le fonti.
Leggere la raccolta dati come sistema
La raccolta dati non vive isolata. È parte di un sistema fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio è trattarla come una definizione da ricordare, mentre serve capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni saltano.
La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questa analisi. Dashboard, query e modelli hanno valore solo se riducono l’incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.
Una sequenza utile parte dal definire il problema in linguaggio business, poi identifica l’unità di analisi corretta tra utente, account, evento, sessione, ordine e campagna, verifica se i dati misurano davvero il fenomeno o solo una sua ombra, costruisce una metrica interpretabile, segmenta per non lasciare che la media nasconda pattern opposti e trasforma il risultato in una raccomandazione verificabile.
Caso reale: Netflix e la disciplina delle metriche
Netflix costruisce le decisioni di prodotto intorno a segnali comportamentali osservabili, come il completamento degli episodi, il tempo di ricerca, l’abbandono precoce, il ritorno settimanale e l’efficacia delle raccomandazioni. Il dato è infrastruttura decisionale, non ornamento.
Quando valuta una modifica, Netflix non misura solo il click immediato ma anche i segnali di qualità, se l’utente guarda davvero, se torna, se riduce il tempo di ricerca, se aumenta la soddisfazione implicita. Questo impedisce di ottimizzare vanity metric che sembrano positive nel breve e danneggiano il valore nel lungo periodo. Lo stesso principio vale qui, perché la raccolta dati deve collegarsi a un outcome. Se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.
Esempio SQL: una vista di controllo
L’obiettivo è creare una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica. La query seleziona gli eventi degli ultimi 180 giorni, li raggruppa per settimana, utente, fonte e dispositivo e calcola eventi totali, giorni attivi, diversità degli eventi e se è stato raggiunto un outcome chiave, per esempio un acquisto.
Il risultato viene poi aggregato per settimana, fonte e dispositivo, mostrando numero di utenti, media dei giorni attivi, diversità degli eventi e tasso di outcome chiave. Questa vista serve a osservare trend, segmenti e variazioni, da cui formulare ipotesi più precise.
Scrivi una query che conti quanti ordini ha effettuato ogni utente e mostri nome, email e numero di ordini. Ordina per numero di ordini decrescente.
Esempio Python: stabilità e anomalie
Una metrica utile deve essere stabile per orientare le decisioni e sensibile per segnalare cambiamenti reali. In Python si calcola la variazione settimana su settimana e si identificano le anomalie con uno z-score basato su rolling mean e deviazione standard. Così si evita di reagire alle oscillazioni casuali e si segnalano solo le variazioni che meritano un’indagine, alimentando alert e review settimanali.
Gli errori che si ripetono
Il primo errore è lavorare su dati troppo aggregati troppo presto, perché la media globale nasconde pattern opposti. Il secondo è non controllare la qualità del dato, lasciando passare duplicati, tracking incompleto, timezone incoerenti e cambi di definizione. Il terzo è confondere correlazione e causalità, dato che un’associazione non implica che la feature causi la conversione. Per ridurre i rischi ogni analisi dovrebbe includere una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.
Riepilogo
La raccolta dati è uno strumento decisionale, non un argomento da manuale. Il valore nasce collegando problema, dati, metrica, segmentazione e azione. Un’analisi non si chiude con “il numero è salito” o “è sceso”, ma con una frase operativa, quale decisione prendiamo, con quale confidenza e quale metrica useremo per verificarla.
Percorso collegato
Lezioni da leggere insieme
Questi collegamenti portano la lezione dentro il resto del corso: basi da riprendere, passaggi successivi e connessioni tematiche tra moduli.