Google ha cambiato il modo in cui Google Tag Manager può inviare i dati a GA4, Google Ads e agli altri prodotti Google supportati. Dal 12 ottobre 2026 un container GTM può comunicare direttamente con le destinazioni collegate, evitando in alcuni casi di caricare la libreria Javascript gtag.js come passaggio intermedio. Google indica tra gli effetti una minore quantità di codice eseguito sulla pagina e una gestione più centralizzata delle impostazioni del tagging.
Per chi utilizza GTM da anni, però, la parte interessante va oltre l’ottimizzazione delle performance.
Sta cambiando il modo in cui Google organizza il rapporto tra container, configurazione del tag e prodotti che ricevono i dati.
Fino a oggi siamo stati abituati a ragionare soprattutto sui tag presenti dentro GTM: Google tag, eventi GA4, conversioni Google Ads, Conversion Linker e così via.
Con il nuovo modello entra in modo molto più evidente il concetto di Destination, cioè il prodotto Google al quale il container deve inviare i dati.
Questo rende più leggibile l’architettura, ma richiede anche di capire bene cosa sia stato effettivamente unificato. GA4, Google Ads e gli altri prodotti continuano infatti a utilizzare quei dati secondo le proprie regole.
Il cambiamento vero riguarda il percorso del dato
In una configurazione GTM tradizionale, Google Tag Manager gestiva trigger, variabili ed eventi, mentre il Google tag forniva il livello necessario per comunicare con le destinazioni Google.
Con l’aggiornamento dei container questo passaggio può diventare più diretto.
Google spiega che, dopo l’ottimizzazione, Tag Manager può inviare direttamente i dati alle destinazioni Google collegate. Nelle configurazioni precedenti GTM caricava invece ulteriore JavaScript tramite gtag.js, con una possibile latenza aggiuntiva nella trasmissione dei dati.
Questo aggiornamento fa parte di un cambiamento iniziato già da tempo.
Il tag di configurazione GA4 era stato sostituito dal Google tag, che permetteva di condividere alcune impostazioni tra prodotti diversi. Adesso Google sta avvicinando ulteriormente Google tag e Google Tag Manager: i Google tag vengono progressivamente aggiornati per acquisire le funzionalità di un container GTM, comprese interfaccia di gestione, debug e versioning.
Per chi lavora sul tracking significa che il container diventa sempre più il punto centrale da cui governare l’invio dei dati verso Google.
La parte a monte rimane sostanzialmente la stessa.
Se un sito espone nel data layer un acquisto, la compilazione corretta di un form o un’altra interazione significativa, GTM continua a dover leggere quell’informazione e decidere cosa farne.
Il cambiamento riguarda soprattutto ciò che succede dopo.
Con le Destinations diventa più chiaro dove vengono inviati i dati
La nuova sezione Settings di Google Tag Manager mostra le Google destinations collegate al container e le configurazioni associate.
La documentazione attuale prevede destination tag per Google Analytics, Google Ads, Floodlight e Merchant Center.
Questo cambia anche il modo in cui conviene leggere un container durante un audit.
Controllare l’elenco dei tag rimane necessario, ma adesso bisogna verificare anche quali destinazioni siano effettivamente collegate e quali impostazioni vengano applicate a ciascuna di esse.
Google permette infatti di gestire dalla nuova area Settings diverse configurazioni che possono influire sulle destinazioni direttamente collegate al container, compresi rilevamento automatico degli eventi, cross-domain, gestione del consenso e raccolta di dati forniti dagli utenti.
Prendiamo un caso semplice: un sito lead generation inserisce nel dataLayer un evento quando un form viene inviato correttamente:
dataLayer.push({
event: "generate_lead",
form_name: "Richiesta preventivo"
});
Quel segnale può essere utilizzato per generare un evento in Google Analytics e una conversione in Google Ads.
L’origine del dato può quindi essere comune.
Analytics continuerà però a usare quell’informazione per le proprie analisi, mentre Google Ads potrà utilizzarla per attribuire conversioni alle campagne e alimentare i propri sistemi di ottimizzazione.
Questa distinzione rimane importante anche con il nuovo modello.
GA4 e Google Ads continuano a richiedere scelte diverse
Una gestione più centralizzata del tagging potrebbe far pensare che diventi meno importante distinguere ciò che inviamo a GA4 da ciò che utilizziamo in Google Ads.
In realtà conviene mantenere questa distinzione, anche mentalmente.
Un evento valido per l’analisi del comportamento degli utenti non deve necessariamente diventare una conversione utilizzata dalle campagne.
Pensiamo, per esempio, al download di una brochure.
In GA4 può avere senso raccoglierlo per capire come gli utenti interagiscono con il sito.
In Google Ads, invece, utilizzarlo come conversione primaria richiede una valutazione diversa: se quel download rappresenta un segnale molto debole rispetto a una richiesta commerciale, far ottimizzare le campagne su quell’azione può indirizzare l’algoritmo verso utenti che scaricano documenti ma non generano opportunità reali.
Il fatto che entrambi i dati passino dallo stesso container non rende equivalenti gli obiettivi delle due piattaforme.
Lo stesso vale per le informazioni fornite dagli utenti.
La nuova area Settings può governare anche l’invio di user-provided data alle destinazioni compatibili. Google specifica che questi dati vengono sottoposti ad hashing prima dell’invio ai prodotti configurati per riceverli.
Questo si collega direttamente alle Enhanced Conversions di Google Ads e ad altre funzioni che utilizzano email, telefono o altri identificativi per migliorare il matching.
La centralizzazione della configurazione semplifica una parte del lavoro, mentre qualità, normalizzazione e corretto momento di raccolta di quei dati rimangono responsabilità dell’implementazione.
Se un telefono arriva nel formato sbagliato oppure un form viene considerato convertito al click sul pulsante anziché dopo l’invio effettivo, la nuova architettura non corregge il dato.
Il Conversion Linker è uno dei punti da controllare
Il cambiamento produce una conseguenza pratica molto evidente sul Conversion Linker.
Questo tag serve a conservare le informazioni associate al click pubblicitario, per esempio quelle necessarie a collegare una conversione successiva al click che ha portato l’utente sul sito.
Per anni una configurazione molto comune in Google Tag Manager ha previsto un Conversion Linker separato insieme ai tag di conversione Google Ads.
La documentazione aggiornata di Google specifica che, se il container carica su tutte le pagine un Google tag o un Destination tag per la destinazione interessata, non serve avere anche un Conversion Linker separato.
Google aggiunge anche che un container contenente tag Google Ads o Floodlight può caricare automaticamente un Google tag prima dell’invio degli eventi quando non trova una Destination già collegata.
È quindi possibile che in molti container il Conversion Linker diventi ridondante.
Questo non giustifica però una rimozione automatica dai container esistenti.
Un setup può utilizzare configurazioni personalizzate dei cookie oppure gestire il cross-domain attraverso il linker.
In questi casi bisogna prima ricostruire come funziona oggi il tracciamento e capire quali impostazioni verrebbero assorbite dalla nuova configurazione.
Il controllo che farei è molto semplice: verificare la Destination associata a Google Ads, controllare dove viene caricata e confrontare quella configurazione con ciò che fa attualmente il Conversion Linker.
Solo dopo ha senso decidere se il tag può essere eliminato.
Prima di ottimizzare un container, controllerei come funziona oggi
Google raccomanda l’ottimizzazione dei container GTM, ma specifica che la modifica non viene applicata automaticamente. Chi dispone dei permessi necessari può avviare il processo dal banner presente nel container e verificare le modifiche prima di pubblicarle.
Su un container nuovo la scelta può essere abbastanza lineare.
Su un container in produzione da anni preferirei invece approfittare dell’aggiornamento per controllare ciò che si è accumulato nel tempo.
Guarderei almeno questi aspetti:
- Google tag e Destination già presenti, verificando quali prodotti ricevono effettivamente i dati e attraverso quale configurazione.
- Conversion Linker e cross-domain, soprattutto quando sono presenti impostazioni personalizzate o più domini coinvolti nel percorso di conversione.
- Consent Mode e user-provided data, perché le nuove impostazioni centralizzate possono incidere sul comportamento delle destinazioni collegate.
- Configurazioni server-side, compreso l’utilizzo di
server_container_url, per evitare di modificare involontariamente il percorso degli eventi verso il server container. - Trigger Custom Event molto generici, che meritano un controllo anche per un’altra modifica rilasciata da Google in questi giorni.
- Hardcoded gtag(‘config’) da rimuovere in quanto non più supportati
Questi ultimi due punti riguardano l’aggiornamento dell’8 ottobre 2026. A partire da questa data, Google ha standardizzato il comportamento dei comandi gtag('config') nei siti che utilizzano Google Tag Manager. Da ora questi comandi possono comparire nel dataLayer come eventi gtag.config, e questo ha almeno due conseguenze operative da verificare.
La prima riguarda i Custom Event trigger configurati con wildcard o espressioni regolari troppo ampie. Un trigger che intercetta, per esempio, qualsiasi evento tramite .* può attivarsi anche quando compare gtag.config. In un container complesso questo può tradursi in tag che partono una volta in più e, nei casi peggiori, in conversioni duplicate.
Conviene quindi controllare i trigger Custom Event e sostituire, quando possibile, le wildcard con i nomi reali degli eventi che devono attivare il tag. Se non è possibile intervenire subito sulla logica del trigger, una misura temporanea può essere escludere esplicitamente l’evento gtag.config.
La seconda verifica riguarda le implementazioni ibride più vecchie, in cui sulla pagina è presente lo snippet GTM ma viene aggiunto a mano anche un comando come:gtag('config', 'AW-XXXXXXXXX');
senza che sia presente il relativo snippet gtag.js.
Google classifica oggi questa configurazione come unsupported. In passato GTM poteva comunque intercettare quel comando e caricare il tag necessario, ma questo comportamento non va più considerato affidabile. La soluzione corretta consiste nel gestire quel Google tag direttamente dentro GTM oppure utilizzare il relativo snippet gtag.js completo sulle pagine.
Il controllo è abbastanza semplice: nel codice sorgente della pagina si può cercare gtag('config' e verificare se è presente anche il relativo caricamento di gtag/js?id=.... In GTM conviene invece controllare i trigger Custom Event che utilizzano regex o wildcard. Quando l’aggiornamento è attivo sul sito, l’evento gtag.config compare anche nella timeline di Preview.
Google sta ancora distribuendo progressivamente questo comportamento, quindi può capitare che su alcuni container l’evento non sia ancora visibile.
Conclusioni: il container diventa più centrale, il dato rimane il punto da cui partire
La direzione presa da Google rende Google Tag Manager sempre più simile a un sistema centrale di distribuzione dei dati verso i propri prodotti.
Questa semplificazione può rendere più ordinata la configurazione e ridurre alcuni passaggi tecnici.
Per chi si occupa di tracking, però, la parte più importante continua a trovarsi prima delle Destinations.
Se un ecommerce invia purchase due volte, le piattaforme riceveranno due acquisti.
Se un form viene tracciato sul click anche quando la validazione fallisce, Google Ads riceverà una conversione che non corrisponde a un lead.
Se il consenso viene interpretato male, alcuni dati possono essere inviati in condizioni diverse da quelle previste.
Una Destination configurata bene distribuisce ciò che riceve. La qualità della misurazione dipende ancora da come abbiamo deciso di generare quei dati e da quanto sono affidabili gli eventi che arrivano a GTM.
È questo il criterio che userei anche per affrontare l’aggiornamento dei container esistenti.
Prima ricostruirei il percorso dei dati e verificherei eventuali duplicazioni o configurazioni obsolete. A quel punto la nuova architettura di Google può essere utilizzata per semplificare il setup senza perdere il controllo di ciò che viene effettivamente inviato alle piattaforme.
FAQ su Google tag e Google Tag Manager
Google sta facendo convergere progressivamente i due sistemi. I Google tag vengono aggiornati per acquisire le funzionalità dei container Google Tag Manager, mentre GTM può gestire direttamente le destinazioni Google collegate. Google specifica comunque che ogni destinazione mantiene il proprio tag e le configurazioni esistenti.
Lo stesso evento presente nel data layer può essere utilizzato per inviare dati a entrambe le piattaforme, ma GA4 e Google Ads continuano a elaborarli secondo configurazioni e finalità proprie. Un evento raccolto in Analytics, per esempio, non deve necessariamente diventare una conversione utilizzata per ottimizzare le campagne.
Un data layer correttamente progettato non richiede modifiche a causa della nuova architettura. Eventi e parametri continuano a descrivere ciò che accade sul sito, mentre GTM decide come utilizzare quelle informazioni e a quali piattaforme inviarle.
Google indica che un Conversion Linker separato non è necessario quando il container carica su tutte le pagine un Google tag o un Destination tag appropriato. Prima di rimuoverlo bisogna comunque controllare l’implementazione esistente, in particolare eventuali configurazioni cross-domain o personalizzazioni dei cookie.
Google raccomanda l’ottimizzazione, ma non la applica automaticamente. Su container già in produzione conviene prima verificare destinazioni, Conversion Linker, Consent Mode, configurazioni server-side e trigger potenzialmente interessati dagli aggiornamenti recenti. Le modifiche proposte dal processo di ottimizzazione possono essere controllate prima della pubblicazione.
Hai un container GTM da rivedere prima di ottimizzarlo?
Posso verificare la configurazione attuale di Google Tag Manager, Destinations, Conversion Linker, Consent Mode e tracciamenti server-side, per capire cosa conviene modificare e cosa invece è meglio lasciare invariato.