Chi guarda una dashboard di GA4 o di Meta Ads con la sensazione che i numeri non tornino più come una volta non sta immaginando le cose. Il tracciamento lato client — lo script che gira nel browser dell’utente e spedisce i dati direttamente ai server di Google, Meta o chiunque altro — funziona sempre peggio, non perché sia cambiato il codice, ma perché è cambiato tutto quello che gli sta intorno: ad blocker più aggressivi, Safari che tronca la durata dei cookie impostati da script di terze parti, utenti che negano il consenso. Il server-side tagging è la risposta tecnica a questo deterioramento, ed è utile capire con precisione cosa risolve e cosa, nonostante il nome suggestivo, non tocca affatto.
Cosa cambia, tecnicamente
Nel modello client-side tradizionale, lo script installato sul sito — un tag di Google Analytics, un pixel di Meta — gira direttamente nel browser dell’utente e invia i dati raccolti a un dominio di terze parti, tipicamente quello del fornitore della piattaforma di analytics o advertising. Il server-side tagging inserisce un passaggio intermedio: i dati vengono inviati prima a un contenitore server di proprietà dell’azienda — ospitato su Google Cloud, AWS o un fornitore gestito come Stape — che li elabora e li instrada verso le destinazioni finali, invece di farli partire direttamente dal browser verso il dominio esterno.
Questo spostamento produce tre effetti concreti. Il primo è la resilienza agli ad blocker: molti strumenti di blocco della pubblicità riconoscono e interrompono le richieste dirette verso domini noti come google-analytics.com o facebook.com, ma faticano a distinguere una richiesta verso il proprio dominio di primo livello che internamente instrada i dati altrove. Il secondo è la durata dei cookie su Safari: Intelligent Tracking Prevention tronca a circa sette giorni la vita dei cookie impostati da script lato client, ma un cookie impostato dal server come cookie di prima parte può avere una durata molto più lunga, migliorando la capacità di riconoscere un utente che torna sul sito settimane dopo. Il terzo, probabilmente il più sottovalutato dai materiali commerciali che insistono sui primi due, è la possibilità di arricchire il dato prima che lasci l’azienda: informazioni che vivono solo nel CRM interno — il margine reale di un ordine, il punteggio di qualità di un lead — possono essere agganciate all’evento di conversione lato server prima di inviarlo alle piattaforme pubblicitarie, dando agli algoritmi di ottimizzazione automatica un segnale più ricco di quello che il solo tracciamento client-side potrebbe fornire.
Cosa non cambia
Il server-side tagging non è un modo per aggirare il consenso dell’utente. Se una persona rifiuta i cookie di profilazione tramite il banner di consenso, quel rifiuto va rispettato indipendentemente da dove viene elaborato il dato a valle: spostare l’elaborazione su un server proprietario cambia l’affidabilità tecnica della trasmissione, non le regole legali su cosa si può raccogliere. Chi presenta il server-side tagging come soluzione al problema del consenso sta confondendo due questioni distinte, e chi lo acquista con quell’aspettativa resterà deluso.
Non risolve nemmeno, da solo, il problema più ampio della perdita di segnale legata ai cookie di terze parti bloccati di default da Safari, Firefox e Brave, discusso altrove su questa testata: il server-side tagging migliora l’affidabilità del dato che l’azienda è comunque legittimata a raccogliere, non recupera dati da utenti che non hanno mai acconsentito o che usano un browser che blocca il tracciamento a prescindere dal consenso.
Il costo reale, oltre l’entusiasmo dei fornitori
Un container server-side non gira gratis: l’ordine di grandezza citato dalla documentazione ufficiale di Google per un’istanza Cloud Run base è tra i 30 e i 50 dollari al mese, una cifra che sale con il volume di traffico gestito, a cui si aggiunge il tempo di configurazione tecnica — mappare correttamente ogni tag, gestire la logica di consenso lato server, mantenere il sistema quando le piattaforme di destinazione aggiornano le proprie API. Per un’azienda senza competenze tecniche interne, questo costo di manutenzione ricorrente è spesso più significativo del canone del server in sé, ed è la ragione per cui sono nati fornitori gestiti come Stape o Addingwell, che si occupano dell’infrastruttura sottostante in cambio di un abbonamento, riducendo ma non eliminando il carico tecnico richiesto internamente.
L’alternativa più leggera arrivata nel 2026
Nel giugno 2026 Google ha ampliato la disponibilità di Google Tag Gateway, una funzionalità che integra nativamente una rete di distribuzione di contenuti — inizialmente basata su Amazon CloudFront — per servire gli script di Google Tag Manager da un dominio di primo livello, senza però offrire l’elaborazione server-side completa che caratterizza un’installazione dedicata. È un compromesso pensato per chi cerca principalmente resilienza nella consegna dei tag e una gestione più solida del segnale di prima parte, senza voler affrontare la complessità e il costo di un’infrastruttura server-side completa. Secondo le prime analisi tecniche pubblicate dopo il rilascio, le sue prestazioni reali si sono rivelate più sfumate di quanto il materiale di lancio di Google lasciasse intendere — un promemoria utile che vale, ancora una volta, il principio già richiamato altrove su questa testata: verificare sul campo prima di fidarsi della descrizione commerciale di una nuova funzionalità.
Chi dovrebbe davvero considerarlo
L’indicazione che emerge in modo abbastanza coerente tra gli osservatori tecnici del settore è che il server-side tagging conviene soprattutto a chi gestisce campagne pubblicitarie multi-piattaforma con volumi consistenti, dove anche un piccolo miglioramento nella qualità del segnale di conversione si traduce in un effetto misurabile sull’efficienza della spesa, e a chi ha già una minima capacità tecnica interna — o il budget per un fornitore gestito — per mantenere l’infrastruttura nel tempo. Per un sito con volumi di conversione contenuti, il guadagno in qualità del dato rischia di essere marginale rispetto al costo di implementazione e manutenzione, e le funzionalità di enhanced conversion offerte direttamente dalle piattaforme pubblicitarie, senza bisogno di un’infrastruttura server-side dedicata, coprono spesso una parte sufficiente del bisogno reale.
Un errore da evitare
Trattare l’implementazione del server-side tagging come un progetto da completare una volta e poi dimenticare. Le piattaforme di destinazione — Google Ads, Meta, gli altri strumenti collegati — aggiornano periodicamente i propri requisiti API, e un’integrazione server-side non mantenuta smette silenziosamente di funzionare correttamente molto prima di quanto chi l’ha configurata se ne accorga, proprio perché il problema non produce un errore visibile ma un degrado progressivo della qualità del dato — lo stesso tipo di rischio silenzioso già descritto a proposito dei modelli di misurazione discussi nella sezione Numeri di questa testata.