La maggior parte dei progetti di analytics nasce al contrario: si installa lo strumento, si attivano tutte le opzioni disponibili e solo dopo qualche mese ci si chiede cosa significhino i numeri. Un piano di misurazione rovescia l'ordine. Prima si decide cosa si vuole sapere, poi si stabilisce cosa raccogliere. È un documento breve, spesso una tabella, ma evita mesi di dati inutili.
La struttura in cinque livelli
Un piano di misurazione efficace scende da ciò che interessa all'organizzazione fino al dettaglio tecnico:
- Obiettivo di business: perché il sito esiste. Esempio: ottenere richieste di preventivo.
- Domande: cosa serve sapere per capire se l'obiettivo è raggiunto e come migliorarlo.
- Metriche e KPI: i numeri che rispondono alle domande.
- Eventi e dimensioni: le azioni da registrare e le informazioni che le accompagnano.
- Implementazione e responsabilità: dove e come si registra ciascun evento, chi lo mantiene.
Ogni riga del livello 4 deve poter risalire a una riga del livello 1. Se un evento non risponde a nessuna domanda, non va raccolto.
Un esempio concreto
Immaginiamo il sito di uno studio tecnico che vive di richieste di consulenza.
| Domanda | Metrica | Evento | Dimensioni |
|---|---|---|---|
| Quante persone chiedono un preventivo? | Richieste inviate al mese | form_inviato |
tipo di servizio |
| Dove si bloccano gli altri? | Tasso di abbandono del modulo | form_iniziato, form_errore |
campo con errore |
| Quali contenuti portano alle richieste? | Richieste per pagina di ingresso | form_inviato |
pagina di ingresso |
| Il telefono è usato come canale? | Clic sul numero | click_telefono |
pagina |
| Quali servizi interessano? | Visite alle pagine servizio | pagina vista | categoria pagina |
Con cinque eventi, alcuni dei quali già registrati di default, lo studio ha tutto ciò che serve per decidere dove investire.
Come scrivere le domande
Le domande buone hanno tre caratteristiche:
- portano a una decisione: se la risposta è A farò una cosa, se è B ne farò un'altra;
- sono specifiche: «gli utenti apprezzano il sito?» non è misurabile, «quante persone che arrivano sulla pagina prezzi passano al modulo?» sì;
- hanno una cadenza: vanno riguardate ogni settimana, ogni mese o a ogni campagna.
Un esercizio utile è scrivere, accanto a ogni domanda, l'azione che si intraprenderebbe in base alla risposta. Se non viene in mente nessuna azione, la domanda è curiosità, non misurazione.
Dimensioni e contesto
Un evento senza contesto dice poco. «Modulo inviato» diventa utile quando sai da quale pagina, per quale servizio, da quale dispositivo. Le dimensioni vanno scelte con lo stesso criterio delle metriche: servono a rispondere a domande precise.
Attenzione però a non inserire dati personali nelle dimensioni. Il nome dell'azienda che chiede il preventivo, l'email o il numero di telefono non devono finire nello strumento di analytics: appartengono al gestionale dei contatti, non alle statistiche.
Documentazione e manutenzione
Il piano non è un documento da archiviare. Va tenuto aggiornato insieme al sito:
- quando si aggiunge una pagina o un modulo, si verifica se servono nuovi eventi;
- quando si rimuove una funzione, si eliminano gli eventi collegati;
- ogni evento ha un responsabile, cioè chi sa dove è implementato e chi se ne accorge se smette di funzionare;
- si annota la data di ogni modifica, perché un salto nei grafici spesso coincide con un cambio di tracciamento.
Nel mio lavoro tengo il piano nello stesso repository del codice del sito, in un file di testo semplice. In questo modo chi modifica un modulo vede subito quali eventi dipendono da quel modulo.
Errori frequenti
- Tracciare tutto «per sicurezza»: aumenta il rumore, il peso degli script e i dati da proteggere.
- Partire dagli strumenti: le funzioni disponibili non sono obiettivi.
- Dimenticare i casi negativi: oltre all'invio del modulo, serve sapere quando fallisce.
- Nomi incoerenti:
invio_form,formInviatoeform-submitper la stessa azione rendono i report illeggibili. - Nessuna revisione: un piano scritto due anni fa descrive un sito che non esiste più.
In sintesi
- Il piano di misurazione parte dagli obiettivi e arriva agli eventi, mai al contrario.
- Ogni evento deve rispondere a una domanda che porta a una decisione.
- Le dimensioni danno contesto, ma non devono contenere dati personali.
- Il piano va mantenuto insieme al sito, con un responsabile per ogni evento.
- Pochi eventi ben definiti valgono più di cento eventi raccolti senza scopo.
