Google Tag Manager cambia nel 2026: meno codice, più controllo. Ma il tracking va ripensato?

Google ha introdotto una nuova fase nell’evoluzione di Google Tag Manager e del tag Google: il contenitore può comunicare più direttamente con alcune destinazioni Google, le impostazioni diventano più centralizzate e una parte della configurazione delle conversioni si avvicina a un’esperienza visiva.

È una novità rilevante per chi segue pubblicità, analytics ed e-commerce. Ma la lettura più interessante, a mio avviso, non riguarda soltanto qualche richiesta JavaScript in meno. Riguarda il modo in cui un’impresa progetta, controlla e interpreta ciò che misura.

La domanda, quindi, non è «dobbiamo aggiornare tutto?». È più utile chiederci: quali dati stiamo raccogliendo, perché li raccogliamo e quanto possiamo fidarci delle decisioni che ne derivano?

Ottobre 2026: che cosa ha annunciato Google

Le date aiutano a separare la notizia dalle interpretazioni. L’8 ottobre 2026 Google ha pubblicato una modifica al comportamento dei comandi gtag('config') in relazione ai container Tag Manager. Il 12 ottobre ha annunciato la disponibilità della nuova capacità di ottimizzazione dei contenitori, che consente di inviare dati direttamente alle destinazioni Google supportate, senza il precedente passaggio necessario attraverso JavaScript aggiuntivo in determinate configurazioni.

La trasformazione è parte di un percorso più ampio, avviato nel corso del 2026: una nuova organizzazione dell’interfaccia, l’avvicinamento tra tag Google e GTM, una gestione più unificata delle destinazioni e strumenti guidati per creare eventi di conversione.

Sono novità documentate nelle note di rilascio ufficiali di Google Tag Manager e nella pagina Google dedicata agli aggiornamenti al tag Google e a Google Tag Manager.

🔎 Attenzione alla parola “aggiornamento”: nel caso dei contenitori GTM esistenti, Google specifica che l’ottimizzazione non viene applicata automaticamente. È una procedura da esaminare, avviare e pubblicare dopo le opportune verifiche.

Prima e dopo: cosa cambia davvero nel percorso dei dati

Fino a questa evoluzione, in numerose implementazioni il contenitore web di GTM caricava anche il codice gtag.js per inviare informazioni a una destinazione Google. Questo introduceva un ulteriore livello di JavaScript, con possibili costi in termini di caricamento e tempi di trasmissione dei segnali.

Con la nuova architettura, un contenitore ottimizzato può inviare dati direttamente alle destinazioni Google supportate. Il vantaggio potenziale è ridurre una parte delle dipendenze e concentrare le impostazioni in un unico luogo.

Il beneficio, tuttavia, va descritto correttamente: non significa eliminare GTM dalla pagina, non significa eliminare qualunque script di misurazione e non significa trasformare automaticamente il tracking in server-side. Il comportamento concreto dipende dal contenitore, dai tag presenti, dalle destinazioni e dalla modalità di implementazione.

Google parla di miglioramento del rendimento. Io aggiungerei un criterio operativo: misurare prima e dopo. Non basta presumere che un aggiornamento riduca il tempo di caricamento; bisogna verificare richieste di rete, tempi di invio, quantità e qualità degli eventi, e comportamento dei principali percorsi utente.

Una nuova regia: Impostazioni, destinazioni e autorizzazioni

La nuova organizzazione di Google Tag Manager rende più visibile il rapporto fra il contenitore e gli strumenti che ricevono i dati.

Nella pagina Panoramica compaiono le sezioni Impostazioni e Avanzate. La prima centralizza gli aspetti che riguardano l’intero contenitore e le destinazioni collegate; la seconda raccoglie funzioni come trigger, variabili, modelli e cartelle.

L’ottimizzazione porta le configurazioni dei tag Google nella sezione Impostazioni, con una mappa dei flussi verso le relative destinazioni. Google precisa inoltre che i collegamenti agli account di destinazione vengono creati nel corso della procedura e ricevono inizialmente l’accesso in lettura, modificabile tramite la gestione degli utenti.

È un cambiamento meno spettacolare di un nuovo algoritmo, ma per chi gestisce più proprietà e account può essere significativo. In molte aziende la misurazione è cresciuta per aggiunte successive: una proprietà GA4, un account Google Ads, una seconda conversione, un plugin, uno script legacy, un’agenzia che subentra a un’altra.

Quando ogni componente ha impostazioni e autorizzazioni separate, il rischio non è soltanto perdere tempo: è non sapere con precisione chi controlla quale parte della raccolta dati. Centralizzare aiuta, purché la configurazione venga documentata e governata.

Il dettaglio dell’8 ottobre che può sfuggire: gli eventi gtag.config

C’è una modifica particolarmente importante per gli specialisti. Google ha standardizzato l’inizializzazione dei container gtm.js: i container si inizializzano al caricamento indipendentemente dai comandi gtag('config') eventualmente presenti nella pagina.

I comandi di configurazione possono inoltre comparire nel dataLayer come eventi visibili gtag.config. Questo conta quando un contenitore utilizza trigger Evento personalizzato con condizioni troppo ampie o pattern wildcard: potrebbero intercettare anche eventi che prima non venivano trattati allo stesso modo.

Il problema pratico non è tanto la sintassi, quanto ciò che può succedere a valle. Un trigger poco selettivo potrebbe attivare un tag inatteso, moltiplicare richieste o sporcare un report. Non è corretto affermare che accadrà a ogni sito: è una condizione da verificare dove esistono regole generiche.

Per questo includerei nei controlli non soltanto i nomi degli eventi del dataLayer, ma anche l’ordine di esecuzione, i trigger che utilizzano espressioni regolari e le dipendenze tra tag di configurazione e tag evento. La documentazione aggiornata di Google rimanda alla corretta installazione di gtag.js per chi continua a utilizzare i comandi di configurazione nel codice del sito.

I prefissi degli ID non sono una formalità: GTM, G e AW

Una parte del percorso di unificazione riguarda anche il prefisso del contenitore. Google distingue tra identificatori GTM-, che consentono di utilizzare l’insieme completo dei tipi di tag — inclusi script di terze parti e HTML personalizzato — e identificatori di prodotto, come G- o AW-, limitati alle funzioni di tagging Google.

Questa differenza non è un dettaglio cosmetico. Un sito che deve governare GA4, Google Ads, Meta e altri strumenti non può dare per scontato che qualsiasi identificatore esegua automaticamente gli stessi tag.

L’aggiornamento del 9 luglio 2026 ha inoltre modificato il comportamento dei container caricati attraverso percorsi di installazione non supportati: oggi è il prefisso dell’ID a determinare le capacità eseguibili. Google chiarisce che le installazioni effettuate con gli snippet ufficiali non sono interessate dalla relativa anomalia precedente. Fonte: documentazione Google sugli ID contenitore.

Il criterio resta semplice: conoscere l’architettura installata prima di modificarla.

Tagging visivo: più accessibilità, ma ancora non per tutti i casi

Un’altra evoluzione è il tagging visivo attraverso Tag Assistant. Google consente di selezionare elementi direttamente dal sito e di farsi guidare nella configurazione di informazioni di acquisto, come ID transazione, importo, valuta e dati necessari alla misurazione.

È una prospettiva interessante perché rende meno complesso l’avvio di alcune implementazioni. Ma, al momento delle indicazioni ufficiali consultate, questa capacità è presentata in beta per le conversioni di acquisto di Google Ads, non come sostituto universale della progettazione del dataLayer o della configurazione di qualsiasi evento.

C’è anche un’avvertenza esplicita nella guida: quando una conversione di acquisto è già rilevata da un contenitore, continuare con una nuova configurazione può portare a un conteggio doppio. Fonte: guida ufficiale al tagging visivo.

⚙️ Semplificare la creazione di un tag non equivale a stabilire che cosa debba valere come conversione. Una vendita confermata, un clic sul pulsante di acquisto e un avvio di checkout hanno significati diversi. L’interfaccia può aiutare a configurarli; l’impresa deve decidere come interpretarli.

E il server-side? È un’altra architettura, non un effetto collaterale dell’upgrade

Il punto merita una sezione a parte, perché spesso viene confuso. Ottimizzare un contenitore web GTM e implementare un container server-side GTM non sono la stessa operazione.

Nel primo caso si interviene sulla modalità con cui il contenitore web gestisce le destinazioni Google. Nel secondo si configura un ambiente server che riceve eventi, li interpreta e li instrada a una o più destinazioni secondo regole definite. L’invio attraverso infrastrutture controllate dall’azienda può fornire strumenti ulteriori per filtrare o trasformare i dati, ma comporta anche responsabilità tecniche, costi e verifiche aggiuntive.

La documentazione per Google Tag Manager lato server descrive questo modello come una scelta architetturale specifica. Non emerge alcuna indicazione secondo cui l’ottimizzazione web di ottobre crei automaticamente un server container o trasferisca gli eventi sul server.

Per chi utilizza già una configurazione server-side, i controlli diventano ancora più importanti: bisogna capire quali richieste restano nel browser, quali raggiungono il server di tagging e quali vengono inoltrate alle destinazioni. Una nuova modalità di invio diretto ai servizi Google non deve introdurre, per errore, un percorso parallelo che produca duplicati. È un rischio da verificare nel singolo progetto, non un effetto inevitabile dell’aggiornamento.

Il consenso non si risolve cambiando il percorso della richiesta

Un punto su cui non farei compromessi riguarda la privacy. I nuovi flussi di tagging non sostituiscono il Consent Mode e non rendono superfluo il lavoro della piattaforma di gestione del consenso.

Google spiega che, nelle implementazioni server-side, le scelte dell’utente vengono raccolte sul sito, comunicate dal tag web e trasmesse al server attraverso i parametri della richiesta. I tag sul server adeguano poi il proprio comportamento alle informazioni sul consenso. Fonte: guida Google al Consent Mode server-side.

Per le imprese questo significa che l’audit deve coprire tutta la catena: banner e preferenze, valori iniziali e aggiornamenti del consenso, condizioni di attivazione, dati effettivamente inviati, configurazione delle destinazioni e documentazione applicabile. Una richiesta che attraversa un server di proprietà non è automaticamente lecita o conforme.

La qualità della misurazione e la tutela delle scelte degli utenti non sono obiettivi incompatibili. Sono parte della stessa architettura ben progettata.

Un esempio B2B: quando una conversione esiste, ma non rappresenta il risultato

Immaginiamo un distributore industriale che investe in campagne Google Ads per generare richieste commerciali. Sul sito esistono un modulo contatti, un form per richiedere un preventivo e una funzione per scaricare schede tecniche.

Nel tempo, più persone hanno lavorato sul tracciamento. Il modulo invia un evento GA4, una regola GTM attiva una conversione Google Ads, il CRM registra l’arrivo del lead e un’altra integrazione restituisce l’esito del contatto. A colpo d’occhio i report sembrano ricchi. Ma alcune azioni possono essere conteggiate più volte, altre non riportano identificatori stabili, mentre una richiesta generica finisce per pesare quanto una richiesta di offerta realmente qualificata.

Una nuova architettura di GTM può rendere l’invio dei dati più efficiente. Non sa, da sola, distinguere il contatto commerciale utile da quello che non genererà mai una trattativa.

Il progetto che realizzerei partirebbe da una domanda diversa: quale evento del sito indica davvero un progresso verso il risultato economico? Da lì definirei identità dell’evento, sorgente, identificativi utili, eventuale arricchimento da CRM e regole per evitare di moltiplicare le conversioni.

Solo dopo verificherei se ottimizzare il contenitore, mantenere il percorso server-side o ridisegnare una parte della configurazione.

Questo è il punto che considero più importante: prima si chiarisce che cosa significhi “risultato”; poi si ottimizza il percorso con cui lo misuriamo.

Come testare l’aggiornamento senza compromettere i report

Non avvierei una nuova configurazione sul sito in produzione soltanto perché compare un banner in GTM. Sceglierei una sequenza controllata, capace di confrontare prima e dopo.

Google descrive il flusso Area di lavoro → Anteprima → Tag Assistant e la pubblicazione tramite Invia nella propria guida italiana alla verifica e pubblicazione dei tag. L’importante non è eseguire questi passaggi meccanicamente, ma sapere quali segnali devono risultare corretti prima di dire che il lavoro è finito.

La nuova organizzazione dei dati cambia anche il rapporto tra agenzia e impresa

L’evoluzione della piattaforma rende più semplice gestire alcune parti del tracking, ma rende anche più visibile una responsabilità che spesso rimane implicita: chi ha il compito di garantire che i numeri utilizzati nelle decisioni siano attendibili?

Un’impresa può delegare la configurazione tecnica, ma deve conservare una visione chiara dei propri indicatori. Un professionista può conoscere perfettamente GTM e, allo stesso tempo, aver bisogno di confrontarsi con commerciale, amministrazione e direzione per capire che cosa misurare.

Lo vedo ogni volta che la conversazione passa dai click alle opportunità, dai moduli inviati alle trattative, dal fatturato attribuito al margine effettivo. Il valore non sta soltanto nel collegare due sistemi. Sta nel far dialogare la tecnologia che registra, il processo aziendale che genera il risultato e le persone che prendono decisioni.

È in quel punto che analytics e strategia smettono di essere due attività separate. È anche il motivo per cui, nei nostri servizi di consulenza e marketing digitale, partiamo sempre dagli obiettivi prima di progettare la misurazione.

Cosa cambia adesso, e cosa non cambia

Il nuovo Google Tag Manager offre una prospettiva interessante: meno frammentazione nella gestione delle destinazioni Google, maggiore visibilità delle impostazioni e possibilità di rendere più leggero il flusso tecnico in alcune configurazioni.

Non significa che ogni contenitore debba essere aggiornato immediatamente. Non significa che il server-side sia diventato superfluo. E non significa che gli strumenti visivi possano sostituire la definizione delle conversioni o un serio controllo della raccolta dati.

La mia conclusione è semplice: un’azienda non ha bisogno di collezionare più eventi. Ha bisogno di poter prendere decisioni migliori grazie agli eventi giusti.

Se l’evoluzione di GTM ci aiuta a ridurre complessità e incertezza, è un’opportunità. Se invece diventa l’ennesima modifica tecnica introdotta senza una verifica del risultato, rischia di aggiungere un nuovo livello a un sistema che nessuno governa davvero.

La misurazione efficace non comincia dal tag. Comincia da una domanda aziendale alla quale vale la pena rispondere.