Google Tag Gateway: quanto recupera davvero e quando conviene

Perché stai perdendo dati (e chi te li sta bloccando)

Google Tag Gateway: partiamo dall’inizio. Quando un utente apre il tuo sito, il browser scarica gli script di Google (gtag.js, il container di Google Tag Manager) da domini come googletagmanager.com, e invia i dati a google-analytics.com. Il problema è che questi domini sono noti, e questo li rende un bersaglio facile.

Cerchiamo di capire in che senso. Partiamo dagli ad blocker.

Gli ad blocker: la richiesta non parte

Un ad blocker è uno strumento come uBlock Origin o AdBlock Plus, che si occupa di fermare i tracker. Lo fa in diversi modi, tra cui tenere una lista di domini di tracciamento noti che vengono bloccati a priori.

Se googletagmanager.com è in quella lista, la richiesta non parte proprio: niente script, niente evento, niente conversione registrata.

Safari e ITP: il cookie non dura

Safari è il browser che ha dato più filo da torcere a chi misura. Con la sua Intelligent Tracking Prevention (ITP) tratta con sospetto i cookie first-party scritti via JavaScript e ne accorcia drasticamente la durata:

Qui non perdi l’evento, perdi la memoria. Lo stesso utente che torna dopo qualche giorno viene contato come nuovo, e l’attribuzione salta.

Tieni a mente la differenza, perché torna utile più avanti: l’ad blocker ti toglie la richiesta, ITP ti toglie la continuità. Sono due problemi diversi, e il tag gateway li affronta in modo molto diverso.

L’effetto combinato è una fetta di dati che manca senza farsi notare: i numeri nei report ci sono e sembrano sensati, sono solo più bassi della realtà.

Cos’è il Google Tag Gateway: i tag serviti dal tuo dominio

Il Google Tag Gateway cambia una cosa sola, ma decisiva: da dove vengono serviti i tag. Come spiega la documentazione ufficiale di Google:

Il gateway del tag Google per gli inserzionisti carica il tag dal tuo dominio e invia gli eventi di misurazione al tuo dominio, dove vengono inoltrati a Google.

Immagina che le richieste di tracciamento siano lettere. Oggi le spedisci in una busta con stampato sopra a caratteri cubitali “GOOGLE ANALYTICS”: chiunque al controllo (l’ad blocker, il browser) la nota e la cestina.

Il tag gateway rimette le stesse lettere in una busta con il tuo indirizzo, cioè il tuo dominio. Per chi controlla è posta interna del sito, non traffico verso un tracker esterno. E quindi passa.

Come funziona, in concreto

Tre elementi, niente di più:

• Un percorso dedicato sul tuo dominio, per esempio tuosito.com/a8f3k2.
• Una CDN (o un load balancer, o il tuo web server) che gestisce quel percorso e inoltra le richieste ai server di Google dietro le quinte.
• Il browser e gli ad blocker vedono una richiesta first-party interna, non un tracciamento verso l’esterno.

Un dettaglio che fa la differenza: non chiamare quel percorso /tracking o /analytics. Gli ad blocker più sofisticati riconoscono anche questi pattern nel nome, quindi meglio una stringa neutra e poco riconoscibile.

Per verificare che funzioni, apri la scheda Network degli strumenti per sviluppatori del browser e controlla che gli script si carichino dal tuo dominio e non più da googletagmanager.com.

Quanto recupera davvero: l’11% e da dove arriva

Intorno al Google Tag Gateway girano aspettative gonfiate, quindi mettiamo i numeri in fila.

Google dichiara un miglioramento mediano dell’11% nei segnali di misurazione. Per qualcosa di completamente gratuito, è un guadagno tutt’altro che banale.

Ma attenzione a da dove arriva questo recupero. Il grosso dell’uplift non viene dall’eludere gli ad blocker: viene dal far durare di più i cookie, aggirando i tagli di ITP.

Il motivo sta nel dettaglio di prima. ITP accorcia la vita dei cookie di advertising scritti via JavaScript: quando le richieste passano dal tuo dominio, il cookie può essere impostato dalla risposta del server e non dal browser, quindi non ricade nello stesso taglio.

C’è poi un motivo più sottile, ed è il punto in cui il tag gateway fa meglio del server-side su sottodominio. Con il gateway lo script che imposta il cookie sta dietro il proxy del tuo sito, quindi risponde dallo stesso indirizzo IP del dominio: per Safari è indistinguibile dal sito stesso, e il cookie mantiene la sua durata. Con un container server mappato su un sottodominio via CNAME, invece, dietro c’è un indirizzo diverso, e ITP ha modo di accorgersene e il taglio torna ad applicarsi.

Contro gli ad blocker più evoluti, invece, il tag gateway non è una bacchetta magica: aiuta, ma non li bypassa in modo affidabile. Inquadralo per quello che è: un miglioramento incrementale e misurabile, non un interruttore che ti restituisce il 100% dei dati.

Tag gateway o server-side tagging: come scegliere

È la confusione più comune. “Ma quindi è il server-side?” No, e capire la differenza ti evita scelte sbagliate.

Il Google Tag Gateway è un proxy: reindirizza il traffico dei tag di Google attraverso il tuo dominio first-party. Non c’è trasformazione dei dati, non c’è logica personalizzata. È un reindirizzamento, punto.

Il server-side tagging (sGTM) è un’altra cosa: un vero server che controlli tu, che riceve gli eventi, li trasforma e li arricchisce, e li distribuisce a più piattaforme (Google, ma anche Meta, TikTok, LinkedIn). È più potente, ma ha costi di hosting e una complessità di gestione superiori.

Nella pratica si sceglie l’una o l’altra. Per l’ecosistema Google coprono lo stesso bisogno, cioè portare la raccolta dati sul tuo dominio, quindi attivarle entrambe significa duplicare la stessa funzione. È una decisione da prendere una volta sola.

Il tag gateway probabilmente ti basta se

• Vuoi recuperare i dati persi per ad blocker e ITP con il minimo sforzo e a costo zero.
• Lavori essenzialmente con l’ecosistema Google (GA4, Google Ads).
• Non hai bisogno di manipolare i dati o di inviarli a piattaforme non-Google lato server.

Ti serve il server-side se

• Devi arricchire o ripulire i dati prima di mandarli, per esempio per le Enhanced Conversions o per la Meta CAPI lato server.
• Invii eventi a più piattaforme e vuoi orchestrarli da un punto solo.
• Hai requisiti stringenti su cosa esce dal browser e dove finisce.

Su Shopify il tag gateway non puoi attivarlo

È il caso concreto che spiazza di più. Shopify usa Cloudflare, quindi verrebbe da pensare di attivare il Google Tag Gateway con la comoda integrazione Cloudflare in un clic. Non funziona così.

L’integrazione Cloudflare del tag gateway richiede di controllare la zona Cloudflare del tuo dominio, ma su Shopify quella zona è gestita da Shopify: non hai accesso alla sua configurazione, e Shopify non ti consente di creare un reverse proxy su un percorso del dominio (del tipo tuosito.com/gtg/). Il fatto che “sotto” giri Cloudflare, insomma, non ti dà le chiavi per usarlo.

La strada percorribile su Shopify è il server-side tagging con un dominio personalizzato. Dato che il setup “stesso dominio” non è possibile, si mappa un sottodominio (per esempio sgtm.tuosito.com) tramite record CNAME verso il container server, come descrive la documentazione ufficiale di Google sul dominio personalizzato.

Con una premessa da tenere presente: il sottodominio mappato via CNAME è proprio la configurazione che ITP riesce a distinguere, quindi sui cookie non ottieni la stessa resistenza del gateway. Su Shopify, insomma, non scegli fra due opzioni: prendi l’unica praticabile, il server-side, sapendo cosa ci lasci per strada.

Come attivarlo: i provider supportati

L’attivazione parte dalle impostazioni del tuo tag Google, raggiungibili da Google Ads, Google Analytics, Campaign Manager 360 o Google Tag Manager: lì trovi la voce “Gateway del tag Google”. Il prerequisito è avere già un tag Google attivo sul sito (un G-, un AW- e così via).

Da lì le strade dipendono dalla tua infrastruttura. Oggi le opzioni supportate sono:

• Cloudflare: la via più semplice, con integrazione diretta nell’interfaccia. Si attiva in pochi minuti autenticandosi con l’account Cloudflare.
• Amazon CloudFront (AWS): da giugno 2026 Google ha aggiunto un flusso guidato dentro Tag Assistant (https://support.google.com/tagmanager/answer/17133552?hl=it) che ti accompagna passo passo nella console AWS. Per chi è su AWS è una grossa semplificazione.
• Akamai e Fastly: integrazioni ufficiali per chi usa queste CDN.
• Google Cloud Platform: tramite External Application Load Balancer.
• CDN o web server generici: configurazione manuale, per chi ha competenze tecniche e vuole il controllo completo. I dettagli stanno nella documentazione per sviluppatori di Google Tag Manager (https://developers.google.com/tag-platform/tag-manager/gateway?hl=it).

Prima di andare live: il consenso resta obbligatorio

Un equivoco pericoloso: il Google Tag Gateway non ti esonera dal consenso. Recuperare dati bloccati non significa poterli raccogliere senza base giuridica. Il tag gateway rispetta il Consent Mode v2 e le normative europee (DMA), ma a una condizione: che l’architettura sia impostata bene.

Il nodo è di tempistica. Il Consent Mode richiede che l’informazione sul consenso arrivi prima che i tag elaborino i dati, come spiega la documentazione di Google sul consenso (https://developers.google.com/tag-platform/security/guides/consent?hl=it). Se la CMP si carica dopo i tag, i segnali di consenso arrivano tardi e rischi di raccogliere dati prima del dovuto.

La buona pratica resta gestire la Consent Management Platform e i tag dentro Google Tag Manager, così che il consenso di default sia impostato prima che inizi qualsiasi raccolta. Se vuoi il quadro completo, trovi tutto in “Consent Mode v2: cosa sta succedendo?“.

Domande frequenti sul Google Tag Gateway

Il Google Tag Gateway è gratuito?

Sì, il servizio è gratuito. Restano gli eventuali costi della CDN o dell’infrastruttura che usi per servire il percorso sul tuo dominio.

Il tag gateway sostituisce il server-side tagging?

No. Il gateway è un proxy che serve i tag di Google dal tuo dominio, il server-side tagging è un server che controlli tu e che elabora e instrada gli eventi verso più piattaforme. Nella pratica si sceglie l’uno o l’altro, perché per l’ecosistema Google coprono lo stesso bisogno.

Quanti dati si recuperano con il Google Tag Gateway?

Google dichiara un miglioramento mediano dell’11% nei segnali di misurazione. Il grosso di quel recupero arriva dalla maggiore durata dei cookie, non dall’aggirare gli ad blocker.

Si può usare il Google Tag Gateway su Shopify?

No, non con l’integrazione Cloudflare: su Shopify la zona Cloudflare è gestita da Shopify e non puoi creare un reverse proxy su un percorso del dominio. La strada percorribile è il server-side tagging con un sottodominio personalizzato.

Con il tag gateway serve ancora il Consent Mode?

Sì. Il tag gateway non incide sulla base giuridica della raccolta: il Consent Mode v2 va gestito come prima, assicurandosi che il segnale di consenso arrivi prima che i tag elaborino i dati.

Considerazioni finali: quando il tag gateway è la mossa giusta

Il Google Tag Gateway risponde a un problema concreto e crescente, i dati che non arrivano, con una mossa semplice: servire i tag dal tuo dominio. Per molti siti è il modo più rapido ed economico per recuperare misurazioni che oggi stanno semplicemente sparendo, e con il supporto a Cloudflare, AWS, Akamai e Fastly l’attivazione è ormai alla portata di quasi tutte le infrastrutture.

L’importante è inquadrarlo bene: è una soluzione di consegna gratuita e leggera, alternativa al server-side, e comunque dentro le regole del consenso. Se sei su Shopify, la decisione l’hai già presa: server-side con sottodominio dedicato.

Se vuoi approfondire i temi vicini, dai un’occhiata anche a Novità nel monitoraggio web: il nuovo Google Tag.