Il Google Tag Gateway è un proxy first-party che Google mette a disposizione per rendere più affidabile la misurazione di GA4 e Google Ads, senza dover costruire un’infrastruttura server-side completa.
Hai mai notato questo banner in cima al tuo workspace di un container su Google Tag Manager?
Probabilmente sì, se utilizzi una CDN come Cloudflare. Se però hai avuto dubbi se attivarlo o meno, questo articolo cercherà di fare chiarezza.
Il Google Tag Gateway (GTG) è un servizio Google che permette di servire e ricevere i tag di misurazione — GA4, Google Ads e Floodlight — direttamente dal dominio del sito, invece che da domini Google. In pratica, cambia solo da dove i tag vengono richiesti e serviti, rendendo la comunicazione “first-party”: per il browser, la richiesta sembra rivolta al sito stesso e non a un dominio terzo, il che la rende più resistente ad ad blocker e alle restrizioni sui cookie di terze parti come l’Intelligent Tracking Prevention di Safari.
È importante chiarire fin da subito un equivoco comune: il GTG non è un vero server-side tagging. Non fornisce un container dove intercettare, modificare o instradare gli eventi verso altre piattaforme: è un’integrazione tra Google e la CDN, pensata per irrobustire la misurazione esistente con un intervento leggero, non per governare l’intera architettura di tracciamento.
Come funziona Google Tag Gateway?
Il funzionamento si basa sulla CDN del sito. Quando un tag Google (per esempio gtag.js o il tag di conversione Ads) viene caricato, invece di puntare a un dominio Google viene richiesto a un sottodominio del sito stesso. La CDN riconosce queste richieste e le inoltra ai server Google in modo trasparente, restituendo la risposta come se provenisse dal dominio proprietario.
Attivazione
- Con CDN integrate (Cloudflare, Akamai, Fastly): attivazione one-click, spesso disponibile direttamente dal pannello della CDN o da Google Tag Manager.
- Senza CDN integrate: richiede una configurazione manuale di routing e header sul dominio, più simile a un setup da agenzia tecnica.
Un esempio pratico: le chiamate prima e dopo
Il modo più chiaro per capire cosa cambia davvero è guardare da dove partono le richieste di rete verso i server di misurazione, prima e dopo l’attivazione del GTG.
GET https://www.google-analytics.com/g/collect?v=2&tid=G-XXXXXXX&...
GET https://googletagmanager.com/gtag/js?id=G-XXXXXXX
GET https://googleads.g.doubleclick.net/pagead/viewthroughconversion/...Il browser vede chiaramente richieste verso domini Google di terze parti: gli ad blocker e l’ITP di Safari le riconoscono come tali e possono bloccarle o limitarne fortemente la durata dei cookie.
GET https://www.tuosito.it/gtg/collect?v=2&tid=G-XXXXXXX&...
GET https://www.tuosito.it/gtg/gtag/js?id=G-XXXXXXX
GET https://www.tuosito.it/gtg/pagead/viewthroughconversion/...Stessa richiesta, stesso payload verso Google — ma agli occhi del browser parte tutto dal dominio del sito. La CDN si occupa di inoltrarla a Google in modo trasparente e di restituire la risposta come se arrivasse dal proprio server.
E i tag non Google, come Meta?Il Google Tag Gateway agisce esclusivamente sui tag Google (GA4, Ads, Floodlight). Una chiamata al Meta Pixel continua a essere fatta così com’è, senza alcuna modifica:
GET https:///tr?id=XXXXXXXXXX&ev=PageView&...
GET https:///en_US/fbevents.jsAttivare il GTG non estende alcun beneficio a Meta, TikTok, LinkedIn o a qualunque altra piattaforma non-Google: quelle richieste restano dirette ai domini di terze parti originali, con tutte le limitazioni che ITP e ad blocker applicano già oggi. Per portare anche il Pixel di Meta “dietro” il proprio dominio serve un vero server-side tagging (come un container Stape), che intercetti e re-inoltri anche quegli eventi.
Vantaggi principali del Google Tag Gateway
- Comunicazione first-party: i tag vengono richiesti dal dominio del sito, non da un dominio Google terzo.
- Migliore raccolta dei segnali di conversione: Google dichiara un miglioramento medio dell’11% nella raccolta dei segnali.
- Setup rapido: nessuna infrastruttura server da mantenere, a differenza di un container server-side tradizionale.
- Nessun costo diretto: è un servizio incluso, gestito da Google.
Cosa il Google Tag Gateway non fa
- Non sostituisce una Consent Management Platform (CMP) e non determina la base giuridica del trattamento dei dati.
- Non elabora, filtra, arricchisce o instrada i dati verso piattaforme diverse da GA4, Google Ads e Floodlight.
- Non offre un container dove poter intervenire sulla logica di raccolta.
- Da solo, su un setup client-side puro, non estende la durata dei cookie limitata dall’ITP di Safari.
Le attuali politiche dei browser su cookie first-party e third-party
Per capire perché un proxy first-party come il GTG ha senso, è utile guardare a cosa fanno oggi i principali browser con i cookie. Il quadro nel 2026 è piuttosto frammentato: ogni browser ha adottato un approccio diverso, e non è più vero (come si ipotizzava qualche anno fa) che tutti convergeranno verso lo stesso blocco totale dei cookie di terze parti.
Safari e Intelligent Tracking Prevention (ITP)
Safari resta il browser più restrittivo. L’Intelligent Tracking Prevention blocca integralmente i cookie di terze parti e impone limiti stringenti anche a quelli di prima parte:
- Cookie first-party impostati via JavaScript (
document.cookie): scadono dopo 7 giorni di inattività dell’utente sul sito. - Cookie first-party impostati via header HTTP (
Set-Cookiedal server): non hanno limiti di scadenza imposti da ITP, a meno che il dominio venga classificato come CNAME cloaking, cioè un sottodominio che punta di fatto a un’infrastruttura di tracciamento di terze parti mascherata da first-party. - Landing page con parametri di tracciamento nell’URL (
gclid,fbclid…): se Safari rileva questi parametri, il cookie impostato su quella pagina viene limitato a sole 24 ore, indipendentemente da come è stato impostato.
È proprio questo il motivo per cui un server-side tagging con custom domain reale (come Stape) resta rilevante su Safari: impostando i cookie via header HTTP da un’infrastruttura effettivamente riconducibile allo stesso IP/dominio del sito, si evita il tetto dei 7 giorni. Il GTG da solo, essendo un proxy e non un vero server applicativo, non garantisce automaticamente questo comportamento.
Chrome: cookie di terze parti ancora attivi, ma in bilico
Dopo anni di annunci, Google ha abbandonato ufficialmente il piano di eliminazione dei cookie di terze parti: il progetto Privacy Sandbox è stato chiuso nell’ottobre 2025 e Chrome mantiene tuttora i cookie di terze parti attivi di default, con la possibilità per l’utente di disattivarli manualmente dalle impostazioni di privacy. Non è quindi previsto un blocco totale imminente, ma una quota crescente di utenti sceglie autonomamente di disattivarli, per cui affidarsi esclusivamente ai cookie di terze parti resta una strategia sempre meno affidabile anche su Chrome.
Firefox e Brave: blocco già attivo
Firefox, con la Total Cookie Protection, isola (“partiziona”) ogni cookie per sito visitato, rendendo di fatto inutilizzabile il tracciamento cross-site anche quando un cookie tecnicamente non viene bloccato. Brave blocca i cookie di terze parti in modo integrale e per impostazione predefinita. Insieme, Safari, Firefox e Brave coprono una quota significativa del traffico globale già oggi cookieless per i cookie di terze parti, indipendentemente dalle scelte di Chrome.
Cosa significa in pratica
GTG e server-side tagging: soluzioni complementari
Google Tag Gateway e un container server-side (ad esempio su Stape) non sono alternative in competizione, ma tecnologie pensate per risolvere problemi diversi e, secondo le indicazioni ufficiali di Google, possono essere combinate: la CDN, tramite il GTG, pubblica gli script direttamente dal dominio proprietario, mentre il container server-side separato gestisce la raccolta, l’arricchimento e la distribuzione dei dati verso le varie piattaforme.
No: il GTG copre esclusivamente i prodotti Google (GA4, Google Ads, Floodlight). Per inviare dati a piattaforme non-Google è necessario un setup server-side dedicato.
Nella maggior parte dei casi no, se il sito è servito da una CDN con integrazione nativa: l’attivazione avviene a livello di configurazione, senza toccare gli script di tracciamento già presenti.
Sì, il GTG resta subordinato al Consent Mode: non modifica in alcun modo le preferenze di consenso espresse dall’utente né la base giuridica del trattamento.
