Server-side tagging con Google Tag Manager: cosa migliora davvero e cosa no

Negli ultimi due anni il server-side tagging è passato da argomento per specialisti a voce fissa nei preventivi. Il problema è che viene quasi sempre raccontato male: come un modo per "recuperare i dati persi", a volte perfino come un modo per aggirare banner e ad blocker. Né l’una né l’altra cosa sono una buona ragione per farlo. Ci sono però ragioni buone, e conviene separarle con cura.

Cos’è, senza marketing

Nel tagging tradizionale, o client-side, il browser del visitatore carica il contenitore di Google Tag Manager e ogni tag invia i propri dati direttamente al rispettivo fornitore: Google Analytics, Google Ads, Meta, LinkedIn e così via. Ogni fornitore riceve la richiesta dal browser, con tutto ciò che il browser porta con sé.

Con il tagging server-side si aggiunge un secondo contenitore, di tipo server, che gira su un’infrastruttura cloud gestita da te e risponde su un sottodominio del tuo sito, per esempio misura.tuosito.it. Il browser invia un flusso di eventi a quel server; il server li riceve tramite i client (i componenti che interpretano le richieste in arrivo) e li inoltra ai fornitori tramite i tag server, decidendo cosa passare e in che forma.

Un dettaglio che si dimentica spesso: il contenitore web non sparisce. Nella configurazione più comune il browser continua a caricare il tag Google, che però invia i dati al tuo server invece che a Google. Il server-side non sostituisce il lato client: lo alleggerisce e lo mette sotto controllo.

Cosa migliora davvero

Contesto first-party e durata dei cookie

Safari, con Intelligent Tracking Prevention, limita a sette giorni i cookie impostati via JavaScript. Un utente che clicca un annuncio e torna a comprare dopo dieci giorni, per il tag, è un utente nuovo: la conversione perde il legame con il clic. Un cookie impostato da un server tuo, tramite intestazione HTTP, può invece avere una durata più lunga.

Con una condizione che molti progetti ignorano: dalla versione 16.4 Safari limita a sette giorni anche i cookie impostati dal server se l’indirizzo IP del server di tagging non corrisponde, nella sua prima metà, a quello del sito, o se il sottodominio punta via CNAME a un host di terzi. Un container su Cloud Run collegato a un sito ospitato altrove spesso non supera questo controllo. Il beneficio sui cookie è reale solo se l’architettura è pensata per ottenerlo, per esempio servendo il container sullo stesso dominio del sito tramite il bilanciatore o la CDN che già lo servono.

Controllo su cosa arriva ai fornitori

È il vantaggio più sottovalutato e, per noi, il più importante. Nel modello client-side ogni pixel riceve dal browser indirizzo IP, user agent, URL completo con eventuali parametri, referrer. Nel modello server-side decidi tu: puoi rimuovere parametri che contengono dati personali finiti nell’URL per errore, troncare l’IP, eliminare campi che un fornitore non ha bisogno di ricevere, aggiungere il margine di prodotto al valore di conversione senza esporlo nella pagina.

Prestazioni della pagina

Ogni pixel di terze parti che togli dal browser è JavaScript in meno da scaricare ed eseguire. Se oggi il sito carica Google Ads, GA4, Meta, TikTok e LinkedIn, passare a un solo flusso verso il tuo server e distribuire da lì può ridurre in modo concreto il carico sul thread principale. Se il sito carica solo i tag Google, il guadagno è modesto: non aspettarti miracoli sui Core Web Vitals.

Qualità dei dati per le conversioni

Un flusso server-side è anche il posto naturale per integrare le API di conversione dei fornitori e per unire dati di prima parte in modo ordinato, il che si combina bene con le enhanced conversions e la Data Manager API. Non genera conversioni dal nulla: rende più affidabile la raccolta di quelle che già misuri.

Cosa non fa, e non deve fare

• Consent Mode continua ad applicarsi. Lo stato del consenso viaggia con le richieste che arrivano al server, e i tag Google lato server lo rispettano. Per i tag di altri fornitori la gestione dipende dal template: spesso sei tu a dover condizionare l’invio allo stato del consenso. È il punto in cui vediamo più errori. Le basi sono nella guida a Consent Mode v2 e DMA.
• Il GDPR continua ad applicarsi. L’indirizzo IP e gli identificativi nei cookie restano dati personali. In più, il server è un trattamento in più: ti serve un accordo con il fornitore di hosting, la scelta di una regione europea, una voce nel registro dei trattamenti e un’informativa che descriva il flusso reale.
• Non è uno strumento per aggirare gli ad blocker. Può succedere che alcune richieste passino perché il dominio è il tuo; costruirci sopra la strategia significa ignorare una scelta esplicita dell’utente. Non è un terreno su cui vogliamo portare i nostri clienti.
• Non corregge un tracciamento sbagliato. Se gli eventi nel dataLayer sono incompleti o duplicati, il server li inoltrerà incompleti o duplicati, con un costo di hosting in più.

Quanto costa

I costi hanno tre componenti: infrastruttura, configurazione iniziale, manutenzione. La prima è l’unica con un listino.

Su Google Cloud Run, l’opzione documentata da Google, la raccomandazione per la produzione è di tenere almeno due istanze attive per ridurre il rischio di perdita di dati in caso di guasto. Ogni istanza, con 1 vCPU e 0,5 GB di memoria e CPU sempre allocata, costa secondo Google circa 45 $ al mese. Da due a dieci istanze in autoscaling gestiscono, sempre secondo la documentazione, fra 35 e 350 richieste al secondo, a seconda di quanti tag giri e di cosa facciano.

In alternativa esistono provider gestiti specializzati nell’hosting di container server-side, con piani a consumo di richieste. Tolgono il lavoro sistemistico e spesso offrono strumenti aggiuntivi; in cambio aggiungi un altro soggetto al trattamento, da valutare contrattualmente come qualsiasi responsabile esterno.

La voce che nessuno mette a preventivo è la manutenzione: aggiornare l’immagine del server, controllare che i template dei fornitori seguano le loro API, verificare dopo ogni rilascio del sito che il flusso di eventi sia integro. È lavoro continuo, non un progetto una tantum.

Quando conviene e quando no

Conviene quando si verificano almeno due di queste condizioni:

• La spesa pubblicitaria è tale che qualche punto percentuale di conversioni misurate meglio vale più di qualche centinaio di euro l’anno di hosting e manutenzione.
• Lavori con più piattaforme pubblicitarie oltre a Google, e vuoi un solo punto di controllo su cosa ricevono.
• Una quota rilevante del traffico è Safari o iOS e i cicli d’acquisto superano la settimana.
• Hai esigenze concrete di minimizzazione dei dati verso i fornitori, per esempio in ambito sanitario o finanziario.

Non conviene, o non ancora, quando il sito usa solo i tag Google, il volume di conversioni è basso e nessuno in azienda può seguirne la manutenzione. In quel caso l’alternativa è Google tag gateway for advertisers: consente di caricare i tag Google dal tuo dominio passando per la CDN, per esempio Cloudflare, senza un server da gestire. Copre solo i tag Google, ma per molti account è il compromesso giusto.

Checklist di implementazione

1. Metti in ordine il tracciamento client-side prima di toccare il server: eventi, parametri, valori, deduplica. Il server amplifica quello che riceve.
2. Scegli l’hosting e la regione: una regione europea, per esempio Milano o Francoforte, e un accordo sul trattamento dei dati con il fornitore.
3. Progetta il dominio pensando a Safari: stesso dominio del sito o un sottodominio il cui IP sia compatibile con quello del sito, non un CNAME verso un host di terzi.
4. Configura produzione e anteprima come servizi separati, con almeno due istanze minime in produzione.
5. Invia il tag Google al server tramite il parametro di URL del server, e verifica in anteprima che le richieste arrivino al client GA4.
6. Gestisci il consenso tag per tag: verifica che i tag Google rispettino lo stato ricevuto e condiziona esplicitamente quelli degli altri fornitori.
7. Applica la minimizzazione: rimuovi dagli URL parametri con dati personali, tronca l’IP dove non serve, invia a ogni fornitore solo ciò di cui ha bisogno.
8. Riduci i log di Cloud Run al minimo utile, o i costi di logging supereranno quelli delle istanze.
9. Confronta i numeri per due-quattro settimane con il setup precedente e con i dati del gestionale, prima di spegnere i vecchi pixel.

Gli errori che vediamo più spesso

• Doppio conteggio: il vecchio pixel client-side resta attivo accanto al nuovo tag server-side, e le conversioni raddoppiano. Lo Smart Bidding ringrazia, poi sbaglia tutte le offerte.
• Una sola istanza in produzione per risparmiare 45 $ al mese: al primo riavvio si perdono eventi senza che nessuno se ne accorga.
• Cookie "server-side" che durano comunque sette giorni perché il dominio non supera il controllo di Safari sull’IP. Si paga il progetto senza incassare il beneficio principale.
• Tag di terze parti che ignorano il consenso, perché si è dato per scontato che il server "gestisca il consenso da solo".
• Nessun monitoraggio: il server è un sistema di produzione, e se si ferma la misurazione si ferma con lui. Serve almeno un allarme sul volume di richieste.

Fatto bene, il server-side tagging è uno dei pochi interventi che migliorano insieme qualità del dato, controllo e conformità. Fatto per inseguire una promessa di "dati recuperati", è un costo in più con un rischio in più. Nelle nostre analisi gratuite verifichiamo prima se serve, poi come farlo: puoi vedere come lavoriamo sulla misurazione e le risposte alle domande più frequenti nelle FAQ.