GTM server side: cos’è, come funziona e quanto serve davvero

Come viaggia un evento con il server side?

Passa da una tappa in più: il browser manda i dati al tuo server, e da lì partono verso le piattaforme. Senza server, ogni piattaforma riceve una richiesta direttamente dal browser del visitatore.

1. Un visitatore compie un’azione e il contenitore web fa partire il tag Google.
2. Il tag invia la richiesta all’indirizzo del tuo contenitore server, indicato nelle sue impostazioni.
3. Nel server un componente detto client riconosce la richiesta, la «prende in carico» e la trasforma in evento.
4. L’evento attraversa il contenitore server: attivatori e tag funzionano come nel contenitore web.
5. I tag server inviano i dati alle piattaforme scelte, ed eventualmente modificati.

Il punto che sorprende di più è il primo: il contenitore web resta dov’è. Gli eventi nascono comunque sul sito, quindi il server inoltra quello che gli arriva. Se il valore dell’acquisto parte sbagliato dal browser, arriverà sbagliato anche alle piattaforme.

Che cosa ci guadagni?

Ci guadagni controllo. Fino a quando non decidi di inoltrarli, i dati nel server li vedi solo tu, e puoi scegliere campo per campo cosa passa a ciascuna destinazione.

• Filtrare prima di inviare. Un dato che non deve arrivare a una piattaforma si toglie sul server.
• Meno codice nel browser. Google segnala che meno tag di misurazione sul sito significa meno codice da eseguire. Quanto si guadagna dipende da quanti ne sposti davvero.
• Cookie più robusti. Dal tuo dominio il server può scrivere cookie gestiti lato server, anche non leggibili dagli script della pagina.
• Un punto di controllo unico. I log mostrano cosa parte davvero verso ogni piattaforma.

Da qui deriva il suo valore economico: se le campagne imparano da dati più puliti, le decisioni di spesa partono da una base migliore. Attenzione a chi ti promette percentuali di dati in più: dipende troppo dal sito e dal pubblico perché una cifra valga per tutti.

Perché il dominio cambia tutto?

Perché senza il tuo dominio perdi gran parte dei vantaggi sui cookie. Con l’indirizzo predefinito del servizio, il server lavora in un contesto di terze parti. Google consiglia di collegarlo a un dominio tuo prima di farci passare il traffico vero.

Indirizzo del server	Esempio	Cookie impostati dal server	Che cosa richiede
Stessa origine del sito	www.esempio.it/metrics	Pieno accesso ai vantaggi	Un CDN o un bilanciatore che inoltri le richieste
Sottodominio	metrics.esempio.it	Pieno accesso ai vantaggi	Aggiornare il DNS
Dominio predefinito	metrics.run.app	Nessuno, solo cookie JavaScript	Già pronto

Google indica come buona pratica la stessa origine, mentre il sottodominio è la strada più semplice: basta un record DNS. In entrambi i casi conviene controllare le regole di sicurezza del sito, perché le politiche sui contenuti devono autorizzare l’indirizzo del contenitore server.

Quanto costa, in linea generale?

Costa un servizio di hosting che cresce con il traffico, e il tempo di chi lo segue. Al contrario del contenitore web, qui c’è un server da pagare e da tenere acceso, che tu lo faccia su Google Cloud o con un servizio gestito come Stape.

Voce di costo	Da cosa dipende
Server	Numero di server attivi e traffico da gestire
Log delle richieste	Volume delle richieste registrate: su grandi numeri può pesare
Dominio e configurazione	Soluzione scelta fra sottodominio e stessa origine
Lavoro di impianto	Quante piattaforme e quanti tag vanno portati sul server
Manutenzione	Controlli, aggiornamenti, un contenitore in più da tenere in ordine

Le cifre aggiornate stanno sulle pagine di Google Cloud e dei fornitori, e cambiano nel tempo: conviene chiedere un preventivo sul tuo traffico vero. Una cosa però è utile sapere. La guida di Google consiglia più di un server, per ridurre il rischio di perdere dati in caso di guasto, e indica l’impianto di prova con risorse limitate come adatto solo a volumi di test.

Un server fermo non fa rumore: se smette di rispondere, gli eventi spariscono senza errori sul sito. Metti in conto degli avvisi su errori e cali improvvisi.

Che cosa non risolve?

Non risolve il consenso, né un dato nato male. Sono le due illusioni più comuni, e seguirle costa caro.

• Il consenso resta obbligatorio. Si configura nel contenitore web, e il tag Google inoltra lo stato al server con la richiesta. I tag di Google lato server adattano il loro comportamento a quella scelta. Con il consenso negato, per esempio, i cookie di Analytics non vengono scritti né letti nemmeno sul server.
• Non corregge eventi sbagliati. Puoi modificare qualche campo, ma se un evento manca o arriva doppio, va sistemato prima.
• Non toglie il contenitore web. I due lavorano insieme.
• Non sostituisce le verifiche. Le differenze fra report e ordini restano, come spiega la guida ai numeri diversi fra GA4 e gestionale.

Sul consenso vale la pena di leggere come funziona Consent Mode v2. Se i tag devono rispettare le scelte del visitatore nel browser, lo stesso accade qui: cambiare il percorso dei dati non cambia gli obblighi. Il caso specifico va valutato con chi segue la privacy dell’azienda.

Quanto serve davvero?

Serve quando il contenitore web è già pulito e hai un motivo preciso. Un buon test è provare a completare questa frase: «passo al server perché voglio…». Se la risposta è concreta, come togliere certi campi o tenere fuori i bot, ha senso approfondire. Se è «perché lo fanno tutti», aspetta.

La scelta con le regole di decisione è nell’articolo su client side o server side. La configurazione di Google Tag Manager server side copre dominio, hosting, filtro dei bot, dati utente e controllo nel tempo, e parte dal capire se per il tuo negozio serve davvero.

Domande frequenti

Fonti

• Google Tag Manager: introduzione al tagging lato server
• Google Tag Manager: panoramica del lato server
• Google Tag Manager: dominio personalizzato
• Google Tag Manager: lato server e Consent Mode
• Google Tag Manager: installazione su Cloud Run
• Google Tag Manager: inviare dati al contenitore server