Il piano di tracciamento degli eventi per startup

Cos’è un piano di tracciamento

Un piano di tracciamento è un unico documento che elenca ogni evento registrato dal tuo prodotto, le proprietà associate a ciascuno, il momento esatto in cui scatta e la persona che ne risponde. È il contratto tra il codice che emette i dati e le dashboard che li leggono. Trattalo come una specifica viva che cambia con il prodotto, non come un documento da scrivere una volta e dimenticare. Per la versione in una riga, leggi piano di tracciamento; questa guida spiega come costruirne uno.

Perché un piano batte il tracciamento improvvisato

Senza un piano, il tracciamento si accumula. Uno sviluppatore invia signup, un altro Sign Up, un terzo user_registered: tre nomi per un’azione sola, e ogni funnel che passa dalla registrazione si divide o si rompe senza che nessuno se ne accorga. Questa è la deriva, ed è il motivo principale per cui si smette di fidarsi dell’analisi. Un piano fissa il vocabolario prima che il codice vada in produzione, così i numeri che estrai tra sei mesi significano ancora ciò che pensi. Eventi puliti e coerenti sono anche ciò su cui si regge una roadmap di sperimentazione: non puoi misurare un test su una metrica che registri in tre modi diversi.

Chiama gli eventi object_action e non derogare

La convenzione che la maggior parte degli strumenti di analisi consiglia è object_action: l’oggetto, poi ciò che gli è successo, come subscription_started, invite_sent, checkout_completed. Segment, Amplitude e PostHog descrivono ciascuno una variante (Segment usa “Object Action”, PostHog lo snake_case minuscolo, Amplitude un sostantivo più un verbo al passato). Maiuscole e minuscole contano molto meno che scegliere una convenzione e non infrangerla mai. Due regole portano quasi tutto il valore: mantieni coerente il tempo verbale e non costruire mai nomi di eventi in modo dinamico. Un evento chiamato plan_${name}_upgraded crea un evento per ogni cliente e diventa impossibile da interrogare.

Gli 8–10 eventi che descrivono il tuo funnel

Resisti alla tentazione di tracciare tutto. Parti dai pochi eventi che seguono un utente dal primo contatto al pagamento (registrazione, attivazione e ricavi) e strumentali bene prima di aggiungere profondità. Qui sotto trovi un set di partenza per un tipico SaaS B2B; rinominali con i sostantivi del tuo prodotto. Ognuno diventa una riga del piano e, insieme, formano il tuo primo insieme di dati first-party: la materia prima di ogni funnel, coorte e curva di retention che costruirai. Dove strumentare ogni evento, nel browser o sul server, è una decisione a parte: tracciamento server-side e client-side spiega come dividerli.

Le proprietà portano i dettagli, i responsabili tengono tutto in ordine

Tieni gli eventi pochi e generici; sposta i dettagli nelle proprietà. Invece di un evento separato per ogni piano, invia subscription_started con le proprietà plan_name e amount_usd: un solo evento, descritto bene, resta interrogabile. Mantieni snello il set di proprietà di ogni evento: poche proprietà che interroghi davvero valgono più di decine che non usi mai. Poi decidi chi ne è responsabile: nella maggior parte dei piccoli team è un Growth Engineer o chiunque rilasci la strumentazione, e ogni nuovo evento dovrebbe passare da questa persona perché piano e codice non si separino mai. Infine, sappi dove arrivano gli eventi. Inviarli a uno strumento di analisi ospitato o a una CDP è rapido, ma mette i tuoi dati comportamentali sui server di qualcun altro; tenerli first-party (Postgres self-hosted, il tuo data warehouse) li lascia tuoi, ed è il compromesso centrale tra open source e SaaS negli strumenti di engagement.