Debug GA4: cosa fare quando gli eventi smettono di funzionare (senza panico)

Il primo passo del debug non è "aprire GA4 e mettersi a cliccare". È capire quale sintomo hai davanti. Tre casi base, con tre cause completamente diverse.

Caso uno: eventi a zero, ma il traffico c'è. Vedi sessioni regolari in Realtime ma le conversioni sono ferme. Significa che il tag GA4 base funziona, ma uno o più tag specifici (form, telefono, purchase) non partono. Problema di trigger o di evento singolo.

Caso due: anche il traffico è a zero. Niente sessioni, niente eventi, niente utenti in Realtime nonostante tu sappia che il sito sta ricevendo visite. Problema globale di tracking: il container GTM non parte, o il Measurement ID è sbagliato, o c'è un blocco Consent Mode esteso.

Caso tre: alcuni eventi funzionano, altri no. Tutti i form submit arrivano, ma i click sul telefono no. Problema circoscritto a un singolo trigger, di solito un cambio di codice HTML nel sito che ha cambiato la classe CSS o l'attributo a cui il trigger faceva riferimento.

DebugView è il primo posto dove guardare, sempre. È il pannello che ti mostra gli eventi in tempo reale, evento per evento, con tutti i parametri visibili. Per attivarlo ci sono tre modi: installare l'estensione Chrome "Google Analytics Debugger" e attivarla sul sito, attivare il Preview Mode di GTM (che mette automaticamente il flag debug), oppure aggiungere `?debug_mode=true` agli URL del sito.

Una volta attivato, vai su GA4 > Admin > DebugView, e vedi la lista dei "device" attivi in debug. Selezioni il tuo e ti compaiono gli eventi che stai generando navigando il sito, in tempo reale. Se navighi, clicchi sul form, clicchi sul telefono, e in DebugView non compare niente, allora il problema è chiarissimo: i tag non stanno partendo.

Se invece in DebugView vedi gli eventi che arrivano regolarmente, ma in "Reports > Realtime" non li vedi, il problema è downstream: forse Consent Mode che blocca l'invio, forse data quotas raggiunte, raramente un bug GA4. Ma sapere che gli eventi partono è già metà del lavoro.

Tag Assistant è l'estensione ufficiale di Google e fa due cose che servono insieme. Prima: ti mostra tutti i tag che sono attivi sulla pagina (GA4, Google Ads, Floodlight, Microsoft Clarity, eccetera) e ti dice se ognuno sta partendo correttamente. Seconda: integra il Preview Mode di GTM, e ti permette di vedere dentro al container quali trigger sono partiti, quali tag hanno aspettato, quali variabili erano popolate.

Apri Tag Assistant, attivi il debug sul tuo dominio, vai in Preview di GTM (Workspace > Preview), e navighi il sito in una finestra controllata. Nel pannello di Tag Assistant vedi ogni evento del data layer e per ogni evento la lista dei tag che si sono attivati o non si sono attivati, con il motivo. Se un tag non parte, Tag Assistant ti dice "trigger non soddisfatto", e puoi cliccare per vedere quale condizione del trigger è fallita.

Tag Assistant è particolarmente utile quando devi distinguere "il trigger non si attiva" da "il trigger si attiva ma il tag dà errore". Sono due cose diverse, con due fix diversi.

Quando DebugView e Tag Assistant non bastano, scendi più in basso: il Network tab dei DevTools di Chrome. Apri DevTools (F12), vai su Network, filtra per `collect` (è l'endpoint dove GA4 manda gli eventi), e naviga il sito. Per ogni evento GA4 vedi una request a `https://www.google-analytics.com/g/collect?...`.

Tre cose da controllare. Prima, la request c'è davvero? Se no, il tag non parte (e torni a Tag Assistant). Seconda, lo status code: 200 o 204 è OK, 4xx significa che la request è sbagliata (Measurement ID sbagliato, parametri malformati), 5xx significa che GA4 ha un problema lato server (raro). Terza, il payload della request: clicca sulla riga e guarda i parametri in "Payload" o "Request". Devi trovare `en` (event name), e tutti i parametri del tuo evento. Se manca un parametro che ti aspettavi, sai che la variabile GTM era vuota al momento del fire.

Il Network tab è anche dove scopri se Consent Mode sta bloccando le request. In Consent Mode v2, quando il consenso è denied, GA4 manda lo stesso una request ma con il parametro `gcs=G100` (signal denied). Se vedi `G111` o `G110` è denied, se vedi `G111` è granted. Se non vedi proprio request, è blocking totale.

Realtime di GA4 è meno granulare di DebugView ma è dove vedi cosa vede davvero il GA4 di produzione, senza il debug mode. Vai su Reports > Realtime e guardi utenti attivi negli ultimi 30 minuti, eventi correnti, sorgenti di traffico, location geografica.

Se in DebugView vedi gli eventi e in Realtime no, qualcosa li sta filtrando. Possibili cause: filtri internal_traffic che escludono il tuo IP (in quel caso da casa li vedresti), Consent Mode che li manda ma li marca come denied (vanno in "Modelled" non in Realtime), property GA4 sbagliata (stai guardando il Realtime di una property diversa). Realtime è il giudice finale: se gli eventi arrivano lì, il setup è OK per la produzione.

Ordine operativo, quello che faccio nel mio lavoro tutti i giorni. Step 1: apri DebugView e simula l'azione che dovrebbe generare l'evento. Se non lo vedi, problema di tag. Step 2: apri Preview GTM e Tag Assistant, ricontrolla in modalità debug. Vedi quale trigger non parte e perché. Step 3: se il trigger parte ma il tag no, vai nel Network tab e cerca la collect request, controlla payload e status. Step 4: se la request parte ma il dato arriva sbagliato, vai a guardare il data layer (`dataLayer` in console di Chrome) e controlla che il valore sia quello che ti aspetti, nel formato corretto.

Step 5: controlla lo stato di Consent Mode. In Tag Assistant guarda i flag `gcs` e `gcd`, oppure in console controlla `google_tag_data.ics.usedDefault`. Se Consent Mode è in stato di blocco, gli eventi non partono per davvero, partono ma vengono filtrati. Step 6: se ancora non hai trovato nulla, confronta il setup attuale con uno che funzionava (snapshot di GTM workspace di una settimana fa). Quasi sempre il problema è in un cambio recente.

Lista ordinata per frequenza. Uno: data layer non popolato (il CMS è stato aggiornato e ha cambiato la struttura del push, oppure il tema WordPress è cambiato). Fix: aggiorni le variabili GTM ai nuovi nomi. Due: trigger su elementi DOM che non esistono più (un click su `.btn-submit` dopo che il sito ha cambiato la classe a `.button-primary`). Fix: aggiorni il selettore del trigger.

Tre: Consent Mode che blocca tutto (un aggiornamento del plugin CMP ha resettato i default a denied per tutti). Fix: controllo lo stato di default e l'integrazione con la CMP. Quattro: GTM container non pubblicato (qualcuno ha fatto modifiche in workspace ma non ha cliccato Submit > Publish). Fix: pubblichi il container, e la prossima volta ti annoti tutti i Submit nel changelog. Cinque: typo nel tag (nome evento con un underscore in più, Measurement ID copiato male). Fix: vai a vedere il tag e correggi.

Dopo 30 minuti di debug senza aver trovato la causa, fermati. È il momento di chiedere aiuto a qualcuno che vede setup come il tuo tutti i giorni e che riconosce i pattern in pochi minuti. Soprattutto se il debug coincide con cambi recenti su WordPress, Shopify, plugin CMP, o se è seguito a una migrazione di sito: in questi casi le cause si annidano in posti non ovvi e la conoscenza dei dettagli vale più del manuale.

Vale anche un'altra regola: se gli eventi sono fermi da più di una settimana e tu hai campagne attive, ogni giorno che passa stai bruciando budget pubblicitario senza dati di ottimizzazione. Chiama, 329 128 68 25, il costo del debug si ripaga in due giorni di Smart Bidding che torna a vedere. Per il quadro più ampio su come tenere il tracciamento sotto controllo c'è la checklist di audit del tracciamento in dieci punti, e per evitare uno dei problemi più frequenti l'integrazione corretta del cookie banner con GTM. Tutto il resto sta nelle categorie tracciamento e analytics, strumenti per l'advertising, e nei servizi di Google Ads e Meta e siti web SEO e AI.

• Audit del tracciamento web: la checklist in dieci punti
• Cross-domain tracking in GA4
• E-commerce tracking in GA4: l'oggetto items