Nel lavoro di crescita la raccolta dati non è un magazzino dove accumuli informazioni. È un sistema che deve guidare decisioni quando non hai certezze. Un evento tracciato non è solo una riga nel database. È una frase che racconta cosa è successo nel prodotto: chi c’era, quando, in quale contesto.
La tesi
Un evento fatto bene assomiglia a una ricevuta fiscale, chiara e con tutto al suo posto. Un evento fatto male è il post-it che ti è caduto sotto la scrivania: quando ti serve non riesci a usarlo. L’obiettivo non è accumulare strumenti o dashboard, è costruire un meccanismo che acceleri il passaggio dal segnale alla decisione e abbassi il costo dell’incertezza.
Schema operativo
Perché un evento resti chiaro e utile, gli chiedo cinque cose:
- Nome evento con verbo chiaro
- Proprietà obbligatorie
- Identità utente o account
- Contesto esperimento
- Regole di qualità e ownership
Questo è la base. La complessità arriva dopo, quando devi gestire grandi volumi, segmenti e automazioni. Se il flusso di base non è chiaro in pochi passaggi, di solito vuol dire che stai automatizzando un processo che non hai ancora capito.
Esempio pratico
Prendiamo l’onboarding. Tracciare solo “button_click” non basta. Meglio un evento come “onboarding_step_completed” con dentro lo step, il metodo, la variante, il tempo dal primo accesso e lo stato dell’utente. Così leghi ogni intervento a un apprendimento concreto: se i numeri migliorano sai cosa scalare, se peggiorano sai quale ipotesi correggere.
Metriche da monitorare
- Copertura degli eventi (event coverage)
- Percentuale di proprietà mancanti (null rate)
- Ritardo nell’ingestione dei dati
- Eventi deprecati ancora in uso
Queste metriche devono stare in una scorecard breve, letta a cadenza regolare, e ognuna deve portare a una decisione. Se una metrica non sposta nessuna scelta, è solo un dato di conforto.
Errore tipico da evitare
Dare ai nomi degli eventi la forma della UI. Il giorno che cambi un bottone, il significato analitico se ne va. Capita spesso perché sembra produttivo: genera attività e grafici, ma non migliora la qualità del ciclo di apprendimento.
Checklist per il team
- Quale decisione vogliamo rendere più chiara?
- Quale evento o dato rende osservabile il comportamento?
- Quale rischio non vogliamo peggiorare ottimizzando?
- Chi può davvero cambiare il processo dopo aver visto i risultati?
Se una risposta resta vaga, meglio fermarsi prima di implementare. La velocità vera è non dover rifare il lavoro per ipotesi o dati confusi.
Lettura pratica
Con l’AI ovunque, il growth superficiale diventerà più rumoroso. Generare idee e automazioni costerà quasi niente, costruire sistemi che separano il segnale dal rumore resterà raro. Il growth engineer del futuro non sarà solo un tecnico. Saprà progettare prove, limiti, feedback e una memoria operativa. Non insegue l’AI, se la mette dentro processi che controlla.
Cosa fare adesso
Prova a leggere ogni evento come una frase: “l’utente ha completato X nel contesto Y”. Se non sta in piedi, l’evento è debole. Portare questa domanda nella prossima review sposta la conversazione dalle opinioni generiche a un sistema che può imparare.