GTM diventa Google Tag: cosa cambia davvero con gli aggiornamenti di agosto 2026

Google Tag e Google Tag Manager stanno diventando un unico sistema. Il rollout è partito a luglio con la nuova Overview e ha preso forma completa ad agosto 2026, come descritto nel post di Stape del 21 agosto 2026. Per chi gestisce container GTM per clienti la frase da tenere a mente è una sola: nessuna modifica automatica. I tag esistenti continuano a funzionare come prima, i container non vengono convertiti da soli e l'adozione del nuovo modello è opt-in.

Cosa cambia in concreto: l'interfaccia (nuova Overview, sezione Settings, sezione Advanced), i nuovi snippet di installazione (senza il comando gtag config), il modo in cui il container invia dati alle destinazioni Google (senza caricare un gtag.js separato) e il visual tagging in beta tramite Tag Assistant. Cosa non cambia: la logica di Consent Mode, il comportamento in pagina dei tag già pubblicati e, in larga parte, il server-side tagging.

Chi è più toccato: chi usava solo il Google Tag (gtag.js) senza container, perché ottiene interfaccia, debug e versioning. Chi ha un container GTM maturo deve soprattutto verificare, documentare e formare il team.

Prima e dopo: la tabella di sintesi

L'unificazione tocca cinque aree: interfaccia, snippet, rapporto tra Google Tag e container, visual tagging e versioning. Ecco il confronto, con le fonti a fianco.

Area	Prima	Dopo (rollout luglio-agosto 2026)	Fonte
UI	Workspace con Tag, Trigger, Variabili, Cartelle, Template tutti allo stesso livello nel menu	Overview ridisegnata; configurazione del container in Settings; trigger, variabili, template e cartelle raggruppati sotto una sezione Advanced a scomparsa	Release notes GTM 1 luglio 2026; Stape 21 agosto 2026
Snippet	Google Tag installato con gtag.js e comando gtag('config', 'ID'); GTM con il classico snippet gtm.js	I nuovi snippet di deployment non contengono più il comando gtag config; Google consiglia il trigger di inizializzazione (gtm init) per le operazioni di avvio	Stape 21 agosto 2026
Google Tag vs container	Due prodotti: il Google Tag configurato a parte, il container GTM che poteva caricare un gtag.js aggiuntivo per parlare con GA4 o Google Ads	Un unico sistema: il container invia i dati direttamente alle destinazioni Google. Ogni destinazione mantiene il proprio tag, ma le impostazioni si gestiscono nell'esperienza unificata	Stape 21 agosto 2026; GA Optimizer 7 maggio 2026
Visual tagging	Configurazione manuale di trigger e variabili per ogni evento	Beta: si selezionano gli elementi direttamente sul sito via Tag Assistant, per ora per le conversioni di acquisto in Google Ads	Stape 21 agosto 2026
Versioning e debug	Disponibili solo per chi usa un container GTM	Chi ha solo il Google Tag ottiene tagging da interfaccia, debug e version control	Stape 21 agosto 2026

Una precisazione sullo snippet: alla data di oggi la pagina ufficiale di installazione di GTM mostra ancora il classico snippet con gtm.start e l'evento gtm.js, senza alcun comando gtag config. Il cambiamento riguarda quindi chi arriva dal Google Tag (gtag.js) o chi genera un nuovo snippet dall'esperienza unificata, non chi ha già un container installato con lo snippet tradizionale.

Cosa fare nei container esistenti

Un container GTM già pubblicato non richiede interventi urgenti, ma richiede una verifica ordinata. Questa è la checklist che seguo quando prendo in mano un container dopo un cambio di piattaforma di questo tipo.

1. Verifica lo snippet in pagina. Controlla nel sorgente e nel network quale codice è realmente installato: snippet GTM classico, snippet gtag.js con gtag('config'), o entrambi. La coesistenza di gtag.js e GTM sulla stessa pagina è la situazione più a rischio di doppi eventi, e con la nuova architettura il container invia già i dati alle destinazioni Google senza un gtag.js separato.
2. Controlla la dipendenza da gtag config. Se hai custom HTML o script esterni che chiamano gtag('config', ...) o gtag('set', ...) contando sul fatto che gtag.js sia in pagina, mappali. Con i nuovi snippet quel comando non c'è: la configurazione va spostata nel tag Google della destinazione o in un tag legato al trigger di inizializzazione. La documentazione ufficiale sui trigger definisce il trigger Initialization come quello che scatta prima di tutti gli altri, eccetto Consent Initialization.
3. Occhio all'ID che carica il container. La release note del 9 luglio 2026 chiarisce che, per i percorsi di installazione non supportati, è l'ID usato per caricare il container a controllare il comportamento, a prescindere dal path. Se hai installazioni "creative" (proxy interni, path riscritti, ID mescolati tra Google Tag e GTM), testale.
4. Testa in Preview con lo stesso rigore di una migrazione. Un giro completo di Tag Assistant sui flussi principali: pageview, eventi chiave, conversione, consenso negato e accettato. Confronta il numero di richieste verso Google Analytics e Google Ads prima e dopo: se cala, è la rimozione del gtag.js ridondante; se raddoppia, hai un doppio invio.
5. Aggiorna la documentazione interna. Screenshot e guide che dicono "vai in Variabili nel menu a sinistra" sono già vecchi: ora quelle voci vivono sotto Advanced. Chi entra nel container per la prima volta si perde in tre minuti.
6. Rivedi la governance. Un'interfaccia che nasconde trigger e variabili sotto una sezione a scomparsa rende ancora più facile accumulare disordine senza vederlo. Se il container ha superato i cento tag, il momento giusto per una pulizia con naming convention e cartelle è adesso: ne ho scritto in tag governance per container GTM da 200 tag.

Server-side: cosa cambia e cosa no

Il server-side tagging è la parte meno toccata da questo aggiornamento. Lo dice Stape stessa, e le release notes ufficiali di sGTM lo confermano: le tre release del 2026 (4.2.0 del 2 febbraio, 4.3.0 del 28 aprile, 4.4.0 del 22 luglio) contengono solo l'aggiornamento dell'immagine base per motivi di sicurezza. Il passaggio a Node.js 24 con immagine gcr.io/distroless/nodejs24-debian13 risale alla 4.0.0 del 10 novembre 2025.

Cosa resta identico:

• Il container server, i client (GA4, Google Tag) e i tag server-side non cambiano logica. Il flusso browser, endpoint first-party, container server, destinazioni finali funziona come descritto nella pagina dedicata al GTM server-side.
• I costi di hosting non sono influenzati dall'unificazione lato web. Se il tema ti interessa, ho analizzato i costi di Cloud Run per il server-side tagging.
• Le versioni 4.x vanno comunque aggiornate: un'immagine base con patch di sicurezza è un motivo sufficiente, e chi usa deployment manuali su Cloud Run o Docker deve farlo a mano.

Cosa cambia intorno al server-side, anche se non dentro:

• Google tag gateway for advertisers si è allargato nel 2026. Le release notes GTM registrano l'integrazione con Akamai e Fastly il 14 maggio 2026 e Amazon CloudFront il 3 giugno 2026, dopo Google Cloud Platform in beta dal 5 gennaio 2026. Secondo la documentazione del gateway, il servizio serve i tag Google da infrastruttura first-party (CDN, load balancer o web server) e si integra con il server-side tagging per il setup "più durevole".
• Floodlight in setup server-to-server. La release note del 22 giugno 2026 dice che quando è presente un GCLID i dati server-side vengono uniti ai segnali paralleli del browser, come i cookie, per recuperare conversioni Floodlight prima sottostimate per mancanza di contesto cookie. È un cambiamento di attribuzione lato Google, non una modifica al tuo container server. Vale la pena monitorare i conteggi Floodlight da fine giugno in poi.
• Lo snippet web cambia, l'endpoint no. Se il container web carica da un dominio first-party (il tuo endpoint sGTM), il nuovo snippet senza gtag config deve continuare a puntare lì. È un controllo da fare in fase di rigenerazione dello snippet, non una modifica al server.

Chi gestisce setup ibridi complessi può confrontare approcci nella classifica degli esperti server-side tracking in Italia.

Consent Mode: la logica non cambia, lo snippet sì

La logica di Consent Mode resta identica: gli stati di consenso (analytics_storage, ad_storage, ad_user_data, ad_personalization) vanno impostati come default prima che qualsiasi tag Google scatti, e aggiornati quando l'utente sceglie. Il trigger Consent Initialization continua a essere quello che parte prima di tutto, come ribadisce la documentazione ufficiale sui trigger citata sopra.

Il punto di attenzione è il posizionamento. Molte installazioni impostano il default di consenso con un blocco gtag('consent', 'default', {...}) inline, subito prima dello snippet gtag.js, dando per scontato che gtag.js sia in pagina. Se rigeneri lo snippet nel nuovo formato e rimuovi gtag.js, quel blocco inline resta ma la funzione gtag potrebbe non essere più definita nel modo che ti aspetti. Le opzioni pulite sono due:

• Spostare il default di consenso in un tag legato al trigger Consent Initialization, come faccio con il custom template per Consent Mode v2.
• Usare il template del CMP che già gestisce il default e l'update; se lavori con Iubenda, la guida a Iubenda, GTM e Consent Mode copre l'ordine di caricamento.

In entrambi i casi il test da fare è lo stesso: in Preview, con consenso negato, nessuna richiesta a Google Ads deve partire con i parametri di conversione, e le richieste GA4 devono mostrare i segnali di consenso corretti. Se il risultato è identico prima e dopo il cambio di snippet, sei a posto.

Impatto per agenzie e team

Per un'agenzia che gestisce decine di container l'impatto è organizzativo più che tecnico. Tre aree da presidiare.

Formazione. Il team deve sapere dove sono finite le cose: Settings per la configurazione del container, Advanced per trigger, variabili, template e cartelle. Un'ora di walkthrough condiviso evita giorni di "non trovo più i trigger". Le procedure interne di QA vanno riscritte con la nuova navigazione.

Accessi. Con l'unificazione, i clienti che avevano solo un Google Tag configurato dall'account Google Ads o GA4 si trovano con versioning e debug. Chiarisci chi ha diritto di pubblicare: se il cliente pubblica una versione dal proprio lato mentre l'agenzia lavora nel workspace, il conflitto è dietro l'angolo. Il modello di permessi per utente e container resta il punto da regolare per contratto.

Chi ha solo il Google Tag. È la categoria che guadagna di più: interfaccia, versioni, anteprima. È anche quella che rischia di più, perché per la prima volta può modificare la configurazione senza un dev. Per un'agenzia è l'occasione per proporre un passaggio ordinato a un container gestito, con naming e processo di revisione dal primo giorno.

Cose ancora non chiare

Alcuni punti restano aperti alla data di oggi e preferisco dichiararli invece di riempire i buchi.

• Il testo esatto dei nuovi snippet. Stape descrive snippet senza gtag config, ma la pagina ufficiale di installazione GTM mostra ancora il formato classico. Non ho una fonte Google che pubblichi il nuovo snippet riga per riga.
• Il rapporto tra "gtm init" e i trigger esistenti. Il consiglio di usare il trigger di inizializzazione è chiaro, ma non è documentato se cambi qualcosa nell'ordine tra Consent Initialization e Initialization, né se esistano nuovi eventi dataLayer dedicati.
• La tempistica per gli account. Il rollout è incrementale e il post di GA Optimizer parla di "funzionalità di ottimizzazione complete" distribuite nel corso dell'anno. Non c'è una data in cui tutti gli account vedranno la stessa cosa.
• Il visual tagging oltre Google Ads. La beta copre le conversioni di acquisto in Google Ads. Non è annunciato se e quando arriverà per eventi GA4 o per altre destinazioni.
• Floodlight e consenso. La release note del 22 giugno 2026 descrive un join tra dati server e segnali browser in presenza di GCLID, ma non specifica come interagisca con gli stati di Consent Mode. Se lavori con Campaign Manager 360 è una domanda da porre al referente Google.

Prossimi passi

Se gestisci container per clienti, il lavoro utile nelle prossime settimane è un giro di verifica per ciascun container: snippet effettivamente in pagina, dipendenze da gtag config, test in Preview con consenso negato e accettato, documentazione aggiornata alla nuova navigazione. Nessuna migrazione forzata, ma nemmeno la scusa per rimandare la pulizia.

Se vuoi una fotografia neutrale dello stato di un container prima di metterci mano, l'audit del tracking GA4 e GTM parte esattamente da questi controlli.