Audit dei tracciamenti GTM: la checklist in 15 punti prima di toccare un container

Un audit dei tracciamenti GTM è una verifica sistematica di cosa fa davvero un container Google Tag Manager: quali tag esistono, quando sparano, con quali dati, sotto quale consenso e con quale effetto sui numeri che leggi in GA4 e Google Ads. Non è un "giro in Preview" di mezz'ora. Produce tre cose concrete: un inventario del container (tag, trigger, variabili, template, versioni), un elenco di anomalie con gravità e impatto sul dato, un piano di rientro ordinato per priorità.

L'ordine di grandezza, per un container medio (poche decine di tag, un ecommerce o dei lead form, una consent platform), è di due o tre giornate tra raccolta, verifica e scrittura. Un container da 200 tag con più domini e server-side può richiedere una settimana. Questa checklist serve a chi eredita un container e deve decidere cosa è rotto, cosa è rischioso e cosa lasciare stare prima di pubblicare qualsiasi versione.

Preparazione: cosa serve prima di iniziare

Prima di aprire il container ti servono accessi, un export e due elenchi. Senza questi l'audit resta una lista di impressioni.

• Accessi: GTM con permesso almeno Read sul container (per l'export serve Edit o superiore), GA4 con ruolo Analyst o Editor, Google Ads in lettura, Search Console per eventuali problemi di rendering delle pagine chiave.
• Export del container in JSON: da Admin, sezione Container, "Export Container". L'export include tag, trigger, variabili e template e permette di scegliere versione o workspace (fonte: guida export e import GTM). Esporta la versione live, non il workspace: l'audit verifica quello che gli utenti ricevono.
• Elenco delle pagine chiave e delle conversioni: home, pagina prodotto o servizio, carrello e checkout, pagina di ringraziamento, form di contatto. Per ogni conversione: nome dell'evento atteso, destinazione (GA4, Ads, Meta, altro) e chi la usa per decidere.
• Consent platform in uso: Iubenda, Cookiebot, OneTrust, custom. Serve sapere come comunica lo stato del consenso a GTM (template ufficiale, dataLayer push, cookie).

Con l'export JSON fai gran parte dell'inventario senza cliccare nell'interfaccia: uno script o un foglio di calcolo che elenca tag, tipo, trigger e stato (attivo o in pausa) è il punto di partenza.

I 15 punti in 5 aree

Ogni punto ha quattro attributi: cosa verificare, come, esito atteso, gravità tipica. La gravità ha tre livelli: alta (dato di conversione o compliance compromessi), media (dato distorto ma leggibile), bassa (ordine e manutenibilità).

Area 1: governance

1. Naming e cartelle. Verifica dall'export JSON se tag, trigger e variabili seguono una convenzione leggibile (tipo, destinazione, evento). Nella nuova interfaccia le cartelle stanno sotto "Advanced". Esito atteso: nomi che dicono cosa fa l'elemento senza aprirlo. Gravità: bassa, ma rende costosi tutti gli altri punti. Le regole che uso per rimettere ordine sono in tag governance per container con 200 tag.

2. Versioni e note. Apri la cronologia versioni e leggi le note delle ultime dieci pubblicazioni. Esito atteso: ogni versione spiega cosa è cambiato e perché. Gravità: bassa, media se trovi pubblicazioni senza nota nei giorni in cui i dati sono cambiati.

3. Utenti e permessi. In Admin, gestione utenti, elenca chi ha Publish. A livello container GTM prevede i ruoli No access, Read, Edit, Approve e Publish. Solo Publish mette in produzione (fonte: gestione utenti e permessi GTM). Esito atteso: Publish limitato a chi ne risponde, fornitori passati rimossi, almeno due amministratori attivi. Gravità: media, alta se trovi ex fornitori con Publish.

4. Tag in pausa e orfani. Dall'export JSON conta i tag in pausa, i tag senza trigger, i trigger e le variabili non referenziati da nessun tag. Esito atteso: zero orfani o un motivo scritto per tenerli. Gravità: bassa. Un tag in pausa da un anno è quasi sempre da eliminare, non da riattivare.

Area 2: consent

5. Default e update di Consent Mode v2. Verifica che esista un comando di default con i quattro segnali ad_storage, analytics_storage, ad_user_data e ad_personalization, eseguito prima di qualsiasi tag Google e seguito da un update quando l'utente sceglie (fonte: guida consent mode, Google Tag Platform). Come: Tag Assistant in Preview, scheda Consent del primo evento della pagina. Esito atteso: default su "denied" dove serve, update presente dopo l'interazione con il banner. Gravità: alta. Se il template della CMP non gestisce i segnali v2, vedi Consent Mode v2 con custom template.

6. Ordine di caricamento. Il tag della CMP deve sparare sul trigger "Consent Initialization - All Pages", che GTM esegue prima di tutti gli altri trigger (fonte: supporto consent mode in Tag Manager). Come: in Preview, controlla che il tag CMP compaia nell'evento Consent Initialization e non in Initialization o Page View. Esito atteso: la CMP è il primo tag eseguito. Gravità: alta. Con Iubenda i dettagli sono in Iubenda e GTM, integrazione consent mode.

7. Tag che sparano senza consenso. Attiva la Consent Overview (Admin, impostazioni container, "Enable consent overview") e aprila dall'icona nella lista tag: divide i tag in "Consent Not Configured" e "Consent Configured" (stessa fonte). Poi in Preview rifiuta tutto dal banner e guarda quali tag risultano comunque "Fired". Esito atteso: i tag non Google (Meta, LinkedIn, TikTok, strumenti di heatmap) hanno un additional consent check e non sparano con rifiuto. Gravità: alta, è il punto con più rischio legale.

8. Segnali ad_user_data e ad_personalization. Nella scheda Consent di Tag Assistant verifica che dopo l'accettazione i due segnali passino a "granted" e non restino "not set". Esito atteso: entrambi coerenti con ad_storage. Gravità: alta per chi fa remarketing o enhanced conversions, perché Google Ads usa questi segnali per decidere cosa accettare.

Area 3: dati

9. dataLayer coerente. Confronta la struttura del dataLayer sulle pagine chiave con il documento di riferimento, se esiste, o con quella attesa dai tag. Come: scheda Data Layer in Tag Assistant, oppure dataLayer nella console del browser. Esito atteso: stessi nomi di evento e parametri su tutte le pagine dello stesso tipo, nessun push che arriva dopo il tag che dovrebbe leggerlo. Gravità: media, alta se tocca gli eventi di conversione.

10. Eventi duplicati. Cerca lo stesso evento inviato due volte a GA4: due tag sullo stesso trigger, un tag GA4 più uno gtag hardcoded nel tema, un evento ripetuto a ogni cambio di stato di una SPA. Come: GA4 DebugView, che mostra in tempo reale gli eventi raccolti da un utente e si attiva dal Preview di GTM o con il parametro debug_mode (fonte: DebugView GA4), più la scheda Network del browser filtrata su collect. Esito atteso: un solo hit per evento per interazione. Gravità: alta se duplica purchase o generate_lead, media altrimenti.

11. Parametri mancanti e dati personali. Per ogni evento importante elenca i parametri attesi e verifica in DebugView che arrivino valorizzati. Nello stesso passaggio cerca email, telefono, nome o codice fiscale dentro page_location, nei parametri custom e nei form listener. Esito atteso: parametri attesi presenti, nessun dato personale in chiaro. Gravità: media per i parametri mancanti, alta per i dati personali, che violano i termini di GA4 e possono richiedere la cancellazione dei dati.

12. Custom dimensions ed ecommerce. Confronta i parametri custom inviati con le dimensioni personalizzate registrate in GA4 (Admin, definizioni personalizzate). Un parametro inviato ma non registrato non compare nei report ed è il modo più comune di perdere dati in silenzio. Il metodo è in custom dimensions GA4, mappatura. Se c'è un ecommerce, verifica in DebugView che view_item, add_to_cart, begin_checkout e purchase portino l'array items con item_id, item_name, price e quantity, più transaction_id, value e currency sul purchase. Esito atteso: ogni parametro utile ha una dimensione registrata, gli eventi ecommerce sono completi, il purchase spara una sola volta per ordine. Gravità: media, alta sull'ecommerce. Il perimetro completo è nel servizio di tracking ecommerce.

Area 4: conversioni

13. Mapping key event GA4 e conversioni Google Ads. Elenca i key event in GA4 e le azioni di conversione in Ads, poi verifica l'origine di ciascuna: importata da GA4 o tag di conversione Ads in GTM. Esito atteso: ogni conversione ha un'unica fonte, nessuna doppia (import da GA4 più tag Ads sullo stesso evento) e le conversioni primarie in Ads sono quelle su cui vuoi ottimizzare. Gravità: alta, perché lo Smart Bidding ottimizza su quello che riceve.

14. Enhanced conversions e cross-domain. Per le enhanced conversions verifica in Tag Assistant che il tag di conversione Ads riceva i dati utente (email hashata o variabile user-provided data) e che in Ads la diagnostica risulti attiva. La procedura aggiornata è in enhanced conversions Google Ads e GA4, setup 2026. Per il cross-domain, con più domini nel percorso (sito, checkout esterno, pagamento), verifica che il parametro _gl compaia nei link tra domini e che in GA4 la sessione non riparta come referral dal secondo dominio. Il metodo di debug è in cross-domain tracking GTM, debug. Esito atteso: enhanced conversions attive dove previste, nessun self-referral. Gravità: alta se il checkout è su un dominio diverso.

Area 5: performance e sicurezza

15. Tag sincroni, terze parti, CSP, server-side. Dall'export JSON elenca i tag Custom HTML e le librerie esterne che caricano. Nella scheda Network misura quante richieste partono da GTM al caricamento e quali bloccano il rendering. Verifica se il sito ha una Content Security Policy e se GTM e i suoi tag la rispettano: con una CSP stretta i Custom HTML inline non partono senza nonce. Infine valuta se il server-side ha senso: quando il container manda dati a più destinazioni pubblicitarie, quando la perdita per ad blocker è alta o quando servono controlli sui dati in uscita. Esito atteso: nessun Custom HTML che potrebbe essere un tag nativo, richieste di terze parti giustificate, CSP rispettata. Gravità: media, alta se un Custom HTML inietta script da domini non controllati. Costi e benefici del server-side sono nel servizio GTM server-side.

Come documentare l'audit

Il documento finale è una tabella con una riga per anomalia, non un report narrativo. Chi deve fare i fix ha bisogno di ID, priorità e proprietario.

ID	Area	Anomalia	Gravità	Impatto sul dato	Fix proposto	Owner
C-03	Consent	Pixel Meta senza additional consent check, spara con rifiuto	Alta	Nessuno sul dato, rischio compliance	Aggiungere check su ad_storage al tag	Analyst
D-02	Dati	purchase inviato da tag GTM e da gtag nel tema	Alta	Ricavi GA4 raddoppiati sugli ordini	Rimuovere gtag dal tema, tenere GTM	Dev
D-04	Dati	Parametro lead_type inviato, nessuna dimensione registrata	Media	Parametro assente dai report	Registrare dimensione evento in GA4	Analyst
G-01	Governance	Utenti con Publish appartenenti a fornitori passati	Media	Rischio modifiche non tracciate	Rimuovere accessi	Owner account

Le righe sono esempi di formato, non risultati di un audit reale. Alla tabella aggiungo un inventario (tag per tipo e destinazione, tag in pausa, orfani) e un piano di rientro in tre lotti: prima le anomalie alte su consent e conversioni, poi le medie sul dato, infine governance e pulizia. Ogni lotto è una versione GTM separata con nota, così un rollback tocca una versione sola.

Errori che trovi quasi sempre

Per osservazione di lavoro, senza pretesa statistica, questi problemi ricorrono in gran parte dei container ereditati:

• Doppia implementazione GA4: tag in GTM più snippet gtag nel tema o in un plugin, con eventi duplicati e sessioni sdoppiate.
• CMP fuori dal trigger Consent Initialization: il banner parte dopo i tag e il default di consenso arriva tardi.
• Tag non Google senza consent check: Meta, LinkedIn e heatmap sparano indipendentemente dalla scelta dell'utente.
• Parametri custom mai registrati come dimensioni: mesi di dati inviati e mai visibili nei report.
• Conversioni Ads contate due volte: import da GA4 più tag di conversione nativo sullo stesso evento.
• Permessi Publish troppo diffusi: agenzie e freelance passati con accesso completo.

Quando l'audit non basta

L'audit descrive lo stato di un container rispetto a quello che dovrebbe fare. Se nessuno sa cosa dovrebbe fare, l'audit può solo elencare cosa esiste. Succede quando manca un piano di misurazione: gli eventi sono stati aggiunti uno alla volta su richiesta, senza un elenco di domande di business a cui i dati devono rispondere, e ogni conversione ha una definizione diversa a seconda di chi la guarda.

In quel caso il fix non è rimettere ordine tra i tag ma ripartire dal piano: quali decisioni vanno prese, quali eventi e parametri servono per prenderle, come si chiamano, chi li possiede. Il container viene ricostruito dal piano, non riparato pezzo per pezzo. Il modo in cui lo imposto è nella metodologia di tracking. Un segnale chiaro: più di un terzo delle anomalie in tabella ha come fix "da definire con il business".

Limiti della checklist

La checklist copre container web. I container server-side hanno un'interfaccia di debug diversa e punti di verifica propri (client, trasformazioni, destinazioni), quelli per app mobile non usano il Preview web. Le gravità sono indicative: un tag Meta senza consent check è alto per un ecommerce con remarketing e basso per un sito senza advertising. Infine l'audit fotografa un momento: con dieci pubblicazioni al mese il documento invecchia in poche settimane e va accompagnato da regole di governance, non solo da fix.

Se preferisci che l'audit lo faccia chi apre container ereditati per lavoro, perimetro e formato di consegna sono nel servizio di audit tracking GA4 e GTM.