KLC Richiedi un’analisi
Passa al contenuto principale
Google Tag Manager: che cos’è, come governarlo e quando serve davvero

Google Tag Manager: che cos’è, come governarlo e quando serve davvero

Scritto da KLC il . Pubblicato in Dati e misurazione.

15 Agosto 2026 · Dati e misurazione

Google Tag Manager è un sistema per gestire tag e configurazioni di misurazione attraverso un contenitore, riducendo la necessità di modificare il codice del sito per ogni intervento. Non è però un sostituto dello sviluppo, non corregge un piano di misurazione sbagliato e non rende automaticamente conforme la raccolta dei dati.

Il suo valore emerge quando eventi, permessi, versioni, test e consenso sono governati come componenti di produzione.

Che cosa gestisce Tag Manager

Un contenitore può includere:

  • tag Google Analytics e Google Ads;
  • eventi basati su interazioni;
  • pixel di piattaforme autorizzate;
  • conversion linker;
  • variabili e data layer;
  • regole di attivazione;
  • tag HTML personalizzati;
  • template;
  • integrazione con la gestione del consenso.

Il browser riceve comunque codice e può inviare dati ai fornitori. “È in GTM” non significa che sia sicuro, necessario o autorizzato.

Quando serve davvero

GTM è utile quando:

  • più sistemi di misurazione condividono eventi;
  • il sito ha un data layer strutturato;
  • servono versioni e rollback;
  • marketing e sviluppo devono collaborare;
  • esistono ambienti di test;
  • il consenso deve controllare il comportamento dei tag;
  • le modifiche richiedono QA ripetibile;
  • più proprietà usano standard comuni.

Può essere eccessivo per un sito molto semplice con un solo tag installato correttamente. La scelta deve considerare rischio e capacità di manutenzione.

Il data layer come contratto con il sito

Il data layer separa il significato degli eventi dalla struttura visiva. Invece di attivare un tag perché l’utente clicca un elemento con classe .button-green, il sito può inviare:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'rfq_submit_success',
  form_type: 'technical_quote',
  product_family: 'valves'
});

L’evento descrive ciò che è accaduto. Il trigger visivo può cambiare senza rompere la misura.

Il contratto deve definire:

  • nome evento;
  • significato;
  • momento di emissione;
  • parametri;
  • tipi e valori ammessi;
  • dati vietati;
  • owner;
  • versione;
  • test di accettazione.

Non si devono inserire dati personali nei parametri analytics non previsti. Campi liberi, email e URL possono esporre informazioni sensibili.

Stabilire una convenzione di nomi

Contenitori disordinati diventano rapidamente ingestibili. Una convenzione può includere:

  • tipo: GA4, ADS, CMP, UTIL;
  • funzione: evento o configurazione;
  • oggetto: form, download, video;
  • ambiente o mercato, se necessario.

Esempio: GA4 - Event - RFQ success. Anche cartelle e descrizioni aiutano, ma non sostituiscono documentazione esterna per gli eventi critici.

Permessi e proprietà dell’account

L’account deve appartenere all’organizzazione, non al profilo personale di un fornitore. Google Tag Manager consente permessi a livello account e contenitore. È utile applicare il principio del minimo privilegio:

  • lettura per chi deve consultare;
  • modifica per chi configura;
  • approvazione o pubblicazione per un numero limitato di responsabili;
  • almeno due amministratori interni;
  • revisione periodica degli accessi;
  • rimozione degli utenti non più autorizzati.

Condividere credenziali impedisce di attribuire le modifiche e aumenta il rischio.

Workspaces, versioni e ambienti

Le aree di lavoro permettono di sviluppare insiemi separati di modifiche. Prima di pubblicare:

  1. descrivere lo scopo;
  2. confrontare le modifiche;
  3. risolvere conflitti;
  4. provare in preview;
  5. verificare consenso e rete;
  6. creare una versione con nome leggibile;
  7. pubblicare nell’ambiente corretto;
  8. monitorare.

Gli ambienti di GTM possono sostenere test su sviluppo o staging. Non bisogna però inviare dati reali di test alle proprietà di produzione senza controllo.

Le versioni consentono rollback, ma il rollback del contenitore non ripristina codice, CMP o backend. Le dipendenze vanno documentate.

Consent Mode comunica ai tag Google lo stato delle scelte dell’utente e ne modifica il comportamento. Il banner o la CMP raccolgono e gestiscono la scelta. Sono componenti distinti che devono essere integrati.

La documentazione Google richiede di impostare uno stato predefinito e aggiornarlo dopo l’interazione. I segnali comprendono, tra gli altri:

  • analytics_storage;
  • ad_storage;
  • ad_user_data;
  • ad_personalization.

Le configurazioni giuridiche non possono essere decise da GTM. Categorie, base giuridica, testi, geografie e conservazione richiedono valutazione competente.

In una configurazione basic, i tag Google vengono bloccati fino all’interazione secondo il modello scelto. In quella advanced, i tag possono caricarsi con stati negati e inviare ping privi delle normali funzionalità di archiviazione, secondo la documentazione Google.

La scelta non è soltanto tecnica. Deve essere approvata in base alla policy dell’organizzazione e alla normativa applicabile. Tag Assistant e gli strumenti di rete vanno usati per verificare cosa accade prima e dopo ogni scelta.

QA di un rilascio

Un piano di test dovrebbe coprire:

  • accettazione, rifiuto e preferenze parziali;
  • prima visita e visite successive;
  • desktop e mobile;
  • più lingue e regioni;
  • form riusciti e falliti;
  • link e download;
  • deduplica degli eventi;
  • parametri;
  • navigazione single-page, se presente;
  • integrazioni advertising;
  • traffico interno;
  • errori JavaScript;
  • richieste di rete;
  • record nei report.

Vedere un tag “fired” non dimostra che il dato sia corretto. Bisogna verificare payload, destinazione e significato.

Gestire tag personalizzati e fornitori

I tag HTML personalizzati hanno grande libertà e quindi maggiore rischio. Prima di approvarli:

  • leggere il codice;
  • identificare dominio e dati inviati;
  • verificare necessità e consenso;
  • evitare dipendenze non documentate;
  • limitare permessi e attivazione;
  • definire owner e data di revisione;
  • rimuovere tag non più usati.

Template verificati possono ridurre alcuni rischi, ma richiedono comunque valutazione.

Un esempio di governance insufficiente

Tre agenzie lavorano sullo stesso contenitore. Ognuna crea un evento “lead” con trigger diverso. Il modulo genera tre conversioni, una al click, una alla visualizzazione della pagina grazie e una alla risposta server. Le campagne sembrano performare meglio, ma il CRM riceve un solo lead.

La soluzione è definire un unico evento di successo, rimuovere duplicati, documentare i trigger e limitare la pubblicazione. Il problema non era GTM: era l’assenza di responsabilità.

Quando usare direttamente il codice

Alcune funzioni possono richiedere sviluppo:

  • eventi emessi dal backend;
  • autenticazione;
  • configurazioni di sicurezza;
  • gestione robusta del consenso;
  • logica applicativa;
  • dati che devono essere validati dal server;
  • integrazioni critiche.

GTM può ricevere e distribuire il segnale, ma non deve diventare un livello applicativo nascosto che nessuno controlla.

Il principio finale

Google Tag Manager è un sistema di rilascio per la misurazione. È utile quando rende cambiamenti tracciabili, testabili e reversibili. Senza data layer, permessi, consenso e QA, accelera anche gli errori. La domanda non è “possiamo aggiungere questo tag?”, ma “chi ne è responsabile, quale dato raccoglie e come dimostriamo che funziona correttamente?”.

Fonti ufficiali

Approfondisci il servizio: Analytics e conversioni.