Checklist Google Tag Manager: container, naming, ambienti e pubblicazione
10 Settembre 2026 · Dati e misurazione
La richiesta deve essere contata dopo l’invio riuscito
Un produttore di quadri elettrici riceve dal sito un modulo con un allegato tecnico. Il visitatore preme «Invia», ma il caricamento del file fallisce. Google Tag Manager deve contare la richiesta soltanto dopo la conferma dell’invio riuscito. Questa checklist serve al titolare per chiedere al tecnico una prova comprensibile prima di pubblicare la modifica.
Il percorso mostra dove controllare una modifica GTM prima e dopo la pubblicazione.
Scarica l’infografica (PNG ad alta risoluzione)
Incorpora l’infografica nel tuo sito
Puoi ripubblicare l’infografica usando questo codice, con il collegamento all’articolo originale.
Capire che cosa c’è nel container
Google Tag Manager, abbreviato in GTM, gestisce istruzioni chiamate tag, che possono inviare dati agli strumenti di analisi. Il container raccoglie la configurazione usata dal sito. Un evento descrive un’azione avvenuta; il trigger è la condizione che fa partire il tag. Il tecnico deve spiegare quale conferma genera l’evento di richiesta.
Il data layer è la struttura con cui il sito mette a disposizione dei tag le informazioni sugli eventi. La documentazione Google spiega come il campo event possa attivare i tag. Per il produttore di quadri, lo sviluppatore comunica il nome dell’evento emesso dopo l’invio accettato. Chi configura GTM usa quel nome per la condizione di attivazione.
Prima del lavoro, chiedi una mappa dei container e delle destinazioni dei dati. Il sito pubblico e l’eventuale applicazione possono avere configurazioni diverse. Il titolare deve sapere chi gestisce ciascuna parte e dove arrivano le misure. Un container usato sul server, cioè nell’infrastruttura che elabora le richieste, va descritto separatamente da quello eseguito nel browser.
L’azienda deve poter mantenere gli accessi
Google raccomanda che l’account sia gestito da una persona dell’organizzazione e che abbia un amministratore aggiuntivo. Se l’account ha un solo amministratore e quella persona non è più raggiungibile, l’azienda non riesce più a modificare i tag. Gli accessi vanno quindi riesaminati prima che cambi il fornitore o esca il dipendente che segue il sito.
I permessi del container distinguono la lettura dalla modifica, dalla creazione di versioni e dalla pubblicazione. Assegna il diritto di pubblicare a chi deve assumersi quel compito. Il tecnico che prepara una modifica può avere un ruolo diverso. Nel processo concordato deve comparire il nome di chi controlla la prova e di chi decide il rilascio.
Le richieste di approvazione integrate in GTM sono disponibili solo nella versione a pagamento, Google Tag Manager 360. Con un account standard basta che un collega controlli la modifica prima della pubblicazione e lo scriva nella nota della versione.
Nomi che il prossimo tecnico possa leggere
Il naming è la convenzione usata per dare nomi coerenti agli oggetti. GA4 significa Google Analytics 4, lo strumento di analisi. L’azienda può concordare nomi come GA4 | richiesta_preventivo per un tag, indicando la destinazione e l’azione inviata. Un trigger come evento | invio_riuscito descrive invece la condizione reale che lo attiva. Una variabile come dato | tipo_richiesta indica il dato letto.
Sono esempi di una convenzione aziendale, da concordare con chi lavora sul container. Le eccezioni vanno spiegate nella documentazione, senza lasciarle soltanto nel nome. Correggere un’etichetta non cambia le condizioni di attivazione del tag; la prova deve mostrare che cosa succede davvero.
La specifica del data layer descrive quando nasce l’evento e che cosa contengono i valori associati. Una brochure scaricata deve restare riconoscibile rispetto a una richiesta commerciale. I nomi basati sulle iniziali di un fornitore o sulla parola «nuovo» diventano poco utili al cambio del team. Cartelle e descrizioni aiutano a spiegare lo scopo del tag.
Per un’azienda di prodotti chimici, il download di una scheda di sicurezza può essere fatto da un cliente già acquisito. Contarlo come richiesta di preventivo altererebbe la lettura delle campagne. Il responsabile commerciale concorda con chi misura il sito quali azioni tenere nei report, poi il tecnico le collega agli eventi corrispondenti.
Workspace, versione e ambiente fanno lavori diversi
Il workspace è l’area in cui si prepara un gruppo di modifiche. La versione fotografa una configurazione. La pubblicazione la rende operativa nell’ambiente scelto. Google documenta sia la possibilità di salvare versioni sia quella di recuperarne una precedente. Prima di pubblicare bisogna leggere il riepilogo delle differenze.
Due fornitori possono lavorare nello stesso giorno sul modulo e sul catalogo. I workspace permettono di preparare i lavori separatamente, ma le modifiche devono essere confrontate prima della versione finale. Un tag estraneo al modulo va spiegato dal suo autore. Le note di rilascio indicano quali oggetti sono stati aggiunti, cambiati o rimossi.
L’ambiente di staging è una copia di prova del sito. GTM permette di associare configurazioni a diversi ambienti, usando il codice previsto o un collegamento di anteprima. Il tecnico controlla la destinazione effettiva dei dati di test. La parola «test» nel nome del tag non impedisce che i dati finiscano nei report reali.
La prova da allegare al rilascio
La modalità Preview collega il sito a Tag Assistant e mostra quali tag si attivano. È un controllo utile prima della pubblicazione. Per seguire una richiesta completa servono poi la conferma nella destinazione di analisi e il riscontro del commerciale sul sistema che riceve il modulo. Il test comprende i casi nei quali l’invio deve fallire.
| Situazione | Che cosa deve vedere il tecnico | Riscontro commerciale |
|---|---|---|
| Invio riuscito | L’evento atteso arriva una volta alla destinazione concordata. | La richiesta compare nel sistema che riceve i moduli. |
| Campo obbligatorio vuoto | L’evento di richiesta riuscita rimane assente. | Nessuna richiesta incompleta viene scambiata per invio. |
| Errore nell’allegato | Il sito mostra l’errore e non emette il lead riuscito. | Il visitatore sa come riprovare. |
| Ricaricamento della conferma | La stessa richiesta non viene contata di nuovo. | Il report non duplica il contatto. |
| Scelte sul consenso | I tag rispettano gli stati e gli aggiornamenti concordati. | Il risultato della prova è descritto nelle note. |
| Invio dal telefono e da un altro sito (per esempio un modulo ospitato su un indirizzo diverso) | L’invio conserva il funzionamento e i parametri previsti. | Il contatto arriva al referente giusto. |
| Area riservata | L’evento funziona nello stato di accesso previsto, senza invii impropri negli altri stati. | La richiesta arriva al referente competente per l’area. |
| Modulo che non ricarica la pagina | Ogni richiesta completata viene riconosciuta una volta, anche ripetendo l’invio nella stessa pagina. | Richieste distinte restano riconoscibili e non compaiono duplicazioni. |
| Versione precedente | Il tecnico sa quale configurazione recuperare. | Il referente conosce chi avvisare per il ripristino. |
Il tecnico annota l’indirizzo provato e l’esito, poi firma la prova. Nelle richieste interne usa dati riconoscibili da chi riceve i moduli. Il contenuto del disegno e l’email del buyer non devono finire per errore nei parametri delle piattaforme di analisi. Il controllo riguarda i valori trasmessi, visibili nelle richieste di rete.
Le prove coprono il consenso concesso e quello negato, poi il suo eventuale aggiornamento. Il comportamento atteso dipende dalla configurazione adottata. Le verifiche tecniche vanno concordate con chi segue le scelte sul trattamento dei dati. Consent Mode è il sistema con cui Google riceve la scelta del visitatore sui cookie. L’uso di GTM non decide da sé quali trattamenti l’azienda possa effettuare.
Per l’area riservata e il modulo che non ricarica la pagina, il tecnico può segnare non applicabile quando quelle funzioni non esistono nel sito, scrivendone il motivo nel foglio delle prove.
Che cosa ferma la pubblicazione
Chiedi al responsabile tecnico di esaminare gli script Custom HTML, cioè il codice personalizzato inserito nel container, e i modelli di tag prima del rilascio. Deve chiarire quali dati possono leggere e quali destinazioni possono contattare. La prova e il nome del revisore restano nelle note della versione. Se nessuno ha controllato il codice aggiunto, la modifica non va pubblicata.
Un evento duplicato o generato da un modulo fallito impedisce di fidarsi dei conteggi. Una destinazione sbagliata può inquinare il report delle campagne. L’assenza di un accesso aziendale impedisce di intervenire in autonomia. Questi problemi vanno risolti prima di rilasciare la modifica interessata, con una nuova prova dell’esito corretto.
Ogni controllo può essere conforme, parziale, non conforme o non applicabile. Una prova fatta solo da computer è parziale quando il modulo viene usato anche dal telefono. Un container server assente può rendere non applicabili i controlli specifici di quell’architettura. La motivazione evita che una casella vuota venga scambiata per un test superato.
Ripristino e controllo sul sito pubblicato
Il rollback è il ritorno a una versione precedente. Il tecnico identifica quella da usare e descrive come pubblicarla. Deve chiarire anche che cosa rimarrebbe attivo sul sito. Ripristinare GTM non annulla una modifica distribuita dallo sviluppatore nel modulo o nel data layer; può essere necessario coordinare entrambi gli interventi.
Dopo il rilascio invia una richiesta interna dal sito pubblico e seguila nelle destinazioni previste. Il commerciale conferma la ricezione, chi misura controlla l’evento. Nella nota rimane il risultato. La manutenzione successiva riguarda i tag senza referente e le configurazioni inutilizzate, insieme agli accessi dei collaboratori cessati.
Il resoconto conta le duplicazioni e gli errori ancora aperti. Riporta le pubblicazioni prive di revisione e i tempi di ripristino effettivamente osservati. Le differenze tra prova e sito pubblico devono avere una spiegazione. Il numero dei tag aggiunti non misura la qualità del lavoro.
Domande frequenti
A cosa servono i workspaces?
A sviluppare set di modifiche separati e gestire conflitti prima della versione.
Quanti container servono?
Quelli necessari a mantenere perimetri tecnici e responsabilità, senza moltiplicazione arbitraria.
GTM risolve la privacy?
No. Implementa comportamenti; finalità, consenso, dati e conformità richiedono governance più ampia.
Decidere il rilascio con chi usa i dati
Con fornitori diversi per sito e campagne, puoi affidare a KLC il coordinamento della prova e del rilascio. Prima del rilascio, la prova condivisa con il commerciale conferma che il modulo arrivi e che la richiesta sia contata nel modo concordato.
Fonti e riferimenti
- Google Tag Platform, il data layer. Struttura dei dati e campo event usato per attivare i tag.
- Google Tag Manager, considerazioni prima dell’installazione. Gestione aziendale dell’account e raccomandazione di un amministratore aggiuntivo.
- Google Tag Manager, anteprima e debug. Preview e Tag Assistant mostrano l’attivazione dei tag prima della pubblicazione.
- Google Tag Manager, pubblicazione e versioni. Versioni, recupero della configurazione precedente e approvazioni integrate in Google Tag Manager 360.
- Google Tag Manager, ambienti. Configurazioni e codice per gli ambienti di prova e pubblicazione selettiva.
- Google Tag Platform, Consent mode overview. Comunicazione a Google delle scelte di consenso del visitatore.
Approfondisci il servizio: Analytics e conversioni.