Google tag ha tolto il comando più basilare

La rimozione di gtag config dai nuovi snippet impone un adattamento strutturale a ogni nuova implementazione di GTM

Google promette semplificazione, ma il primo dettaglio tecnico che comunica è la rimozione del comando più basilare, gtag config; e il visual tagging, che dovrebbe automatizzare il setup, dichiara da subito di coprire solo il 70–80% dei casi semplici. Il paradosso è servito. Il 20 agosto Google ha annunciato tre cambiamenti a Google tag e Google Tag Manager: un’interfaccia semplificata con una scheda Impostazioni e una scheda Avanzate, l’unificazione tra Google tag e GTM e il visual tagging.

La promessa del 70-80%

L’annuncio si articola in tre mosse. Come si legge nell’annuncio di supporto, l’obiettivo è snellire la configurazione della misurazione, migliorare prestazioni e gestione e offrire un’esperienza più unificata tra i prodotti di tagging. Per i siti che oggi usano solo Google tag, l’aggiornamento a contenitori GTM completi aggiunge tagging tramite interfaccia, debug e controllo versione. Ma è il visual tagging a concentrare le aspettative: consente di creare eventi e conversioni selezionando elementi direttamente sulla pagina, senza codice manuale, ed è attualmente in beta per le conversioni di acquisto in Google Ads.

Qui il dato di copertura è il primo filtro. Come osserva Matteo Zambon, Google sta di fatto ammettendo che il setup manuale era troppo doloroso per la maggior parte degli inserzionisti e sta chiudendo il divario per il 70–80% dei casi in cui «track a purchase button» è l’intero requisito. Tradotto: il visual tagging non affronta il restante 20%, quello che richiede ancora competenze specialistiche. Se il visual tagging promette di coprire la maggior parte dei casi semplici, cosa succede quando si guarda sotto il cofano tecnico?

Cosa si rompe sotto il cofano

Ma la semplificazione annunciata si scontra con la realtà dell’implementazione. Il cambiamento più tecnico è la rimozione del comando gtag config dai nuovi snippet di deployment: secondo la documentazione di supporto, i nuovi snippet non includeranno più il comando e l’inizializzazione sarà gestita tramite il trigger gtm init. Non si tratta di un dettaglio isolato: il cambiamento influenzerà ogni nuova implementazione di GTM da qui in avanti, non solo i casi complessi. Chi prepara un nuovo container dovrà configurare l’inizializzazione in modo diverso rispetto alle indicazioni precedenti.

C’è poi un limite che riguarda la misurazione server-side. La semplificazione del tagging lato browser non riduce di per sé il numero di richieste inviate a un contenitore GTM lato server, come spiega Stape. In altre parole, spostare la configurazione sul trigger gtm init rende più snello lo snippet browser, ma non cambia la catena di richieste che arriva al server. Per chi deve giustificare un’architettura server-side, il guadagno in termini di volume non è automatico: va misurato, non assunto.

L’upgrade dei Google tag a contenitori GTM completi aggiunge funzionalità di debug e controllo versione per chi oggi usa solo Google tag. Ma la rimozione di gtag config introduce un cambiamento strutturale in ogni nuova implementazione. Il paradosso è questo: Google promette meno attrito per l’utente finale, ma il passaggio tecnico più immediato chiede un adattamento a chi configura i container. Se ogni nuova implementazione dovrà adattarsi, quali dati ci diranno se la migrazione ha davvero semplificato la misurazione?

La domanda che resta aperta

La semplificazione non è una promessa nuova. Già nel 2022 Google aveva parlato di una più stretta integrazione e di percorsi di aggiornamento tra Google tag e Google Tag Manager, come si legge nel post del blog ufficiale. L’annuncio del 20 agosto 2026 è quindi il punto di arrivo di un percorso iniziato anni prima, ma arriva con un limite: il visual tagging è in beta e copre solo le conversioni di acquisto in Google Ads. Restano aperti i nodi su migrazione, adozione ed effettiva riduzione del carico di implementazione.

La prossima metrica da osservare non è la percentuale di casi coperti, ma l’impatto reale sulla migrazione e sulla qualità della misurazione. La domanda resta aperta: come valuteremo se la semplificazione ha ridotto gli errori di configurazione, migliorato l’attribuzione o diminuito il lavoro specialistico sul 20% rimanente? Il lavoro di misurazione non è finito, ma la domanda su cosa andrebbe misurato meglio resta aperta.