Come implementare GA4: eventi, conversioni ed errori

Di tutti gli audit di analytics che abbiamo fatto, non abbiamo ancora trovato un’installazione di GA4 perfetta. Nemmeno una. Il quadro tipico: eventi duplicati che gonfiano le metriche, un consent mode configurato male che scarta metà dei dati, e conversioni non definite — con le campagne paid che ottimizzano alla cieca.

E il problema è serio: tutto il growth marketing si regge sui dati. Se il tracking è rotto, ogni test A/B, ogni decisione di budget e ogni dashboard costruita sopra sono contaminati. In questa guida spieghiamo come implementare GA4 bene: il modello a eventi, cosa misurare, come impostarlo con Google Tag Manager e gli errori che vediamo ripetersi in quasi tutti gli account.

Perché la maggior parte delle installazioni GA4 è rotta

Tre cause spiegano il 90% dei disastri che verifichiamo negli audit:

1. Dati duplicati. La combinazione classica: lo snippet di gtag.js incollato nel template e GA4 che si attiva anche da Google Tag Manager. Risultato: due page_view per pagina, conversioni doppie e rapporti che non tornano con il business. Succede anche con i plugin dei CMS che “includono già analytics” e convivono con il tag manuale.
2. Consent mode impostato male (o assente). Da marzo 2024, il consent mode v2 è obbligatorio per usare le audience e il remarketing di Google nel SEE. Lo vediamo implementato male di continuo: il banner dei cookie blocca GA4 completamente (perdita totale dei dati di chi rifiuta), oppure il contrario, attiva tutto senza aspettare il consenso (problema legale).
3. Conversioni non definite. GA4 non sa cosa è importante per il tuo business. Se nessuno contrassegna gli eventi come conversione (key events), Google Ads ottimizza verso i clic, i report non rispondono a domande di business e “avere analytics” si riduce ad avere un contatore di visite.

La buona notizia: niente di tutto questo è difficile da sistemare. Il difficile è accorgersene, perché un tracking rotto produce numeri belli quanto uno sano.

Il modello a eventi di GA4: dimentica le categorie di Universal Analytics

Se vieni da Universal Analytics, la prima cosa da fare è disimparare. UA aveva tipi di hit diversi (pageview, eventi con categoria/azione/etichetta, transazioni). In GA4 tutto è un evento con parametri:

evento: sign_up
parametri: { method: "google", plan: "free" }

Questo ha due implicazioni pratiche:

• Non mettere l’informazione nel nome dell’evento. click_bottone_verde_home è un anti-pattern; la cosa giusta è un evento generico (cta_click) con parametri (location: "home", cta_text: "..."). Meno eventi, più parametri.
• I parametri personalizzati non compaiono nei report per magia. Bisogna registrarli come dimensioni o metriche personalizzate nella proprietà. È la dimenticanza più comune: eventi ricchi di parametri che nessuno può consultare.

GA4 inoltre include eventi automatici (page_view, session_start) e di misurazione avanzata (scroll, click in uscita, file_download, video_start…). Esaminali prima di creare i tuoi: non misurare a mano ciò che è già incluso di serie.

Cosa misurare: un piano di misurazione legato al funnel

L’errore di fondo di solito non è tecnico ma di progettazione: misurare senza un piano. Il nostro punto di partenza è sempre lo stesso: un evento ben definito per ogni fase del funnel AARRR.

Il piano di misurazione è un documento (basta un foglio di calcolo) con: nome dell’evento, quando si attiva, parametri, chi lo consuma e per quale decisione. Se un evento non ha una risposta a “quale decisione alimenta?”, non si implementa. Dieci eventi documentati valgono più di cento improvvisati.

Implementazione con Google Tag Manager

La nostra raccomandazione di default: un solo punto di ingresso (GTM) e un dataLayer ben popolato. Niente gtag.js hardcoded che convive con il container.

• Il dataLayer è il contratto tra sviluppo e marketing. Il team di prodotto fa il push degli eventi con i loro parametri (dataLayer.push({event: "sign_up", method: "google"})) e GTM li traduce in tag. Così il tracking sopravvive ai redesign: non dipende da classi CSS né da selettori fragili.
• Convenzioni di naming dal giorno uno: sempre snake_case (GA4 distingue le maiuscole: sign_up e Sign_Up sono due eventi diversi), verbi in inglese coerenti con gli eventi raccomandati da Google (sign_up, purchase, generate_lead) e prefissi per gli eventi custom se aiutano (sw_ per quelli propri). Tutto documentato nel piano di misurazione.
• Ambienti e versioni: GTM permette di testare in preview, pubblicare con versioni e fare rollback. Usalo. Una modifica al tracking senza test è un incidente di dati in attesa di una data.

Conversioni e audience

Con gli eventi che fluiscono, restano due passi che quasi nessuno fa:

1. Contrassegna come conversione (key event) solo ciò che è business: lead, registrazione, acquisto, richiesta di demo. Contrassegnare scroll o page_view come conversione distrugge l’utilità del dato e confonde Google Ads. Tra 3 e 5 conversioni ben scelte è la norma.
2. Costruisci audience basate sul comportamento: utenti che si sono attivati ma non hanno pagato, carrelli abbandonati, visitatori della pagina pricing senza conversione. Esportate su Google Ads, trasformano la tua analytics in muscolo di remarketing e similar audience. È la parte di GA4 che paga il conto.

Consent mode v2 e la perdita di dati

Con il consent mode v2 implementato bene, quando l’utente rifiuta i cookie GA4 invia ping anonimi (senza cookie) invece di non inviare nulla. Con questi, Google applica il modeling di comportamento e conversioni: stima statisticamente i dati di chi ha rifiutato, a partire dai pattern di chi ha accettato.

Quello che bisogna accettare: perderai granularità in ogni caso. Con tassi di rifiuto del 20-40% abituali in Europa, i tuoi numeri assoluti sono parzialmente modellati. Le implicazioni pratiche:

• Configura il consent mode in modalità avanzata (ping anonimi) e non in quella base (blocco totale) se vuoi che il modeling funzioni.
• Tratta GA4 come strumento direzionale: trend e confronti affidabili, cifre assolute approssimative.
• La fonte di verità del business (vendite, lead) deve essere il tuo backend o CRM, mai lo strumento di analytics.

Quando fare il passo successivo: server-side e product analytics

GA4 client-side ben impostato copre molto, ma ha un tetto:

• Tracking server-side (GTM Server-Side): ha senso quando adblocker e ITP si mangiano una parte rilevante dei dati e l’investimento in paid giustifica recuperarla, o quando vuoi arricchire gli eventi con dati di backend e controllare cosa condividi con ogni piattaforma. È infrastruttura: richiede ingegneria, non solo configurazione.
• Strumento di product analytics (PostHog, Mixpanel, Amplitude): quando le domande smettono di essere di marketing (“quale canale converte?”) e diventano di prodotto (“cosa fanno gli utenti che restano e non fanno quelli che se ne vanno?”). Coorti flessibili, funnel ad hoc, session replay e feature flag — terreno dove GA4 non arriva.

La combinazione abituale nelle aziende con prodotto digitale: GA4 per marketing e campagne + uno strumento di prodotto per il comportamento. Se sei a quel punto, è esattamente ciò che costruiamo nel nostro servizio di data & analytics.

Checklist di audit GA4

Prima di dare il tracking per buono:

• Un unico punto di attivazione (GTM o gtag, non entrambi) e nessun page_view duplicato in DebugView
• Piano di misurazione documentato: eventi, parametri, owner e decisione che alimentano
• Convenzione di naming coerente (snake_case, eventi raccomandati da Google dove esistono)
• Parametri personalizzati registrati come dimensioni/metriche personalizzate
• Conversioni (key events) definite: solo eventi di business, tra 3 e 5
• Consent mode v2 in modalità avanzata, verificato con il banner accettando e rifiutando
• Retention dei dati portata da 2 a 14 mesi (di default è a 2)
• Traffico interno e di sviluppo filtrato
• Collegamento con Google Ads e Search Console attivo
• Verifica in DebugView e Realtime dopo ogni pubblicazione di GTM

Errori comuni (e come evitarli)

Conclusione

Implementare GA4 bene non è incollare uno snippet: è progettare un piano di misurazione legato al funnel, eseguirlo con disciplina ingegneristica (dataLayer, convenzioni, versioni, verifica) e accettare onestamente i limiti del dato con consenso. La differenza tra farlo bene e farlo così così non si vede sul sito — si vede tre mesi dopo, quando le decisioni prese con quei dati funzionano oppure no.

E se c’è una cosa che abbiamo imparato facendo audit: costa molto meno impostare il tracking bene una volta che decidere per sei mesi su dati rotti.

Sospetti che il tuo GA4 stia misurando male? Lo verifichiamo e lo mettiamo a punto →