Tracciare ogni clic sembra un modo per non perdere informazioni. Nella pratica, però, spesso produce schemi difficili da mantenere, report rumorosi e domande a cui nessuno sa rispondere con sicurezza. Il problema non è avere molti dati, ma raccogliere azioni senza sapere quale decisione aiuteranno a prendere.
Per decidere quali eventi misurare nell’analitica di prodotto, parti da una decisione reale: che cosa faresti diversamente se i dati mostrassero un risultato anziché un altro? Poi definisci quale comportamento permetterebbe di osservarlo, quale contesto ti serve e come verificherai che la misurazione funzioni. Questo ordine aiuta a creare una strumentazione più essenziale e utile.
Parti dalla decisione, non dall’evento
Prima di aggiungere un evento, chiarisci quale decisione di prodotto o aziendale è ancora da prendere. Potrebbe trattarsi di stabilire la priorità di un miglioramento, indagare un abbandono, modificare un flusso o verificare se una nuova esperienza viene utilizzata. Se nessuno dei possibili risultati cambierebbe il passo successivo, probabilmente quella misurazione non è prioritaria.
Formula la domanda in modo che permetta di agire. “La nuova funzionalità funziona?” è troppo generica: può riferirsi alla scoperta, all’utilizzo, alla comprensione o all’impatto. Una formulazione più utile potrebbe essere: “Quale percentuale delle persone che scoprono la funzionalità completa l’azione principale durante la prima settimana?”. La domanda indica già quale popolazione, comportamento e periodo occorre chiarire.
È utile annotare anche le possibili risposte e le relative conseguenze. Se l’utilizzo è basso, si potrebbe indagare se la funzionalità è visibile; se molte persone la provano, ma poche la completano, si potrebbe rivedere il flusso. L’analitica non decide al posto del team, ma deve distinguere scenari che portano a decisioni diverse.
Trasforma le domande in comportamenti osservabili
Una domanda non si misura direttamente. Bisogna tradurla in azioni che il prodotto possa registrare e che rappresentino in modo ragionevole il comportamento di interesse. Per rispondere, per esempio, a una domanda sul completamento di un’attività, potrebbe essere necessario registrare l’inizio e la conclusione, non ogni movimento del cursore o clic intermedio.
Definisci con precisione che cosa conta come ciascuna azione. “Registrazione completata” potrebbe indicare che è stato inviato un modulo, che il server ha accettato la richiesta o che l’account è diventato disponibile. Questi momenti non sono equivalenti. Scegli quello che rappresenta il risultato che vuoi studiare e specifica quando si verifica, includendo i casi di errore o di nuovo tentativo.
Un evento tende a essere utile quando:
- Rappresenta un’azione o un cambiamento di stato significativo per il prodotto.
- Permette di rispondere a una domanda prioritaria, invece di limitarsi a descrivere l’attività.
- Ha un momento di attivazione definito e può essere verificato con un test.
- Il valore che offre e il suo utilizzo giustificano il costo di implementazione e manutenzione.
Evita nomi ambigui come “azione”, “interazione” o “successo” se non esiste una definizione condivisa. Un nome chiaro e stabile, come “invito inviato”, aiuta prodotto, analisi e ingegneria a interpretare il dato allo stesso modo.
Distingui eventi, proprietà e contesto
L’evento descrive che cosa è successo. Le proprietà aggiungono dettagli sull’accaduto: per esempio, il tipo di elemento selezionato o l’esito di un’operazione, purché questi valori aiutino a interpretare la domanda. Il contesto dell’utente o della sessione permette di analizzare chi ha compiuto l’azione o in quali circostanze, ma non dovrebbe essere aggiunto automaticamente.
Per ogni proprietà, chiediti quale confronto rende possibile e se quel confronto cambierebbe una decisione. Una proprietà con valori inseriti liberamente, incoerenti o quasi sempre vuoti può aggiungere complessità senza aiutare a individuare le cause. Quando opportuno, definisci tipi e valori ammessi; chiarisci anche se un dato può mancare e che cosa significa la sua assenza.
Raccogli solo il contesto necessario. I dati personali o sensibili richiedono particolare attenzione: verifica la finalità, le autorizzazioni, le norme applicabili e chi può accedervi. Non includere informazioni identificative nei nomi degli eventi o nelle proprietà per comodità. Se basta una categoria o uno stato, evita di raccogliere il valore originale.
Una breve scheda per ogni evento può riportare il nome, lo scopo, la condizione di attivazione, le proprietà, le eccezioni, il responsabile e le domande a cui intende rispondere. Non serve trasformare ogni evento in un documento lungo; è importante, invece, che un’altra persona possa interpretarne il significato senza dipendere da chi lo ha implementato.
Dai la priorità in base al valore decisionale e al costo di manutenzione
Il costo di un evento non si esaurisce quando viene pubblicato. Qualcuno deve mantenerne la definizione quando cambia l’interfaccia, verificare che continui a essere raccolto e spiegarne i limiti nelle analisi successive. Per questo è opportuno ordinare i candidati per priorità, invece di strumentarli tutti insieme.
- Valuta la decisione: stabilisci quanto è importante la domanda e quale azione diventerebbe possibile in base alla risposta.
- Verifica l’osservabilità: accertati che il comportamento possa essere rilevato in modo affidabile e nel punto corretto del sistema.
- Stima il costo: considera implementazione, verifica, autorizzazioni, volume dei dati e manutenzione futura.
- Parti dal minimo sufficiente: registra gli eventi e le proprietà necessari per distinguere gli scenari rilevanti.
Se una domanda ha un alto valore, ma non è possibile rispondervi con la strumentazione disponibile, documenta il limite e decidi se conviene migliorarla. Se ha scarso valore o non è collegata ad alcuna azione, rimandala. Questa priorità evita che “potrebbe servire un giorno” diventi il motivo abituale per raccogliere altri dati.
Verifica i percorsi completi e cerca i segnali di rumore
Prima di usare i dati per prendere una decisione, prova i percorsi importanti in condizioni rappresentative. Controlla che l’evento compaia una sola volta quando previsto, che si attivi dopo il risultato atteso e che le proprietà corrispondano a quanto è avvenuto. Includi i casi alternativi: errori, annullamenti, nuovi tentativi, navigazione all’indietro e cambiamenti di stato.
Un evento che manca su determinati dispositivi o percorsi produce conclusioni distorte. Se viene attivato due volte, può gonfiare le conversioni. È un segnale d’allarme anche quando team diversi usano lo stesso nome per indicare cose differenti o quando una proprietà cambia significato senza che la sua definizione venga aggiornata.
Per individuare questi problemi, esamina campioni di eventi insieme a percorsi di test reali e confronta i dati con il comportamento previsto. Quando emergono discrepanze, identifica prima dove nasce il problema: nella definizione, nell’implementazione, nella trasmissione o nell’interpretazione. Non correggere una cifra in un report senza risolvere la causa: lo stesso errore potrebbe ripresentarsi in altre analisi.
Rivedi lo schema quando cambia il prodotto
La strumentazione non è un progetto che si completa una volta per tutte. Un cambiamento del flusso, delle autorizzazioni o del modello aziendale può modificare il significato di un evento. Prima di intervenire, verifica quali analisi dipendono da quell’evento e se mantenere lo stesso nome ne conserverebbe il significato. Se cambia il comportamento rappresentato, documenta la transizione ed evita di mescolare periodi non confrontabili senza segnalarlo.
Pianifica revisioni legate ai cambiamenti rilevanti e alle domande sul prodotto. Rimuovi gli eventi che non vengono più usati, aggiorna le definizioni obsolete e assegna un responsabile agli eventi che supportano decisioni importanti. L’obiettivo non è avere lo schema più piccolo a ogni costo, ma mantenere una misurazione comprensibile, proporzionata e affidabile.
In sintesi, una buona strumentazione parte da una decisione, registra comportamenti osservabili e aggiunge solo il contesto necessario a interpretarli. Definisci i casi limite, prova i percorsi e rivedi lo schema man mano che il prodotto evolve. In questo modo, ogni evento ha una ragione per esistere e i dati diventano più utili per agire.