Il template Meta si è rotto per tutti. Il server-side ha salvato il tracking.
Un aggiornamento del template ufficiale Meta per Google Tag Manager ha trasformato tutti gli eventi in page_view. Per chi aveva solo il client-side, è stato un problema. Per noi, il server-side ha continuato a lavorare come se niente fosse.
Come scopri un disastro alle 6 del mattino
Non è uno scenario teorico. Ieri mattina, prima ancora di bere il caffè, il mio collaboratore ha segnalato un problema critico. C'era un bug nel template ufficiale di Meta per Google Tag Manager. E non era solo nostro.
Il template si era rotto, trasformando letteralmente tutti gli eventi in page_view. Se stavi usando soltanto il client-side tracking, per te era game over. I dati erano corrotti. Niente conversioni reali, niente identificazione di comportamenti specifici, solo page_view ripetute che non dicevano nulla.
Noi lo abbiamo scoperto subito perché avevamo già aggiornato il template per un'agenzia di e-commerce. Gli eventi non erano più quello che dovevano essere. Ma avevamo il server-side in funzione. E il server-side ha salvato la situazione.
Il server-side come polizza assicurativa
Ecco quello che è successo in realtà.
Quando un event viene mandato dal client (page_view, add_to_cart, purchase, qualunque cosa), il server-side vede quello che sta accadendo lato browser, ma non si ferma lì. Il server-side ricostruisce quello che dovrebbe accadere. Nel nostro caso, il server aveva la logica giusta. Aveva le regole. Sapeva esattamente quale evento era quale.
Così mentre il client-side diceva "tutto è page_view", il server-side manteneva la verità. Gli eventi arrivavano al nostro container lato server, e il server li riceveva correttamente, li processava, e li mandava dove dovevano andare. Analytics, Meta, qualunque piattaforma. Nessun dato perso. Niente corrotto.
Il client invia un evento generico al server. Il server ha la logica per capire che cos'è quell'evento, lo valida, lo arricchisce, e lo manda alle piattaforme giuste. Se il client è confuso, il server pensa al posto suo.
La procedura di debug di una mattina
Ha fatto quello che farebbe chiunque voglia capire cosa sia andato storto. Ha controllato il template Meta direttamente. Ha visto il trigger.
Il problema era nel trigger. Era configurato per attivare su un data client specifico che non esisteva più oppure non stava inviando dati. Abbiamo cambiato il trigger da "data client" a "GA4 client". Boom. Risolto.
Sembra semplice perché lo è. Ma la cosa interessante è che abbiamo dovuto verificare il fix non su uno, ma su tutti i nostri client. Perché il template è ufficiale. Se è rotto, è rotto per chiunque lo usi.
Così abbiamo fatto il giro, controllato ogni account, ogni implementazione. Trovato altri client con il medesimo problema. Sistemato ovunque. Fine.
Quando il server-side non basta (e cosa abbiamo fatto)
Non è sempre un happy ending. C'era un'altro cliente con un problema diverso sul remarketing tag. Stesso genere di issue, trigger sbagliato, data client che non funzionava. L'abbiamo fixato anche quello.
E poi c'era un caso ancora diverso. Su uno dei nostri progetti, il server-side stesso aveva dei problemi. Non era il template Meta, era la nostra implementazione server-side che aveva un conflitto. Cosa abbiamo fatto? Abbiamo temporaneamente deciso di tornare al client-side puro.
Perché? Perché a volte il redundancy non significa aggiungere complessità infinita. Se il server-side ha problemi, e il client-side è stabile, usi il client-side. Aspetti, risolvi il problema lato server, poi riconfiguri il setup. Non c'è orgoglio nel mantenere un'architettura complicata quando una semplice funziona.
Cos'è la ridondanza e perché è importante
La storia di ieri è la prova vivente di un principio: la ridondanza non è un lusso, è una scialuppa di salvataggio.
Avere solo il client-side tracking significava essere esposti a quello che è successo ieri. Un update sbagliato, un trigger mal configurato, e i tuoi dati scompaiono. Finito.
Avere il server-side non significa solo avere dati più puliti e di qualità. Significa avere un'assicurazione. Se la parte client si rompe, il server-side continua. Se il server ha un problema, il client è still alive. Non è perfetto, ma è sicuro.
E ieri, questa cosa ha fatto una differenza enorme. Noi continuavamo a tracciare correttamente. I nostri client avevano i loro dati intatti. Niente analisi perse, niente decisioni sbagliate basate su dati falsi.
La lezione
Non è una lezione complicata. Non è su "come costruire un'architettura di tracking perfetta". È più semplice.
Costruisci in modo che se una cosa si rompe, il resto continua a funzionare. Il server-side non è solo per la qualità dei dati o per il GDPR. È una rete di sicurezza. Quando succedono cose strane (e succedono sempre), sei comunque in piedi.
Ieri, grazie a quella rete, non abbiamo perso nulla. Abbiamo fixato il problema in fretta e siamo andati avanti. Poteva andare molto peggio.