Event tracking: practical implementation

L’evento signup_completed sembra semplice finché qualcuno non chiede se include le email verificate, gli account invitati o gli utenti creati da un admin. L’implementazione pratica del tracking serve proprio a trasformare intenzioni vaghe in eventi testabili, versionati e coerenti tra frontend, backend e warehouse. È questo il confine su cui lavoriamo in questa lezione.

Real-world problem

Nel campo della raccolta dati il problema è ottenere eventi affidabili prima che dashboard e modelli amplifichino errori invisibili. Non è teoria isolata: serve a migliorare una scelta concreta con dati, assunzioni esplicite e controlli minimi. Se non sai dire quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora competenza applicata.

Conceptual model

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

Questi quattro punti, decisione, dato, controllo e azione, guidano ogni approfondimento tecnico che segue.

Rigorous formalization

Per rendere analizzabile il tracking definisci l’unità di lavoro, che può essere un evento, una proprietà, un utente, una sessione o una fonte dati. La colleghi a una metrica osservabile come la completezza, i duplicati, la consistenza semantica o la copertura, e poi dichiari la decisione attesa: un tracking plan, un contratto evento, una QA o una 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.

Example or case study

Il team nota che il funnel di onboarding cambia ogni settimana perché alcuni eventi vengono inviati due volte e altri mancano su mobile. La priorità diventa scrivere test di tracking, controllare i duplicati e fissare una definizione unica per ogni step.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Cercare confronto e segmentazione
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

Anatomy of an event

Un evento si definisce con nome, trigger, proprietà, tipi, esempi, casi esclusi e test di qualità. Il tracking è professionale quando un cambio di prodotto non altera in silenzio il significato della metrica.

Ecco un esempio di evento in JSON:

{
  "event": "purchase_completed",
  "user_id": "usr_abc123",
  "anonymous_id": "anon_xyz789",
  "timestamp": "2024-03-15T14:30:00Z",
  "properties": {
    "order_id": "ord_456",
    "amount": 99.99,
    "currency": "EUR",
    "products": [{"sku": "ABC", "qty": 2}]
  },
  "context": {
    "page_url": "/checkout/confirmation",
    "user_agent": "Mozilla/5.0...",
    "ip": "1.2.3.4"
  }
}

Sul piano pratico conviene usare user_id quando l’utente è autenticato e anonymous_id altrimenti, così da unire il percorso prima e dopo il login. Il timestamp indica quando è successo l’evento, non quando è stato processato. Il context raccoglie i metadati automatici come URL, user agent e IP, tenuti separati dalle proprietà di business.

Handling errors

Il tracking non deve mai bloccare l’esperienza dell’utente. Il primo pattern è il fire-and-forget, cioè l’invio in background senza attendere risposta. Quando una chiamata fallisce serve un retry con backoff, che riprova dopo intervalli crescenti. Un buffer locale in localStorage salva gli eventi per inviarli in un secondo momento. In nessun caso il codice di tracking deve lanciare eccezioni capaci di interrompere l’app.

Batching

Inviare un evento alla volta è inefficiente. Raggruppare 10-20 eventi per batch, oppure spedire ogni 5-10 secondi, riduce le richieste HTTP del 90% senza che l’utente percepisca alcuna perdita di freschezza.

Real case: Netflix and the discipline of metrics

Netflix costruisce le decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca, abbandono precoce, ritorno settimanale, efficacia delle raccomandazioni. Il punto non è copiare Netflix, ma adottare lo stesso approccio metodologico, in cui il dato è infrastruttura decisionale e non ornamento.

Netflix non misura solo il click immediato, ma anche segnali di qualità come il tempo di visione o il ritorno. È così che evita di ottimizzare vanity metric che sembrano positive nel breve ma erodono il valore nel lungo periodo.

Lo stesso principio vale per il tracking, che deve restare collegato a un outcome concreto. Se il risultato non aiuta a scegliere tra due azioni, l’analisi è incompleta.

SQL example: building a control view

Una query generica crea una base analitica con metrica, segmento e finestra temporale. Seleziona gli eventi degli ultimi 180 giorni con user_id non nullo, li raggruppa per settimana, utente, fonte e dispositivo, e calcola metriche come eventi totali, giorni attivi, diversità degli eventi e raggiungimento dell’outcome chiave. Aggregando poi per settimana, fonte e dispositivo puoi osservare trend e segmenti, e formulare ipotesi più precise partendo da una superficie di osservazione comune.

Python example: checking stability and anomalies

Una metrica utile deve essere allo stesso tempo stabile e sensibile. In Python calcoli la variazione settimana su settimana, la media mobile, la deviazione standard e lo z-score per individuare le anomalie significative. Così eviti di reagire alle oscillazioni casuali e segnali solo le variazioni che meritano un’indagine.

Common mistakes to avoid

L’aggregazione fatta troppo presto è il rischio più frequente: una media globale può nascondere segmenti che si muovono in direzioni opposte. Poi c’è la qualità del dato, che va sempre verificata, perché duplicati, tracking incompleto, timezone incoerenti e cambi di definizione falsano qualsiasi lettura. Infine, attenzione a confondere correlazione e causalità, perché un’associazione non dimostra che una feature causi la conversione.

Ogni analisi dovrebbe portare con sé almeno tre controlli: una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Lab / exercise

Basic level

Scrivi una scheda sintetica per l’event tracking che includa decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale viene confermato.

Intermediate level

Costruisci una tabella con tre segmenti o scenari e, per ciascuno, indica cosa cambia, una spiegazione alternativa plausibile e un controllo da effettuare prima di raccomandare un’azione.

Research-grade level

Prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione.

Recommended datasets and materials

Usa tracking plan, log eventi, GA4, CDP, warehouse e dataset sintetici di sessioni. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Typical mistake to avoid

L’errore più comune è trattare il risultato come una verità generale invece che come evidenza condizionata. Prima di agire, controlla baseline, assunzioni e costo dell’errore.

Quiz or checkpoint

1. Which concrete decision should this lesson improve?
2. Which unit of analysis makes the problem measurable?
3. Which baseline would you use to avoid a naive reading?
4. Which typical mistake could change the conclusion?
5. Which output would you deliver to a non-technical stakeholder?

Operational Summary

L’event tracking è utile quando produce una decisione più chiara, non quando aggiunge solo terminologia. Collegare problema, dati, metrica, segmentazione e azione trasforma la lezione in pratica verificabile.

[SQL]Try it yourself

Which users performed 'page_view' on the page '/prodotti/elettronica' but have NEVER made a 'purchase'? Use a subquery or LEFT JOIN to find them.

RunCtrl+Enter to runHintSolution