Due giorni di null nel report automatico. Il tracking rotto che nessuno tocca.

Il messaggio che si ripete

Giovedì pomeriggio il report giornaliero arriva su Slack, nel canale dove confluiscono i dati di tutti i clienti. È il solito messaggio automatico generato dal workflow n8n che interroga BigQuery ogni giorno. Sessioni, pageview, transazioni, revenue. Confronto con il giorno prima. Alert quando qualcosa non torna.

Per un e-commerce nel settore cosmetico, il messaggio è chiaro.

Le sessioni ci sono. Le pageview ci sono. Ma le transazioni e la revenue sono null. Non zero. Null. Il che significa che il pixel di tracking non sta passando i dati delle transazioni al sistema di raccolta. Il codice è rotto, o qualcuno lo ha tolto, o un aggiornamento ha cambiato qualcosa nel template dell'e-commerce.

Prendo nota. Verifico rapidamente che non sia un problema lato server container o un errore nella query. Non lo è. Il problema è nel sito del cliente.

Venerdì, stessa storia

Il giorno dopo il workflow gira di nuovo. Stesso orario, stesso canale.

Le sessioni sono leggermente aumentate. Le pageview pure. Ma le transazioni continuano a essere null. Siamo al secondo giorno consecutivo. Significa che se in queste 48 ore ci sono stati ordini, non li stiamo vedendo. GA4 non li registra. Meta non li riceve. Google Ads non può ottimizzare. Tutta la catena di attribuzione pubblicitaria è cieca.

Per capire la portata del danno bisogna pensarla così. Le campagne pubblicitarie continuano a girare. Il budget viene speso. Ma l'algoritmo di Meta e Google non riceve segnali di conversione. Quindi non impara. Non ottimizza. Sta sparando nel buio.

Il valore del monitoring quotidiano

Senza il report automatico avrei scoperto questo problema il lunedì successivo, forse il martedì, aprendo GA4 e notando un buco nei dati. O peggio, me lo avrebbe segnalato il cliente. A quel punto sarebbero stati 5 giorni di dati persi, 5 giorni di campagne che giravano senza feedback.

Il workflow n8n non è intelligente. Non sa perché il tracking è rotto. Non propone soluzioni. Fa una cosa sola e la fa ogni giorno alla stessa ora. Confronta i numeri di oggi con quelli di ieri. Se qualcosa è null o crolla oltre una certa soglia, mette un alert. Fine.

Ma questa semplicità è esattamente ciò che serve. Perché il problema del monitoring nel digital analytics non è mai stato la complessità dell'analisi. È sempre stato la costanza del controllo. Nessuno apre GA4 ogni giorno per ogni cliente. Nessuno controlla manualmente se il pixel di tracking funziona ancora dopo ogni deploy. Serve un sistema che lo faccia per te, e che ti avvisi quando qualcosa cambia.

Il problema organizzativo

Ecco dove la faccenda diventa interessante. Il tracking è rotto. Lo so dal giovedì. Ma il fix non dipende da me.

In molti progetti e-commerce la catena è questa. Il consulente analytics (io) gestisce la configurazione del tracking, i tag in Google Tag Manager, il server container, le connessioni a Meta e Google Ads. Ma il codice che genera il dataLayer, quello che vive nelle pagine del sito, nel template dell'e-commerce, quello lo scrive e lo mantiene il developer del cliente.

Quando il tracking si rompe perché qualcosa è cambiato nel template, io posso solo segnalarlo. Posso scrivere esattamente cosa serve, dove va messo il codice, come deve essere strutturato il dataLayer. L'ho già fatto. Ho già mandato la documentazione tecnica. Ma se il developer non interviene, il tracking resta rotto.

E qui si apre una dinamica che chi fa consulenza conosce bene. Il cliente chiede aggiornamenti. L'agenzia che gestisce il marketing chiede la timeline. Tu hai fatto la tua parte settimane fa. Hai mandato il documento tecnico, hai spiegato cosa serviva, hai seguito gli aggiornamenti. Ma il developer ha altre priorità, o non ha capito l'urgenza, o semplicemente non ha tempo.

Documentare tutto diventa una necessità

In questa settimana mi sono trovato a dover ricostruire una timeline precisa di tutto quello che abbiamo fatto per il tracking di un altro progetto dello stesso gruppo. L'agenzia aveva bisogno di un riepilogo per capire perché certi miglioramenti avevano richiesto tempo.

La risposta era semplice. Nella prima settimana di marzo abbiamo analizzato gli eventi principali, come il purchase, e abbiamo trovato che mancavano informazioni critiche nel dataLayer. Email degli utenti, regione, dati che Meta usa per il matching. Abbiamo preparato un documento con i codici da implementare e lo abbiamo inviato al developer. Il developer ha fatto le modifiche. Noi abbiamo implementato l'hashing secondo la documentazione ufficiale di Meta e configurato l'invio tramite il server container.

Nella seconda settimana abbiamo esteso il lavoro ad altri eventi. Non solo il purchase, ma anche le pageview e l'add to cart. Più eventi inviano dati utente con hash corretto, più la match quality di Meta migliora.

Tutto questo ha funzionato. I miglioramenti nel Meta Event Manager erano visibili. Ma ha richiesto due settimane, non perché il lavoro tecnico fosse complesso, ma perché ogni passaggio richiedeva una risposta dal developer.

La lezione per chi gestisce il tracking

Il monitoring automatico ti dice quando qualcosa si rompe. Ma non può risolvere il chi deve agire.

Nel mio setup il workflow n8n interroga BigQuery, confronta i dati, posta su Slack. Lo fa per tutti i clienti, ogni giorno. Quando vedo un null so immediatamente che c'è un problema. Ma la velocità con cui quel problema viene risolto dipende da fattori che nessun sistema automatico può controllare. Dipende da quanto velocemente il developer risponde. Da quanto l'agenzia preme. Da quanto il cliente capisce che ogni giorno di tracking rotto è un giorno di dati persi per sempre.

Per questo motivo ho iniziato a trattare la documentazione tecnica come un asset operativo. Ogni richiesta che faccio a un developer la scrivo in modo che sia tracciabile. Data, contenuto, destinatario. Ogni modifica implementata viene annotata con la data. Se tra tre settimane qualcuno chiede perché ci è voluto tanto, la timeline è lì. Non è un'accusa. È una fotografia di come funziona il processo.

Cosa cambierei

Se potessi ridisegnare il flusso dall'inizio, aggiungerei un livello. Il report automatico oggi segnala l'anomalia su Slack. Ma potrebbe anche inviare una notifica diretta al developer o al project manager del cliente. Non un messaggio generico. Un messaggio specifico con il nome del sito, il tipo di problema e il link alla documentazione tecnica già pronta.

Non l'ho ancora implementato perché in molti casi il rapporto con il developer del cliente è mediato dall'agenzia. Ma è il passo logico successivo. Ridurre il tempo tra il momento in cui il sistema rileva il problema e il momento in cui la persona giusta lo vede.

L'altro cambiamento è aggiungere un contatore. Quanti giorni consecutivi il tracking è rotto per un dato cliente? Due giorni di null è un warning. Cinque giorni è un'emergenza. Dieci giorni significa che qualcuno deve alzare il telefono.

Il tracking non è un progetto. È un processo.

La tentazione è pensare al tracking come a qualcosa che si configura una volta e poi funziona. La realtà è che ogni aggiornamento del template, ogni deploy, ogni cambio di piattaforma può rompere qualcosa. E quando si rompe, i dati non aspettano. Spariscono. Non puoi recuperare retroattivamente le transazioni che GA4 non ha registrato.

Il monitoring automatico è il minimo indispensabile. Ti dice che il problema esiste. Ma la vera infrastruttura è quella organizzativa. Chi riceve l'alert? Chi ha il potere di agire? Quanto tempo ci mette? Queste sono le domande che determinano quanti dati perdi.

Due giorni di null nel report. Il sistema ha funzionato perfettamente. Il fix dipende da qualcun altro.