Le 5 cose che controllo sempre per prime quando metto mano a un progetto altrui.
Quando prendo in mano un progetto web già esistente, la prima cosa che faccio non è guardare il design né il codice. Vado su Google Analytics 4. E quasi sempre quello che trovo mi conferma una cosa: GA4 è stato installato, ma non configurato. O peggio, è stato configurato male due volte.
Non è una questione di incompetenza. GA4 è uno strumento complesso, cambiato radicalmente rispetto a Universal Analytics, e la maggior parte delle guide online si fermano al “copia il Measurement ID e incollalo nel sito.” Il risultato? Dati che sembrano corretti ma non lo sono. Dashboard che danno una sensazione di controllo che non esiste.
Diverse analisi di settore mostrano che gli errori di configurazione GA4 sono molto frequenti, soprattutto su eventi custom, GTM e tracciamenti duplicati. Non è un caso isolato: è uno dei problemi più sottovalutati nel web professionale, proprio perché GA4 non avvisa quando qualcosa va storto.
Queste sono le cinque cose che controllo sempre per prime.
1. Doppio tracking: il problema invisibile che gonfia tutto
Questo è in assoluto l’errore più frequente e il più difficile da riconoscere se non sai cosa cercare.
Succede quando GA4 riceve due volte lo stesso evento dalla stessa sessione. Il segnale tipico: le pageview sono esattamente il doppio di quello che ti aspetti. Non approssimativamente, esattamente. Una differenza del 100% netta è quasi sempre doppio tracking.
Come si genera? I casi più comuni sono:
- Un plugin WordPress (Rank Math, MonsterInsights, Site Kit) che invia il tag GA4 direttamente, mentre esiste già un container GTM configurato per lo stesso Measurement ID.
- Il tag
gtag.jshardcodato nel tema, rimasto lì dopo che qualcuno ha aggiunto GTM per gestire il tracking. - Due container GTM attivi sullo stesso sito, uno del developer originale e uno aggiunto da un’agenzia successiva.
- Enhanced Measurement di GA4 attivato su eventi (scroll, click uscenti) che sono stati anche configurati come eventi custom in GTM.
Google non deduplica nulla in automatico. Se arrivano due pageview, registra due pageview. Il dato è confermato dalla documentazione ufficiale GTM e da Analytics Mania (2025).
Come lo verifico: apro il Network tab del browser in DevTools e filtro per “collect”. Se vedo due richieste in uscita verso analytics.google.com con lo stesso Measurement ID su ogni caricamento di pagina, il doppio tracking è confermato. In alternativa, uso GA4 DebugView mentre naviguo il sito: se ogni azione produce due eventi identici in sequenza immediata, il problema c’è.
Fix: identifico quale dei due sistemi è quello autorizzato (solitamente GTM) e disattivo o rimuovo l’altro. Se uso GTM, rimuovo qualsiasi script gtag.js hardcodato nel tema. Se uso un plugin, mi assicuro che GTM non stia inviando lo stesso evento in parallelo.
2. Data retention a 2 mesi: perdere dati senza saperlo
Questo è il classico errore che si scopre solo quando è troppo tardi.
GA4 standard ha una retention di default di 2 mesi per i dati a livello utente ed evento negli Exploration report. Il massimo configurabile nella versione gratuita è 14 mesi. Durate superiori (26, 38 o 50 mesi) sono disponibili solo con GA360. (Fonte: documentazione ufficiale Google Analytics, verificabile in Admin > Data Settings > Data Retention.)
È importante chiarire cosa significa nella pratica: i report standard (Acquisizione traffico, Pagine e schermate) usano dati aggregati e non sono influenzati da questa impostazione. Sono le Explorations, i funnel personalizzati, i path analysis e le analisi su segmenti custom che smettono di funzionare oltre la finestra di retention. Ed è esattamente lì che si trovano le analisi più utili.
Il momento in cui ci si accorge del problema è quando si vuole fare un confronto anno su anno in un’Exploration. Quei dati non ci sono più. E l’impostazione non è retroattiva: portarla da 2 a 14 mesi conserva i dati da quel momento in poi, non recupera quelli già cancellati.
Come lo verifico: vado in Admin > Data Settings > Data Retention. Se trovo “2 months” su “Event data retention”, è da correggere immediatamente.
Fix: porto a 14 mesi e attivo “Reset user data on new activity”. Per esigenze oltre i 14 mesi, l’export BigQuery è l’unica soluzione disponibile nella versione gratuita. Per siti con volume consistente, lo attivo subito come salvaguardia.
3. PII nei dati: il rischio legale che nessuno vede
Questo punto non riguarda solo la qualità dei dati, riguarda la conformità al GDPR e ai Termini di Servizio di Google.
GA4 vieta esplicitamente la raccolta di Personally Identifiable Information (PII): nomi, email, numeri di telefono, codici fiscali. Se Google rileva PII in una property, può cancellare tutti i dati di quella property. E il GDPR prevede sanzioni proprie per la trasmissione non autorizzata di dati personali a piattaforme terze. (Fonte: Google Analytics Terms of Service, Sezione 7 – Privacy.)
Il problema è che la PII non arriva intenzionalmente. Arriva per come è costruito il sito:
- Un form di contatto che, dopo il submit, reindirizza a
/[email protected]sta passando quell’email nell’URL, che GA4 registra come page location. - Un sito di login che include lo username nell’URL della pagina profilo.
- Parametri query generati da CRM o piattaforme esterne che contengono ID cliente leggibili.
- Form dove il valore del campo viene tracciato come parametro di un evento custom, invece di registrare solo il submit.
Come lo verifico: vado in Reports > Engagement > Pages and Screens e cerco URL che contengano @, email=, tel=, nomi propri in query string. Controllo anche il Realtime report mentre compilo i form del sito.
Fix: la soluzione migliore è evitare che dati personali vengano inseriti negli URL o inviati come parametri degli eventi. GA4 include una funzione nativa chiamata Data Redaction che intercetta indirizzi email e parametri query personalizzati prima che raggiungano i server di Google, accessibile in Admin > Data Streams > Data Redaction. Per implementazioni più complesse, è possibile filtrare i parametri tramite Google Tag Manager prima che vengano inviati ad Analytics. Quando possibile, il flusso applicativo dovrebbe essere progettato in modo che nomi, email e altri dati personali non vengano mai trasmessi a GA4. (Fonte: documentazione ufficiale Google Analytics, support.google.com/analytics/answer/13544947.)
4. Traffico interno non filtrato: i dati del team dentro i report
Ogni volta che il team sviluppa, testa, naviga il sito con il proprio IP, quelle sessioni entrano in GA4 come traffico reale. Su siti piccoli o in fase di lancio, il traffico interno può rappresentare una percentuale significativa del totale, distorcendo engagement rate, sessioni e conversioni.
GA4 non esclude il traffico interno per default. Richiede una configurazione esplicita.
L’errore più comune: il filtro viene creato ma lasciato in modalità “Testing” invece di “Active”. In modalità Testing i dati vengono taggati ma non esclusi dai report. Il risultato è la stessa situazione di prima, con l’illusione di avere il filtro attivo.
Come lo verifico: vado in Admin > Data Filters. Controllo che esista un filtro Internal Traffic in stato “Active” (non “Testing”). Poi vado in Admin > Data Streams > Configure Tag Settings > Define Internal Traffic e verifico che gli IP siano inseriti correttamente, compresi VPN aziendali e IP delle agenzie che lavorano sul progetto.
Fix: se il filtro non esiste, lo creo. Se è in stato Testing, lo passo ad Active. Se gli IP aziendali sono dinamici, valuto l’uso di un parametro traffic_type impostato via cookie o GTM per identificare il traffico interno senza dipendere dall’IP fisso.
5. Key events / Conversioni non configurati correttamente
Questa è la categoria di errore più ampia e quella con più variazioni, ma si riduce a due scenari opposti: nessuna conversione configurata, o tutte le conversioni configurate.
Nel primo caso GA4 raccoglie eventi ma non sa quali siano i successi. Non c’è modo di misurare il rendimento reale del sito.
Nel secondo caso, capita quando si seleziona “segna come conversione” su eventi come page_view, scroll, session_start. GA4 mostra migliaia di conversioni al giorno che non significano nulla, e Google Ads, se collegato, ottimizza su segnali che non corrispondono a nessuna azione di valore reale.
Una nota sull’interfaccia: GA4 sta progressivamente spostando la terminologia da “conversioni” a “key events” per le metriche interne di Analytics. Il concetto è lo stesso: un evento va marcato come key event quando rappresenta un’azione importante per il business. Le conversioni nel senso di Google Ads rimangono separate. (Fonte: documentazione Google Analytics, 2024-2025.)
Un key event dovrebbe rappresentare un’azione con valore di business verificabile: compilazione di un form, acquisto completato, download di un documento, click su un numero di telefono. Non il fatto che qualcuno abbia caricato una pagina o scrollato.
Come lo verifico: vado in Admin > Events e guardo quali eventi hanno il toggle “Mark as key event” attivato. Se vedo page_view, scroll, o first_visit tra i key event, il setup è da rivedere. Se non c’è nessun key event, chiedo al cliente quali sono le azioni di valore sul sito e le configuro.
Fix: definisco con il cliente 3-5 azioni chiave con valore di business verificabile. Configuro quelle come key event. Rimuovo il tag da tutti gli eventi generici.
Nota finale
Questi cinque punti non coprono tutto quello che si può controllare in un audit GA4 completo. Ci sono problemi di cross-domain tracking, configurazioni errate di Google Signals, attribution model non allineati agli obiettivi di business, e molto altro.
Ma questi cinque sono quelli che trovo quasi sempre. Sono quelli che causano il danno maggiore perché rimangono invisibili: GA4 non lancia errori, continua a mostrare dati, e chi guarda il report non ha modo di sapere che quei dati non sono affidabili.
Sistemarli richiede meno di due ore su un progetto medio. Non sistemarli significa prendere decisioni su dati sbagliati, a volte per mesi o anni.
