Un tracking plan GA4 completo, per me, voleva dire ore passate a cliccare, fare screenshot e scrivere. Di recente ne ho prodotto uno con 47 eventi, pronto per gli sviluppatori, e mentre l'AI faceva l'esplorazione in pochi minuti io lavoravo ad altro.
La differenza non è stata eliminare degli step. Ho diviso il lavoro: un agente AI ha esplorato il sito e scritto la prima bozza, io ho dedicato il mio tempo dove serve davvero un ingegnere, cioè alla validazione e ai casi limite che l'agente non poteva vedere.
In questo articolo ripercorro il processo su un progetto reale (anonimizzato). Vedrai cosa l'AI fa sorprendentemente bene, dove sbaglia in silenzio e cosa serve in un tracking plan perché uno sviluppatore possa implementarlo senza ambiguità.
Perché i tracking plan richiedono tempo, e perché gli sviluppatori odiano quelli fatti male
Il tracking plan è il documento che serve a comunicare tra chi ha bisogno dei dati e chi scrive il codice. Quando è vago, lo sviluppatore tira a indovinare, e le ipotesi sbagliate le scopri settimane dopo, nei report dei tool Analytics che non quadrano.
Scriverne uno fatto bene richiede tempo, perché è un lavoro ripetitivo e manuale:
- Percorrere ogni flusso del sito, da desktop e da mobile, come farebbe un utente reale.
- Fare lo screenshot di ogni interazione e segnare esattamente dove deve scattare ogni evento.
- Mappare i dati del sito (codici prodotto, prezzi, ID dei punti vendita) sui parametri ecommerce di GA4.
- Scrivere un
dataLayer.pushper ogni evento, che lo sviluppatore possa copiare e incollare. - Documentare le regole che nessuno scrive: svuotare l'oggetto ecommerce, formati dei numeri, deduplicazione, consenso.
Quasi tutti questi passaggi sono ripetitivi. È esattamente il caso d'uso ideale per un agente AI con accesso ad un browser.
Il caso: una catena di ristoranti con ordini online e prenotazione tavoli
Il sito appartiene a una catena di ristoranti italiana. Ha due flussi di conversione, entrambi su un sottodominio separato dedicato agli ordini: un flusso Order per ritiro e consegna, e un flusso Book per la prenotazione dei tavoli. Sulla piattaforma degli ordini non c'erano né GTM né dataLayer, quindi il tracciamento partiva da zero.
Ho dato all'agente il sito, un foglio di calcolo di base e una sola istruzione: simulare ogni interazione in entrambi i flussi e adattare gli eventi ecommerce di GA4 dove possibile.
Ecco cosa è tornato indietro:
| Area | Risultato |
|---|---|
| Eventi | 47 in totale: 6 globali, 30 in Order, 11 in Book |
| Per ogni evento | Nome, momento di attivazione, screenshot annotato, URL di esempio, dataLayer.push pronto da copiare, regole sui parametri, menu a tendina per lo stato, note per gli sviluppatori |
| Dati reali | SKU dei prodotti e codici dei ristoranti letti dall'API del sito, quindi gli esempi usano valori reali |
| Fogli aggiuntivi | Indice di copertina, guida per gli sviluppatori, dizionario delle variabili, mappatura dell'oggetto item, setup di GTM e Consent Mode v2, changelog |
L'agente ha anche adattato il modello di GA4 al modo in cui un ristorante vende davvero. La consegna porta l'utente su piattaforme di terze parti, quindi è diventata un evento personalizzato delivery_partner_click. Senza spedizione, add_shipping_info ora porta modalità di ritiro, ristorante e fascia oraria. Nel flusso Book la conversione è generate_lead.
Ha trovato anche interazioni che io avrei elencato solo in un secondo passaggio: un popup di cross-sell sulle bevande (mostrato, aggiunto, chiuso), le promozioni (view_promotion, select_promotion), i filtri vegano e vegetariano, la visualizzazione degli allergeni, la personalizzazione dei piatti, i codici promo, gli errori di pagamento e il "nessuno slot disponibile" nella prenotazione.
Dove si ferma l'AI e inizia l'ingegnere
La bozza sembrava finita. Non lo era, e le lacune erano proprio quelle che un non specialista non vedrebbe.
| Cosa ha gestito bene l'AI | Cosa ha mancato o non ha potuto verificare |
|---|---|
| Percorrere entrambi i flussi ed elencare ogni interazione | Le pagine di conferma di purchase e generate_lead: giustamente si è fermata prima di pagare o prenotare, quindi sono state specificate alla cieca |
| Mappare i dati del sito sui parametri item di GA4 | Login, registrazione e carrello mobile: la sessione era già autenticata e i test erano solo da desktop |
Scrivere codice dataLayer coerente e pronto da copiare | Dati personali: l'email dell'utente compariva negli screenshot e ha dovuto essere oscurata |
| Produrre la guida per gli sviluppatori e le checklist | Segnaposto per gli ID del container GTM e della proprietà GA4 |
Niente di tutto questo è marginale. Un evento purchase sbagliato rompe il reporting dei ricavi e ogni strategia di offerta che ci viene costruita sopra. Dati personali non oscurati in un documento condiviso sono un problema molto serio di GDPR. I flussi mobile non testati sono il punto in cui arriva la maggior parte degli ordini.
Per questo ho diviso il processo in due. L'agente fa l'esplorazione e la prima bozza. Io rivedo ogni evento di conversione confrontandolo con il vero flusso di conferma, segno come "da confermare con gli sviluppatori" ciò che non è verificato, controllo hashing e consenso, e decido che cosa vale davvero la pena tracciare. L'agente fa risparmiare le ore; la revisione è ciò che rende il documento affidabile e pronto per la produzione.
Anatomia di un tracking plan pronto per gli sviluppatori
L'obiettivo è semplice (nella teoria): uno sviluppatore che apre il file deve sapere cosa fare senza chiamarti. Queste sono le colonne che ogni riga di evento deve avere.
| Colonna | Perché conta |
|---|---|
| Nome dell'evento | Il nome esatto in GA4, in snake_case, senza ambiguità |
| Trigger | Quando scatta, a parole ("dopo che l'articolo è stato aggiunto al carrello, non al click") |
| Screenshot | L'elemento evidenziato, così nessuno traccia il pulsante sbagliato |
| URL di esempio | Dove riprodurlo |
dataLayer.push | Codice da copiare con valori realistici |
| Regole sui parametri | Tipi, formati, valori ammessi |
| Stato | Menu a tendina: da fare, in corso, implementato, validato |
| Note | Casi limite e domande aperte |
Oltre ai fogli degli eventi, ci sono alcuni fogli di supporto che evitano fraintendimenti:
- Copertina: un indice di tutti gli eventi con i link a ogni riga.
- Guida per gli sviluppatori: le regole condivise, come
ecommerce: nullprima di ogni push, navigazione single-page, formati dei numeri, deduplicazione e hashing SHA-256 peruser_data. - Dizionario delle variabili: ogni parametro con i suoi valori ammessi.
- Mappatura degli item: come i campi prodotto del sito diventano parametri item di GA4.
- Setup di GTM: installazione del container con Consent Mode v2.
- Changelog: cosa è cambiato nel documento e quando.
Il punto d'arrivo, e come ottenere il tuo
L'AI ha reso la parte più lenta di un progetto di tracciamento la più veloce. Non ha eliminato la necessità di qualcuno che capisca quanto costa un evento purchase rotto.
