Data collection: fundamentals and strategy
How to design a robust data collection strategy: event tracking, ETL, quality at source.
What you will learn
- Understand the analytical problem and the decision-making context
- Apply examples, metrics, and controls to real cases
Links
Data collection: fundamentals and strategy
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
| Phase | What to clarify | Output |
|---|---|---|
| Question | Which real choice needs improvement? | Decision to make |
| Measure | Which observable signal represents the problem? | Metric or source data |
| Control | Which baseline makes the result interpretable? | Credible comparison |
| Action | What changes after the analysis? | Next operational step |
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.
| Element | Requested specification |
|---|---|
| Unit of analysis | evento, proprietà, utente, sessione o fonte dati |
| Primary signal | completezza, duplicati, consistenza semantica, copertura |
| Baseline | periodo precedente, gruppo comparabile, benchmark, scenario controfattuale |
| Decision | tracking plan, contratto evento, QA, correzione prioritaria |
| Risk | 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.
| Observed evidence | Cautious interpretation | Recommended action |
|---|---|---|
| The number improves | Could be a real effect or normal variation | Look for comparison and segment |
| One segment changes more than others | La media aggregata nasconde differenze | Separate cohorts or use cases |
| Cost grows along with the result | Impact must be read on the margin | Estimate trade-offs and sustainability |
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
- Which concrete decision should this lesson improve?
- Which unit of analysis makes the problem measurable?
- Which baseline would you use to avoid a naive reading?
- Which typical mistake could change the conclusion?
- Which output would you deliver to a non-technical stakeholder?
A starting scene
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.
The three pillars of 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.
The tracking framework
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 | |
|---|---|---|
| How it works | SDK in browser/app sends events to a collector | Server sends events via API/webhook |
| Advantages | Facile da implementare, dati ricchi (DOM, click, scroll) | Reliable, not blocked by ad-blocker, full control |
| Disadvantages | Blocked by ad-blocker, missing data, extra latency | Requires more backend development, less visual data |
| Ideal for | Web analytics, heatmap, A/B testing | Transactions, business-critical events |
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.
Real case: Netflix and the discipline of metrics
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.
Write a query that counts how many orders each user has made and shows name, email, and number of orders. Order by number of orders descending.
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.
Summary
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.
Related Path
Lessons to read together
Questi collegamenti portano la lezione dentro il resto del corso: basi da riprendere, passaggi successivi e connessioni tematiche tra moduli.