Di tracciamenti ne ho implementati e sistemati centinaia. Su siti diversi, con strumenti diversi e configurazioni che spesso si erano accumulate nel tempo.
Il banner dei cookie c'è. Google Tag Manager anche. Qualcuno ha inserito Analytics, qualcun altro il pixel di Meta. Nel pannello sembra esserci tutto.
Poi apri il debugger.
Un tag arriva da GTM, un altro da un plugin, un altro ancora dal tema. Disattivi qualcosa e le chiamate continuano a partire. Oppure il banner raccoglie la scelta dell'utente, ma lo stato iniziale del consenso arriva dopo che una parte dei tracciamenti è già stata eseguita.
Sono situazioni diverse, che incontro nel lavoro. Prima di aggiungere un tag devo capire chi sta già facendo cosa, da dove e in quale momento.
Dove finisce la configurazione e comincia il codice
Ci sono anche le implementazioni che escono dal percorso previsto dal tutorial.
Per dire: devi tracciare un form che invia senza ricaricare la pagina. Non c'è una thank-you page. Il form potrebbe stare dentro un iframe, dentro un'applicazione che gestisce i propri passaggi senza cambiare pagina.
Il click sul pulsante lo vedi, forse. Ma dopo quel click l'invio può riuscire, fallire o fermarsi su un campo compilato male. Devi arrivare al segnale che ti interessa, capire chi lo produce e come farlo uscire da quel componente.
Se l'applicazione incorporata può comunicare con la pagina che la contiene, puoi lavorare su quel collegamento. Ho seguito anche integrazioni tramite postMessage, con gli sviluppatori che preparavano il segnale e i dati dell'evento, e la parte di tracciamento che li riceveva e li utilizzava. Servono interventi sui pezzi che devono parlarsi e prove sul flusso reale.
Un'altra situazione: una conversione viene inviata più volte. Puoi mettere una mitigazione in GTM, ma devi anche capire se l'applicazione sta comunicando nuovamente lo stesso fatto e quali casi rimangono fuori dalla tua correzione.
È qui che mi serve saper leggere e scrivere codice. Per seguire il funzionamento dell'applicazione, costruire il collegamento quando manca e verificare che i dati trasmessi corrispondano a quello che è successo.
I pezzi installati raccontano solo una parte
Anche il consenso richiede questo tipo di lavoro. Il banner è visibile; bisogna vedere come inizializza lo stato, come lo aggiorna e come gli altri componenti usano quei segnali.
Una chiamata di rete prima dell'accettazione, da sola, non basta per capire se c'è un errore: in Consent Mode avanzato possono partire ping senza cookie. Devi guardare lo stato e il comportamento previsto dall'implementazione. Documentazione Google.
Per questo mi interessa vedere quello che viene eseguito nel browser, oltre a quello che risulta configurato nei pannelli. Se le due cose non coincidono, devo risalire al passaggio che le separa.
E le verifiche possono cambiare anche l'intervento che avevo in mente. Mi è capitato di proporre di centralizzare i tracciamenti in GTM e poi, guardando meglio i moduli presenti, trovare componenti server-side e logiche di deduplica che aveva senso conservare. A quel punto il lavoro era organizzare la convivenza, evitando sovrapposizioni.
Conoscere gli strumenti serve anche a capire quando lasciare un pezzo dov'è.
Quello che rimane dopo centinaia di interventi
Lavorando su queste cose accumuli dei percorsi di verifica. Sai quali origini controllare, quali segnali cercare, quali domande fare a chi sviluppa il sito. Alcune configurazioni le riconosci, altre ti costringono a cambiare strada.
Poi, quando devi analizzare i dati, questa conoscenza torna utile anche dall'altra parte: sai che il numero nel report dipende da un'implementazione, e che trovare un difetto oggi non basta a spiegare quello che è successo mesi fa.
Una parte di quel lavoro si può organizzare: interrogare le fonti, conservare i risultati, confrontare periodi, tenere insieme una verifica e il motivo per cui l'hai fatta. Le valutazioni richiedono comunque il contesto del sito e qualcuno che le controlli.
Da qui sono arrivato al repository di analisi su cui sto lavorando con un agente IA.
Dare all'agente un ambiente con cui lavorare
Nel primo articolo sul repository ho raccontato come ho messo insieme script, istruzioni, percorsi di analisi e un registro delle evidenze.
Qui mi interessa il motivo per cui quei pezzi hanno quella forma.
Se conosco una materia, posso scegliere quali operazioni rendere disponibili all'agente e quali controlli chiedergli. Posso preparare strumenti per interrogare una fonte e salvare la risposta, ma anche istruzioni per specificare periodo e filtri, confrontare le osservazioni e lasciare aperta un'ipotesi quando manca una verifica.
Durante il lavoro posso chiedere un approfondimento e l'agente può eseguirlo usando gli strumenti disponibili. Il risultato rimane collegato alla richiesta e può diventare il punto di partenza del passaggio successivo. Io porto il contesto, controllo le interpretazioni e modifico l'ambiente quando vedo che qualcosa manca o porta fuori strada.
Questo sistema ha già prodotto un'analisi e un documento. Alcune parti sono ancora legate alla prima esecuzione; il riuso su altri lavori va verificato. Le centinaia di interventi sono l'esperienza da cui parto, mentre l'ambiente per l'agente è una cosa che sto costruendo e facendo evolvere.
Mi interessa proprio questo collegamento: prendere un lavoro che conosco abbastanza da poterne discutere i dettagli e costruirci intorno strumenti capaci di eseguire una parte delle operazioni, conservando quello che fanno.
Poi li uso. E mentre li uso vengono fuori altre cose da collegare, altri controlli da aggiungere, qualche istruzione che sembrava chiara e invece non lo era.