Cosa va in un tracking plan e cosa non riesce a intercettare

Che cos'è un tracking plan?

Nella product analytics, un tracking plan è la specifica scritta che elenca ogni evento inviato da un prodotto, il momento esatto in cui scatta, le proprietà che porta con i loro tipi, la sorgente che lo emette e la persona che ne è responsabile. Tutto va concordato prima che qualcuno scriva il codice di instrumentazione. La documentazione di Segment Protocols lo definisce così: "una specifica dei dati che descrive gli eventi e le proprietà che intendi raccogliere nelle tue Segment Sources." La versione di Amplitude aggiunge il motivo di ogni riga: "Un tracking plan definisce ogni evento e ogni proprietà che raccogli, perché la raccogli e quale sorgente la emette."

Il piano è il contratto e il codice di tracciamento è l'implementazione. Quando i due non coincidono, qualcuno deve decidere quale dei due sbaglia, e senza un piano non c'è niente con cui confrontare il codice. L'event tracking è la pratica di registrare ciò che gli utenti hanno fatto. Il tracking plan è il documento che stabilisce che cosa significa "fatto" per ogni evento.

Quali colonne servono in un tracking plan?

Un tracking plan ha bisogno di una riga per evento e di colonne sufficienti perché uno sviluppatore possa implementare l'evento senza fare domande. Le colonne qui sotto sono quelle che evitano le discussioni vere, più avanti. L'editor del Tracking Plan di Segment ne usa un sottoinsieme, chiamato Name, Description, Status, Data Type e Permitted Values.

L'elenco dei tipi di dati di Segment è un buon punto di partenza per la colonna Tipo: "any, array, object, boolean, integer, number, string, null, Date time", con le date che "devono essere in formato ISO-8601." La sua colonna Permitted Values accetta "semplici espressioni regolari per convalidare i valori delle proprietà", e questo funziona solo con le proprietà di tipo stringa.

Come si presenta una riga compilata di un tracking plan?

Una riga compilata si legge come una piccola specifica. Ecco un evento del flusso di registrazione di un SaaS, scritto come lo conserverebbe un piano salvato in un repository:

event: signup_completed
trigger: >
  Fires once, from the server, after the account row is written.
  Not on button click. Not on page load of /welcome.
answers: Signup-to-activation funnel, weekly signups by channel
source: backend
owner: growth-eng
status: live
properties:
  plan:
    type: string
    required: true
    allowed: [team, pro]
  signup_method:
    type: string
    required: true
    allowed: [email, google, github]
  invited:
    type: boolean
    required: false

Il testo del trigger è la parte che la maggior parte dei piani sbaglia. "Scatta alla registrazione" non dice se un invio fallito del modulo conta, se un nuovo tentativo scatta due volte, né se l'evento arriva dal browser o dal server. Scrivere "non al clic del pulsante" esclude il duplicato più comune, quello in cui il clic fa scattare l'evento e poi il server rifiuta il modulo. Lo stile dei nomi è una scelta a parte, e scegliere una convenzione per i nomi degli eventi prima della prima riga ti evita di rinominare dopo.

Cosa può convalidare uno strumento di tracking plan e cosa no?

Uno strumento di tracking plan convalida gli eventi che arrivano rispetto a quelli descritti dal piano, ma non può dirti nulla sugli eventi che non arrivano mai. Questa seconda metà è la cosa più utile da sapere su questi strumenti, e lo dicono gli stessi fornitori.

La documentazione di Segment descrive il lato del controllo: "Le violazioni vengono generate quando un evento non corrisponde all'evento specificato nel Tracking Plan." Poi, nella descrizione della colonna Status: "Non puoi rendere obbligatoria una chiamata Track perché Segment non è in grado di verificare quando una chiamata Track dovrebbe scattare." Segment può controllare che un evento abbia le sue proprietà obbligatorie, ma non ha modo di sapere che l'evento avrebbe dovuto scattare e non l'ha fatto.

Amplitude gestisce la direzione opposta. Gli eventi che arrivano senza essere nel piano compaiono come "Unexpected", e Amplitude dice: "Puoi aggiungerli al tuo piano, oppure eliminarli per interrompere l'acquisizione e rimuoverli dal tuo catalogo dati." Per la direzione mancante, Amplitude pubblica una guida a parte intitolata "Planned events that never arrived: confirm the problem", che ti dice di "confrontare il tuo tracking plan con i dati osservati e con i tuoi registri di pianificazione per trovare gli eventi pianificati che non sono mai arrivati in Amplitude." La stessa pagina dice che "Data Assistant non individua queste voci" e che Observe, la vista che mostra se un evento è arrivato, copre "l'intervallo di tempo selezionato, fino a 14 giorni."

Quindi una dashboard di convalida tutta verde significa che ogni evento arrivato corrispondeva alla sua specifica. Non significa che ogni evento della specifica stia arrivando. La soluzione pratica è un controllo a ogni rilascio. Elenca gli eventi segnati come attivi nel piano, interroga i dati recenti per ogni nome e segnala quelli con conteggio zero. La guida di Amplitude aggiunge la giusta cautela: un evento senza attività "potrebbe appartenere a un flusso raro, a una funzione disattivata o a un rilascio futuro", quindi chiedi al responsabile prima di eliminare la riga.

Quali limiti delle destinazioni vanno inseriti nel piano?

Nel piano vanno i limiti di ogni strumento in cui confluiscono gli eventi, perché una riga che supera un limite fallisce in silenzio nella destinazione. Google Analytics lo dice chiaramente: "Google Analytics non registra eventi, parametri degli eventi e proprietà utente che superano i seguenti limiti."

I due strumenti falliscono in modo diverso quando un piano li supera. GA4 scarta l'elemento: il suo esempio è che "Analytics non elabora la 26ª proprietà utente e nemmeno un nome evento con più di 40 caratteri." Amplitude continua a ricevere i dati ma "smette di indicizzare i nuovi valori", quindi i dati esistono negli export ma non si possono interrogare nei grafici. Amplitude aggiunge che gli eventi oltre il limite dei tipi di evento "contano comunque nel volume mensile di eventi", il che significa che un bug di strumentazione fuori controllo ti costa denaro per dati che nessuno può rappresentare in un grafico.

Segment ha un limite proprio per i piani gestiti come file: un CSV del Tracking Plan caricato "deve pesare meno di 15 mb" e deve "avere meno di 100.000 righe e 2.000 regole."

Quanti eventi deve contenere la prima versione?

La prima versione deve contenere i pochi eventi che rispondono alle domande che il team si pone già ogni settimana, e nient'altro. La guida all'implementazione di Amplitude dice di "resistere alla tentazione di tracciare tutto fin dall'inizio" e consiglia di "partire da due eventi importanti del tuo prodotto per ottenere i primi spunti." Il suo playbook sulla tassonomia ordina il lavoro così: prima gli obiettivi di business, poi le metriche chiave, poi gli eventi e le proprietà che servono a quelle metriche.

È l'ordine giusto. Parti dalla metrica della revisione settimanale, come la north star metric, scrivi la domanda che solleva e aggiungi solo gli eventi necessari per rispondere. Un flusso di registrazione che richiede una analisi del funnel ha bisogno di un evento per ogni passaggio e di una proprietà che segmenti il risultato, non di quaranta eventi per ogni clic sulla pagina. Se usi Flowsery, il suo tracciamento degli obiettivi "registra iscrizioni, acquisti, download ed eventi personalizzati in un unico posto", e il piano è il luogo in cui decidi quali di questi obiettivi vale la pena definire.

Come mantieni aggiornato un tracking plan?

Un tracking plan resta aggiornato quando una modifica al codice di tracciamento non può essere integrata senza una modifica corrispondente al piano. Tutto il resto è un promemoria che le persone ignorano.

La colonna Stato fa gran parte del lavoro. Segnare un evento come deprecato invece di cancellare la sua riga impedisce a un nuovo sviluppatore di reintrodurre il vecchio nome sei mesi dopo. Entrambi gli strumenti conservano la cronologia. Segment dice che le modifiche al piano fatte tramite caricamento sono "riportate nell'Audit Trail e nel changelog del Tracking Plan", e la sua esportazione CSV chiama ogni file workspaceSlug-trackingPlanName--yyyy-mm-dd--hh-mm-utc. Un piano che vive nel repository accanto al codice ottiene la cronologia dal controllo di versione, senza costi aggiuntivi.

Domande frequenti

Qual è la differenza tra un tracking plan e una convenzione per i nomi degli eventi?

Una convenzione per i nomi degli eventi è una regola all'interno di un tracking plan: come si formano i nomi, per esempio object_action in snake case. Il tracking plan è l'elenco completo degli eventi che seguono quella regola, con trigger, proprietà, tipi, sorgente e responsabile di ciascun evento.

Chi dovrebbe essere responsabile del tracking plan?

Una persona precisa dovrebbe approvare le modifiche, scelta tra il team che legge di più i dati, mentre gli sviluppatori propongono le righe. Un piano che chiunque può modificare senza revisione finisce nello stesso stato di un piano che non esiste.

Un tracking plan dovrebbe stare in un foglio di calcolo o in uno strumento?

Un foglio di calcolo va bene per una prima versione con qualche decina di eventi. Uno strumento come Segment Protocols o Amplitude Data aggiunge la validazione degli eventi in ingresso rispetto al piano, e un file nel repository del codice aggiunge revisione e cronologia tramite pull request.

Gli eventi lato server vanno nello stesso tracking plan?

Sì. Tieni un unico piano con una colonna Sorgente, perché lo stesso nome evento inviato dal browser e dal server viene contato due volte, a meno che il piano non indichi quale dei due è quello di riferimento. La definizione di tracking plan di Amplitude include "quale sorgente lo emette".

Come trovi gli eventi pianificati che non sono mai partiti?

Confronta gli eventi segnati come attivi nel piano con i nomi evento presenti nei dati recenti e segnala quelli con conteggio zero. Segment dice di non poter imporre una chiamata Track, e Amplitude dice che il suo Data Assistant non individua queste voci, quindi nessuna dashboard di validazione solleva il problema da sola.

L'autocapture elimina la necessità di un tracking plan?

No. L'autocapture registra clic e visualizzazioni di pagina, ma non registra cosa significava un clic, per esempio quale piano ha scelto un utente o se il server ha accettato il modulo. Gli eventi che alimentano le metriche di ricavo e attivazione hanno comunque bisogno di un trigger e di un elenco di proprietà scritti.

Cosa dovrebbe dire la colonna del trigger?

Dovrebbe indicare in parole semplici l'unico momento in cui l'evento parte, incluso ciò che non conta. "Parte all'iscrizione" lascia aperto se contino un invio fallito o un nuovo tentativo, e se a inviarlo siano il browser o il server. "Parte una sola volta, dal server, dopo che la riga dell'account è stata scritta. Non al clic sul pulsante" non lascia nulla da indovinare.

Con quanti eventi dovrebbe iniziare un tracking plan?

Inizia con i pochi eventi che rispondono alle domande che il team si pone ogni settimana. La guida all'implementazione di Amplitude dice di "resistere alla tentazione di tracciare tutto fin dall'inizio" e suggerisce di partire da due eventi importanti. Aggiungine altri solo quando una metrica li richiede.

Cosa succede quando un piano supera i limiti di GA4 o Amplitude?

GA4 scarta l'elemento, quindi una 26ª proprietà utente o un nome evento oltre i 40 caratteri non viene mai elaborato. Amplitude continua a ricevere i dati ma smette di indicizzare i nuovi valori, quindi i dati compaiono negli export ma non si possono interrogare nei grafici. Gli eventi oltre il limite dei tipi di evento contano comunque nel volume mensile di eventi.

Perché segnare un evento come deprecato invece di cancellare la riga?

Una riga deprecata impedisce a un nuovo sviluppatore di reintrodurre il vecchio nome mesi dopo. Mantiene inoltre la cronologia nel piano. Prima di cancellare la riga di un evento senza attività, chiedi al responsabile, perché potrebbe "appartenere a un flusso di lavoro raro, a una funzione disattivata o a una release futura."