Un evento è una decisione che hai preso, non qualcosa che è successo
Ogni prodotto emette un numero illimitato di cose che succedono: clic, scroll, passaggi del mouse, cambi di route. Un evento è il piccolo sottoinsieme a cui hai deciso di dare un nome, perché ti dice qualcosa su cui agiresti. Questa decisione, non la strumentazione, è tutto il lavoro.
La conseguenza pratica è che un piano di tracciamento è un documento di prodotto, non di sviluppo. Se non sai dire cosa faresti di diverso a seconda che un evento scatti o meno, non ha ancora bisogno di esistere.
Dai agli eventi il nome dei risultati, non delle interfacce
clicked_blue_button smette di essere vero nel momento in cui il design rilascia un redesign. report_exported sopravvive, perché nomina ciò che l'utente ha ottenuto e non ciò che ha toccato.
Scegli una convenzione e mantienila: prima l'oggetto, poi l'azione al passato, in minuscolo con i trattini bassi — invite_sent, project_created, payment_failed. La coerenza conta più della convenzione scelta, perché sono i nomi incoerenti a rendere un catalogo di eventi impossibile da consultare dopo due trimestri.
Una convenzione di denominazione da copiare
La maggior parte dei team non ha bisogno di inventare una convenzione, solo di metterla per iscritto. Questa è abbastanza breve da ricordare e abbastanza rigorosa da mantenere un catalogo consultabile:
| Regola | Sì | No |
|---|---|---|
| Prima l'oggetto, poi l'azione | invite_sent | sent_invite |
| Al passato, perché è già successo | project_created | create_project |
| Minuscolo con trattini bassi | plan_upgraded | PlanUpgraded, plan-upgraded |
| Nomina il risultato, non il controllo | report_exported | export_button_clicked |
| Le varianti vanno nelle proprietà | report_exported con format: csv | report_exported_csv |
| Nessun dato personale nei nomi o nei valori | plan: team | email: ana@acme.com |
Metti la convenzione all'inizio del piano di tracciamento e verifica i nuovi eventi rispetto a essa come verifichi il codice rispetto a una guida di stile. Un nome sbagliato si paga ogni volta che qualcuno cerca l'evento e non lo trova.
Da dieci a venti eventi, non duecento
L'errore comune è tracciare tutto con l'idea che i dati potrebbero servire in futuro. Quello che ottieni è un catalogo in cui nessuno sa orientarsi, tre eventi che significano quasi la stessa cosa e nessun accordo su quale sia quello di riferimento.
Parti dalle domande che già ti fai nelle revisioni (le persone completano la configurazione, tornano, dove rinunciano?) e strumenta solo ciò che vi risponde. Un piano di tracciamento che sta in una schermata viene mantenuto. Uno che sta in un foglio di calcolo no.
Un esempio concreto: un piano di tracciamento per un'app SaaS B2B
Ecco come appaiono dodici eventi per un tipico prodotto SaaS basato sui team. Ognuno esiste perché risponde a una domanda che qualcuno si pone già in una revisione settimanale.
| Evento | Scatta quando | Proprietà chiave | La domanda a cui risponde |
|---|---|---|---|
signup_completed | L'account esiste, non quando il modulo viene inviato | source | Quali canali portano persone che arrivano davvero alla fine? |
workspace_created | Il primo workspace viene salvato | team_size | Quanti iscritti arrivano fino alla configurazione? |
teammate_invited | Viene inviato un invito | role | L'account si sta estendendo oltre una sola persona? |
invite_accepted | La persona invitata si unisce | role | Gli inviti si trasformano in colleghi? |
integration_connected | Una connessione va a buon fine | integration | Quali integrazioni usano i team che restano? |
project_created | Un progetto viene salvato | template | L'oggetto principale viene creato? |
report_viewed | Un report finisce di essere renderizzato | report_type | Cosa tornano a guardare le persone? |
report_exported | Il file viene generato | format | L'output esce dal prodotto? |
plan_upgraded | La fatturazione conferma il cambio | from_plan, to_plan | Cosa succede subito prima che le persone paghino di più? |
payment_failed | Il provider di fatturazione segnala un errore | reason | Quanto abbandono è involontario? |
subscription_cancelled | L'annullamento diventa effettivo | reason | Perché i team se ne vanno? |
feedback_submitted | Il modulo di feedback viene inviato | category | Cosa chiedono gli utenti, con le loro parole? |
Vale la pena notare due cose. La maggior parte di questi eventi scatta su un risultato, non su un clic: un invito può essere cliccato e fallire comunque. E gli eventi di fatturazione non avvengono affatto nel browser. Arrivano dai webhook del tuo provider di fatturazione, quindi le analisi solo lato browser non li vedranno mai. Va bene, purché nessuno consideri un clic su “Upgrade” come un ricavo.
L'attivazione di solito è una combinazione di questi eventi piuttosto che uno solo, per esempio un workspace creato e un collega invitato nella prima settimana. Scegli questa definizione di proposito; i benchmark dei funnel di attivazione spiegano come.
Le proprietà portano il dettaglio; gli eventi portano il verbo
Resisti alla tentazione di creare un evento separato per ogni variante. report_exported_csv, report_exported_pdf e report_exported_xlsx dovrebbero essere un unico evento, report_exported, con una proprietà format. La regola pratica: se mai vorresti vedere i numeri sommati, è un unico evento con una proprietà.
Mantieni i valori delle proprietà stabili e con pochi valori possibili. Una proprietà che contiene un URL grezzo o una stringa di testo libero è una colonna che non puoi raggruppare, e quindi è decorazione e non dati.
Errori nel tracciamento degli eventi che rompono i report senza che te ne accorga
- Far scattare l'evento sul clic invece che sul risultato. Un clic su “Esporta” non è un'esportazione. Se la richiesta fallisce, l'evento ha già mentito. Invia gli eventi di risultato quando l'azione è andata a buon fine.
- Eventi doppi nelle single-page app. Un componente che viene renderizzato di nuovo o una route che viene montata due volte può inviare lo stesso evento due volte. Controlla alcune sessioni a mano prima di fidarti di un conteggio.
- Dati personali nelle proprietà. Email, nomi e URL con token nella query string finiscono in ogni report e in ogni esportazione. Invia invece un ID o una categoria.
- Tracciare prima del consenso. Dove si applica il GDPR, le analisi non dovrebbero partire finché il visitatore non acconsente. È una caratteristica della tua configurazione, non di ogni evento, quindi risolvilo una volta sola, con un gestore del consenso ai cookie che trattenga il tracciamento fino ad allora.
- Cambiare il significato di un evento senza rinominarlo. Se
project_createdinizia a contare anche i progetti duplicati, ogni grafico prima e dopo il cambiamento non coincide e nessuno capisce perché. Un nuovo significato richiede un nuovo nome, o una proprietà che distingua i due casi. - Eventi senza un responsabile. Ogni evento del piano ha bisogno di una persona che si accorga quando smette di scattare. Gli eventi senza responsabile si degradano per primi e sono quelli di cui ci si fida più a lungo.
Acquisizione automatica ed eventi espliciti rispondono a domande diverse
L'acquisizione automatica registra le interazioni con l'interfaccia senza chiederti di pianificare, il che è davvero utile all'inizio: significa che i dati per una domanda a cui non avevi ancora pensato sono già lì, ed elimina il deploy dal ciclo. Quello che non può fare è conoscere il tuo dominio. Niente in un flusso di clic sa che un abbonamento è stato aggiornato.
La soluzione praticabile è usare entrambi: l'acquisizione automatica per esplorare e per le domande che non hai ancora fatto, e un breve elenco di eventi di dominio espliciti e ben nominati per i numeri su cui fai report e fissi obiettivi.
Definire gli eventi a posteriori
L'acquisizione automatica cambia la domanda da “ci siamo ricordati di strumentare questo?” a “riusciamo a trovarlo in ciò che è stato acquisito?”. PulsePanda registra ogni clic con id, classi, testo visibile, tag e posizione dell'elemento nella pagina, quindi un evento può essere definito in seguito a partire da questi dati, e la definizione si applica anche ai clic acquisiti prima che esistesse. Una domanda posta giovedì può trovare risposta con i dati di lunedì.
Ciò che lo rende affidabile è un aggancio stabile nel markup. Le classi cambiano a ogni redesign e il testo visibile cambia a ogni modifica dei testi e a ogni traduzione. Un id sui pochi controlli che contano cambia solo quando qualcuno decide che deve cambiare:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/it/billing">Upgrade</a>Un evento definito come clic su #export-report sopravvive a un redesign, e un clic sull'icona o sull'etichetta all'interno del pulsante conta comunque, perché il percorso registrato risale fino all'elemento più vicino con un id.
Un evento definito resta comunque un clic, con il limite descritto sopra: ti dice che qualcuno ci ha provato, non che ha funzionato. Per i risultati, il segnale più onesto è spesso la pagina a cui porta il successo. Un passaggio del funnel “ha raggiunto /onboarding” dopo “ha raggiunto /signup” conta le registrazioni completate senza alcun evento.
Come verificare un evento prima di fidarti
- Attivalo tu stesso e trova la tua sessione. L'evento dovrebbe comparire una sola volta, con tutte le proprietà compilate.
- Confronta il conteggio con una fonte attendibile. Se il database dice che la settimana scorsa sono stati creati 140 progetti e le analisi dicono 95, trova la differenza prima che qualcuno ci costruisca un grafico. Ad blocker, consenso e richieste fallite rendono tutti i conteggi del browser più bassi di quelli del server. La differenza dovrebbe essere costante, non una sorpresa.
- Guarda una registrazione della sessione in cui è scattato. Un numero ti dice che è successo; una registrazione ti dice che è successo quando pensi tu.
- Inseriscilo in un funnel. Un evento che compare senza il passaggio che deve precederlo sta scattando dal punto sbagliato.
Da dove iniziare questa settimana
Scrivi i cinque momenti più importanti del tuo prodotto, dai loro un nome con la convenzione qui sopra e strumenta solo quelli. Poi, una settimana dopo, verifica che ciascuno scatti quando ti aspetti e che le sue proprietà siano compilate — un evento che scatta su un percorso del codice che nessuno usa è peggio di nessun evento, perché verrà creduto.
Se vuoi vedere come si comportano gli eventi che invii già prima di aggiungerne altri, il tracciamento degli eventi in PulsePanda mostra ogni evento, il suo volume e le sue proprietà in un unico posto, e porta gli stessi dati direttamente nei funnel e nei percorsi.