Google Tag Manager Server Side:
guida tecnica e scelte operative

Articolo di Team Digital Marketing

Il tracciamento lato client presenta limiti strutturali: parte dell'elaborazione avviene nel browser, gli script di misurazione possono incidere sulle performance e la raccolta dei dati è soggetta alle regole di consenso, alle restrizioni dei browser e ad altri fattori tecnici. Google Tag Manager Server Side introduce un livello intermedio controllato dall'azienda: il server container riceve le richieste di misurazione, le elabora e può inoltrarle alle piattaforme di destinazione secondo regole definite.

Prima di entrare nei passaggi operativi, è utile chiarire il funzionamento del server side tag manager. I dati possono essere inviati al server container, che li interpreta tramite i client, applica eventuali trasformazioni e attiva i tag verso le destinazioni previste.

I benefici potenziali riguardano soprattutto controllo del flusso dei dati, qualità della misurazione e riduzione di parte del lavoro eseguito nel browser, ma dipendono dall'architettura e dall'implementazione adottate.

Prosegui nella lettura per esplorare in dettaglio il funzionamento e i passaggi di configurazione.
 

Google Tag Manager Server Side: cos'è e come funziona

La domanda su che cosa sia Google Tag Manager Server Side genera ancora una certa confusione. In sintesi, è un'architettura di tagging in cui una parte dell'elaborazione e dell'invio dei dati viene spostata dal browser a un server container. Google mette a disposizione il provisioning su Google Cloud Platform, in particolare tramite Cloud Run, ma il server container può essere distribuito anche con modalità manuali su infrastrutture compatibili.

Nel modello client side tradizionale, i tag di misurazione e advertising vengono eseguiti nel browser e comunicano con i rispettivi endpoint. Con il server side tagging, una parte di queste richieste può essere instradata verso il server container, che le interpreta e le inoltra alle destinazioni configurate. Questo consente di centralizzare parte della logica di raccolta e distribuzione e, quando alcuni tag vengono effettivamente spostati dal browser al server, di ridurre il codice e l'elaborazione lato client.

Un vantaggio rilevante riguarda il controllo tecnico sul flusso dei dati. Prima dell'invio alle piattaforme di destinazione, puoi applicare trasformazioni, rimuovere parametri non necessari, normalizzare valori o instradare gli eventi verso sistemi proprietari. Questo non significa che il server side renda automaticamente il trattamento conforme alla normativa privacy: consenso, basi giuridiche, minimizzazione e finalità del trattamento devono comunque essere gestiti nell'architettura complessiva. Un'attività di web analytics ben progettata deve tenere insieme aspetti tecnici, qualità del dato e requisiti di governance.

Dal punto di vista tecnico, i client del server container ricevono le richieste in ingresso e le trasformano in eventi utilizzabili dal container; i tag elaborano gli eventi e inviano i dati verso le destinazioni finali. Il server di tagging comunica via HTTPS e, prima dell'utilizzo in produzione, è opportuno configurarlo in un contesto first-party tramite dominio personalizzato.
 

Vantaggi della configurazione server side di Tag Manager

Per valutare i vantaggi di Google Tag Manager Server Side è importante distinguere le possibilità architetturali dai risultati effettivamente misurati. Il primo beneficio riguarda la qualità e la resilienza della raccolta: un endpoint first-party e una gestione centralizzata degli eventi possono ridurre alcune perdite tecniche e rendere più controllabile la catena di misurazione. L'entità del miglioramento varia però in base a browser, consenso, configurazione dei tag, qualità del data layer e piattaforme utilizzate.

Il secondo vantaggio riguarda la performance. Spostare sul server parte dei tag e delle elaborazioni che altrimenti avverrebbero nel browser può ridurre il lavoro lato client. L'effetto sui Core Web Vitals non è automatico: va verificato con un confronto prima/dopo, perché una configurazione server-side non elimina necessariamente tutti gli script di misurazione dalla pagina.

La privacy è un terzo punto centrale. Il server container può applicare trasformazioni e regole prima dell'invio dei dati alle destinazioni, aumentando il controllo tecnico. Non sostituisce però una CMP, il Consent Mode quando richiesto, né gli altri obblighi previsti dalla normativa applicabile. Il server-side tagging non deve essere utilizzato come strumento per aggirare il consenso o le restrizioni imposte dai browser.

Esiste infine un vantaggio operativo: tag, trigger, variabili e trasformazioni del server container possono essere testati, versionati e pubblicati separatamente dal front-end. In scenari di performance marketing, questo rende più ordinata la gestione delle integrazioni e riduce la necessità di intervenire sul codice applicativo per ogni modifica di routing.
 

Ecco una tabella che riassume il confronto sintetico tra le due architetture:

Parametro Client side Server side
Carico sul browser Dipende dal numero e dalla complessità dei tag in pagina. Può diminuire se parte dei tag/elaborazioni è spostata sul server.
Qualità del dato Più dipendente da browser e script. Maggiore controllo; possibile recupero perdite tecniche.
Controllo privacy Richieste dirette dal browser a più fornitori. Trasformazioni e regole applicabili prima dell'invio.
Complessità tecnica Generalmente più bassa. Più elevata: infrastruttura, routing, monitoraggio.
Costi operativi Nessuna infrastruttura di tagging dedicata. Costi cloud variabili (istanze, traffico, risorse).


 

Come configurare Google Tag Manager Server Side passo dopo passo

La configurazione di GTM server side coinvolge provisioning cloud, server container, dominio first-party, container web e piattaforme di destinazione. L'esempio seguente considera un ecommerce che utilizza Google Analytics 4 e Google Ads. Prima di iniziare servono i permessi necessari in Google Tag Manager, un account Google Cloud con billing attivo per il provisioning su Cloud Run e la possibilità di intervenire su DNS, CDN o load balancer in base all'architettura scelta.
 

1. Provisioning dell'ambiente Cloud Run

In Google Tag Manager crea un nuovo container e seleziona il tipo Server. Con il provisioning automatico puoi scegliere o creare l'account di fatturazione e lasciare che Tag Manager distribuisca il tagging server su Cloud Run. Non è necessario cercare e abilitare una generica “API Tag Manager Server Side” come passaggio preliminare.

Con il provisioning automatico, Google utilizza attualmente us-central1. Se hai requisiti specifici di regione, ridondanza o residenza dei dati, devi valutare un deployment manuale o un'architettura diversa.
 

2. Configurazione del dominio personalizzato

Prima di inviare traffico di produzione, configura il server di tagging in un contesto first-party. Google distingue due opzioni principali: same-origin (es. https://www.tuosito.it/metrics), indicato come best practice tramite CDN/load balancer, e sottodominio (es. https://metrics.tuosito.it), che richiede configurazione DNS.

Il dominio predefinito run.app può essere utilizzato tecnicamente, ma non offre gli stessi vantaggi di un contesto proprietario per i cookie impostati dal server.
 

3. Verifica del client Google Analytics: GA4

Il server container include per impostazione predefinita il client Google Analytics: GA4, che intercetta le richieste GA4 compatibili e le trasforma in eventi del server container. Nella maggior parte dei casi il client non richiede modifiche. Le impostazioni opzionali vanno utilizzate solo quando esiste un'esigenza concreta.
 

4. Configurazione dei tag server side per GA4 e Google Ads

Per Google Analytics crea il tag Google Analytics nel server container. Quando gli eventi arrivano tramite il client, il tag recupera automaticamente la configurazione disponibile nei dati dell'evento.

Per spostare il monitoraggio delle conversioni Google Ads sul server, configura il Conversion Linker nel server container e il tag Monitoraggio delle conversioni di Google Ads. Parametri ecommerce come transaction ID e valore possono essere letti dai campi evento. Le Enhanced Conversions possono integrare dati first-party forniti dall'utente, normalizzati e sottoposti a SHA-256 secondo le specifiche.
 

5. Aggiornamento del container web

Il container web o il Google tag deve inviare gli eventi al server container tramite il parametro server_container_url. Non disattivare preventivamente i tag Google Ads client side; esegui un test controllato, verifica che il tag server riceva/invii correttamente gli eventi e solo dopo rimuovi l'equivalente tag web per evitare duplicazioni o buchi.
 

6. Consenso e trasformazioni

La gestione del consenso continua a partire dal sito. Il server container riceve le informazioni sullo stato del consenso e può applicare ulteriori regole. Il principio è semplice: il server side non crea un'autorizzazione al trattamento che a monte non esiste.
 

Come verificare la corretta configurazione di Tag Manager Server Side

La verifica deve coprire: richiesta in ingresso, client che la prende in carico, tag che si attiva e risposta della piattaforma di destinazione. Utilizza in combinazione l'Anteprima del server container, Tag Assistant, i report di debug delle piattaforme e i log di Cloud Run.

Per la qualità dei dati, il controllo più utile in un ecommerce è confrontare gli eventi purchase con gli ordini effettivi del backend usando come chiave il transaction_id. Evita confronti basati sul semplice numero totale di eventi (duplicazioni possono falsare il risultato). Allinea fuso orario, test interni, cancellazioni e intervallo di osservazione (idealmente 14-30 giorni).

Se gestisci attività di lead generation, definisci un identificatore stabile del lead e controlla separatamente la presenza di client_id, user_id e degli identificatori pubblicitari (es. gclid) necessari all'attribuzione.

Esempio puramente illustrativo: Copertura degli eventi purchase rispetto agli ordini backend (dati simulati)


 

Applicazioni per Google Ads, Meta Ads e altre piattaforme

Il server side tagging è particolarmente utile quando la stessa pipeline deve alimentare più destinazioni pubblicitarie. Il vantaggio non consiste nell'inviare “più dati” indiscriminatamente, ma nel poter controllare quali eventi e quali parametri vengono inviati a ciascuna piattaforma.

Google Ads ed Enhanced Conversions. Google Ads dispone di tag dedicati (Conversion Linker e Monitoraggio conversioni). Dati più affidabili possono creare condizioni migliori per i sistemi di bidding, ma non garantiscono un miglioramento automatico del ROAS. Un'attività di gestione campagne Google Ads deve valutare separatamente qualità della misurazione e performance.

Meta Ads e Conversions API. GTM server-side può essere usato per la Conversions API di Meta. Se lo stesso evento viene inviato sia dal browser sia dal server, la deduplicazione deve essere gestita con un identificatore coerente (es. event_id). Access token e Dataset ID dipendono dal metodo di implementazione.

Google Tag Gateway for advertisers. Annunciato nel 2025, consente di eseguire il Google tag tramite infrastruttura first-party. È complementare, non un'alternativa completa: Gateway instrada i tag, mentre GTM server-side offre un ambiente di elaborazione completo con trasformazioni utilizzabili anche per destinazioni non Google.
 

Sintesi conclusiva e prospettive operative

La configurazione di Google Tag Manager Server Side è una decisione architetturale che influenza raccolta, governance, performance e manutenzione della misurazione. I benefici potenziali includono una maggiore resilienza della raccolta e un controllo più granulare, mentre i rischi principali sono configurazioni errate, costi infrastrutturali sottostimati e gestione errata del consenso.

Per chi gestisce campagne, un'architettura server-side può fornire segnali di misurazione più controllabili. Non sostituisce necessariamente il client side e non garantisce un incremento delle conversioni attribuite: il valore emerge quando raccolta e attribuzione vengono analizzate separatamente rispetto a una fonte di verità come il CRM.

Conviene considerarlo quando:

  • gestisci un ecommerce/lead generation con volumi sufficienti;
  • utilizzi più piattaforme advertising e vuoi centralizzare l'invio;
  • hai bisogno di filtrare o normalizzare i dati e disponi di competenze tecniche per Cloud Run.
     

Potrebbe non essere prioritario quando:

  • il sito genera pochi eventi;
  • il tracciamento è semplice;
  • non ci sono risorse per l'infrastruttura;
  • ci si aspetta (erroneamente) che il server side aggiri automaticamente il consenso.
     

Se il tuo progetto ha bisogno di un'analisi professionale per l'implementazione o di supporto operativo, puoi valutare una consulenza specialistica. Un approccio strutturato all'architettura di misurazione è il primo passo per dati più affidabili.
 

Domande frequenti (FAQ)

Di seguito, alcune domande comuni e risposte sintetiche sull'utilizzo e la configurazione di Google Tag Manager Server Side.
 

Il server side sostituisce completamente il client side?

No. Il client side continua a essere necessario per raccogliere interazioni nel browser, per inizializzare il consenso e per le integrazioni che non dispongono di un percorso server-side. Le architetture ibride sono comuni.
 

Quali costi comporta l'infrastruttura server side?

I costi dipendono da traffico, regione, risorse e istanze (Google raccomanda almeno 2 istanze su Cloud Run). Come riferimento teorico, si stima attualmente circa 45 USD al mese per server, ma è sempre necessario usare il Pricing Calculator e impostare avvisi di budget.
 

Posso utilizzare il server side senza un dominio personalizzato?

Sì, il dominio predefinito run.app funziona, ma Google raccomanda un dominio personalizzato in produzione (same-origin come best practice o sottodominio) per operare in un contesto first-party ottimale.
 

Come gestisco il consenso cookie in un'architettura server side?

Il consenso viene gestito a monte (es. tramite CMP e Consent Mode). Le informazioni sullo stato del consenso accompagnano il flusso al server container, che applica le regole definite. Il server side non sostituisce la gestione del consenso.
 

Il server side migliora automaticamente il posizionamento SEO?

No. Può contribuire indirettamente alla performance riducendo il lavoro del browser, ma l'impatto reale va misurato. Non migliora di per sé i contenuti o la rilevanza per la SEO.
 

Fonti

Vuoi richiedere una consulenza del Team Digital Marketing 2open?
Puoi contattarci senza impegno!

 

Informativa al trattamento dei dati personali ai sensi dell’art. 13 del d.lgs. 196/2003

In ottemperanza agli obblighi previsti dal Decreto Legislativo 30 Giugno 2003 n. 196 in materia di trattamento dei dati personali (codice della privacy) entrato in vigore l’1 Gennaio 2004, con la presente intendiamo informarVi che la società Web Service Internet Solutions S.r.l., con sede a Roma (RM) (di seguito semplicemente "2open”) sottoporrà a trattamento i dati personali che Vi riguardano. Il trattamento dei dati personali sarà effettuato nel rispetto delle norme vigenti ed alle seguenti condizioni.

1. Finalità del trattamento

Il trattamento dei dati personali è diretto esclusivamente al raggiungimento dei seguenti fini:
  1. per esigenze legate alla stipula dei contratti di vendita e degli ordinativi;
  2. per adempiere a ogni tipo di obbligo previsto da leggi o regolamenti vigenti, in particolare, in materia fiscale;
  3. per esigenze di tipo operativo, gestionale e contabile;
  4. per la registrazione degli accessi al sito di 2open e l’utilizzo dei servizi forniti attraverso esso;
  5. per esigenze di monitoraggio dell’andamento delle relazioni con i clienti e per migliorare tali relazioni;
  6. per finalità commerciali e di marketing strategico e operativo.

2. Modalità del trattamento

Il trattamento dei dati potrà consistere nella loro raccolta, nella loro registrazione, conservazione, modificazione, comunicazione, cancellazione, diffusione, ecc. e sarà effettuato sia con l’utilizzo di supporto cartaceo, sia con l’ausilio di strumenti elettronici informatici e telematici, secondo modalità e con strumenti idonei a garantire la sicurezza e la riservatezza dei dati stessi, in conformità con quanto previsto dagli articoli 31 e seguenti del D. Lgs. 196/2003. In particolare, saranno adottate tutte le misure tecniche, informatiche, organizzative, logistiche e procedurali di sicurezza, come previste dal D.Lgs. 196/2003 e ”Allegato B” allo stesso decreto, in modo che sia garantito il livello minimo di protezione dei dati previsto dalla legge.

3. Conferimento dei dati

Il sito di 2open fornisce ai visitatori una serie di servizi senza necessità di richiedere alcun dato o informazione di carattere personale. Tuttavia i servizi riservati ai Clienti richiedono necessariamente il conferimento dei propri dati personali per essere attivati. Se tali dati obbligatori saranno omessi, come del resto in assenza di consenso al trattamento necessario a garantire il servizio richiesto, i servizi non potranno essere erogati in alcun modo. Può accadere inoltre che taluni servizi richiedano la fornitura di dati classificati dal D.Lgs n. 196/03 come “sensibili”, quail “l’appartenenza a categorie protette”, il cui conferimento facoltativo è richiesto per il servizio di raccolta dei “curriculum vitae”. In ogni caso, il conferimento del consenso al trattamento dei dati per l’esecuzione delle attività strettamente necessarie a garantire il regolare svolgimento dei servizi offerti, finalità di cui punto 1.a, 1.b, 1.c, 1.d, è obbligatorio per tutti i dati richiesti. Il consenso alle finalità descritte ai punti 1.e ed 1.f, che nel Vostro interesse vivamente auspichiamo, è invece facoltativo, ed il diniego non comporta alcuna conseguenza pregiudizievole.

4. Comunicazione e diffusione dei dati

La comunicazione all’esterno dei dati personali raccolti per le finalità di cui al punto 1. potrà avvenire solo ove:
  1. tale comunicazione sia obbligatoria per assicurare l'ottemperanza degli adempimenti previsti dalla legge;
  2. tale comunicazione sia obbligatoria per assicurare la corretta instaurazione o prosecuzione del rapporto con Voi intrattenuto.
I dati personali raccolti potranno essere comunicati a soggetti pubblici e privati, persone fisiche e/o giuridiche, aventi finalità commerciali e/o di gestione dei sistemi informativi e/o dei sistemi di pagamento, compresi soggetti esterni che svolgano specifici incarichi per conto di 2open I dati potranno, altresì, essere diffusi, ma solo in forma aggregata, anonima e per finalità statistiche.

5. Trasferimento dei dati all’estero

Nei limiti strettamente necessari all'esecuzione del rapporto con Voi in corso, i Vostri dati personali potranno essere comunicati a soggetti terzi (quali, a titolo di esempio, i fornitori di servizi di connettività) situati all’estero, dentro o fuori l'Unione Europea.

6. Diritti dell’interessato

Ai sensi dell’articolo 7 e seguenti del D. Lgs. 196/2003, Voi avete il diritto di:
  1. ottenere indicazione dell’esistenza, dell’origine, delle finalità e della logica applicata per il trattamento con strumenti elettronici dei dati personali che Vi riguardano;
  2. ottenere indicazioni circa i soggetti o le categorie di soggetti a cui i dati possono essere comunicati o che possono venire a conoscenza degli stessi;
  3. ottenere indicazione circa gli estremi del titolare, dei responsabili e del rappresentante designato al trattamento;
  4. ottenere l’aggiornamento, la rettificazione, l’integrazione, la cancellazione, la trasformazione in forma anonima o il blocco dei dati personali che Vi riguardano;
  5. ottenere l’attestazione che le operazioni al punto b) sono state portate a conoscenza di coloro ai quali i dati sono stati comunicati o diffusi in precedenza;
  6. opporVi, in tutto o in parte al trattamento dei dati che Vi riguardano, previsto ai fini di informazione commerciale, di invio di materiale pubblicitario, di vendita diretta o per il compimento di ricerche di mercato o di comunicazione commerciale.
I diritti che precedono, possono essere esercitati sia direttamente, sia tramite un Vostro incaricato, nelle forme previste dagli artt. 8 e 9 del D.Lgs. 196/2003.

7. Titolare e Responsabile

Il Titolare del trattamento è 2open, in persona dell’Amministratore unico in carica, con sede legale a Roma (RM), 00178, Via Appia Nuova 1083/1087. Il Responsabile del trattamento dei dati che Vi riguardano, domiciliato per questo incarico presso la sede della Società, è il Responsabile della clientela: e-mail: privacy@2open.it.

8. Consenso al trattamento

Come noto, il D.Lgs. 196/2003 prevede che il trattamento dei dati personali sia effettuato con il consenso dell’interessato, salvi i casi di esclusione specificamente indicati dalla legge stessa. Per tale ragione, Vi preghiamo di restituirci firmato l’allegato modulo di richiesta del consenso come attestazione di ricevuta delle informazioni di cui alla presente lettera informativa e come espressione del consenso al trattamento dei dati personali.

I campi contrassegnati dall'asterisco (*) sono obbligatori