Event tracking: implementazione pratica

In questa lezione lavoriamo con modelli tabellari: ogni evento che implementi diventa una riga in una tabella, e la sua qualità si gioca tutta a monte. L’evento signup_completed sembra semplice. Poi qualcuno chiede se include email verificate, account invitati o utenti creati da admin. L’implementazione trasforma intenzioni vaghe in eventi testabili. Li rende versionati e coerenti tra frontend, backend e warehouse. È su questo confine che si gioca l’affidabilità.

Il compito dell’implementazione

L’implementazione di event tracking definisce nomi, trigger, proprietà e test di qualità così che ogni evento resti stabile tra frontend, backend e warehouse. In una frase: trasformare un’intenzione in un contratto testabile.

Il percorso di implementazione

1. Definisci nome, trigger tecnico e casi esclusi per ogni evento.

2. Fissa proprietà obbligatorie, tipi e regole di validazione.

3. Implementa invio non bloccante con retry e buffer locale.

4. Applica batching con soglie esplicite di numerosità e tempo.

5. Verifica con test automatici che duplicati ed errori restino sotto soglia.

Anatomia di un evento

Un evento si definisce con sette elementi: nome, trigger, proprietà, tipi, esempi, casi esclusi e test. Il trigger è la condizione tecnica che fa scattare l’invio. Il tracking è professionale quando un cambio di prodotto non altera in silenzio il significato della metrica.

{
  "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"
  }
}

Usa user_id con utente autenticato e anonymous_id altrimenti. Così unisci il percorso prima e dopo il login. Il timestamp indica quando l’evento è successo, non quando è stato processato. Il context tiene i metadati automatici separati dalle proprietà di business.

Verdetto: contratto con trigger ed esclusioni batte nome evento senza definizione.

Errori e batching

Il tracking non deve mai bloccare l’esperienza utente. Il pattern base è fire-and-forget con invio in background senza attesa. Sul fallimento scatta il retry con backoff a intervalli crescenti. Un buffer in localStorage salva gli eventi per invii successivi. Il codice di tracking non lancia mai eccezioni verso l’app. Inviare un evento alla volta è inefficiente. Raggruppare 10-20 eventi per batch o spedire ogni 5-10 secondi riduce le richieste HTTP del 90 per cento senza perdita percepita di freschezza.

Verdetto: invio in background con buffer e batch batte chiamate singole bloccanti.

Disciplina delle metriche

Costruisci le decisioni su segnali osservabili. Conta completamento, abbandono precoce, ritorno settimanale ed efficacia delle raccomandazioni. Non misurare solo il click immediato. Osserva anche i segnali di qualità come visione effettiva e ritorno. Così eviti metriche decorative, positive nel breve, che erodono valore nel lungo. Il tracking resta collegato a un outcome concreto. Altrimenti l’analisi non aiuta a scegliere tra azioni alternative.

Verdetto: outcome con segnali di qualità batte click immediato senza ritorno.

Errori tipici

Tre controlli precedono ogni lettura. Primo: non aggregare troppo presto, perché la media nasconde segmenti opposti. Secondo: verifica duplicati, tracking incompleto, timezone incoerenti e cambi di definizione. Terzo: non confondere correlazione con causalità. Ogni analisi porta definizione esplicita, confronto per segmento e verifica contro periodo precedente o gruppo di controllo.

Verdetto: test di tracking più deduplicazione più definizione unica battono funnel che cambia ogni settimana.

Il caso che mostra il lato oscuro del client-side

Nel settembre 2018 British Airways scopre che un codice maligno di tipo Magecart iniettato nelle pagine di pagamento ha intercettato dati dei passeggeri durante il checkout. Nel luglio 2019 l’autorità britannica ICO annuncia l’intenzione di multare la compagnia per 183 milioni di sterline. Nell’ottobre 2020 la sanzione definitiva è fissata a 20 milioni di sterline. Il caso mostra il lato oscuro dell’implementazione client-side: ogni script di tracking o di pagamento nel browser è superficie di attacco e va inventariato, versionato e monitorato come il resto della pipeline.

[SQL]Prova tu

Quali utenti hanno fatto 'page_view' sulla pagina '/prodotti/elettronica' ma NON hanno mai fatto 'purchase'? Usa una subquery o LEFT JOIN per trovarli.

EseguiCtrl+Enter per eseguireSuggerimentoSoluzione

Controlla di aver capito

1. Cosa deve fissare il contratto di un evento prima dell’implementazione?

2. Come eviti che il tracking blocchi l’esperienza utente in caso di errore?

3. Quali soglie usi per il batching senza perdere freschezza?

4. Come distingui duplicati da eventi reali dopo un retry?