Setup GA4 fatto come si deve: eventi nativi, conversioni e dati di cui ti puoi fidare

Il problema

C’è una differenza enorme fra “ho GA4 che gira” e “GA4 è utile al business”. La maggior parte delle property che audito raccoglie dati tutti i giorni — e quasi tutte hanno almeno uno di questi problemi sotto la superficie:

• Eventi ereditati da Universal Analytics: la migrazione è stata fatta traducendo categoria/azione/etichetta in eventi custom (click_addtocart, acquisto_completato). GA4 li raccoglie, ma non li riconosce: i report e-commerce restano vuoti e Google Ads non ha segnali puliti su cui ottimizzare.
• Eventi e-commerce senza parametri items: il purchase parte, ma senza l’array items con item_id, item_name, price e quantity. Risultato: revenue totale visibile, performance per prodotto inesistente.
• Conversioni mai configurate: nessun evento marcato come key event, oppure marcati tutti — che è lo stesso problema al contrario.
• Impostazioni di property lasciate al default: data retention a 2 mesi (e le Explore che non vanno più indietro di così), cross-domain non configurato, traffico interno non filtrato.
• Collegamenti mancanti: Google Ads e Search Console non collegati, quindi niente import conversioni, niente audience, niente query organiche dentro GA4.

Il punto è che un setup GA4 sbagliato non dà errori. Raccoglie numeri, i grafici si muovono, tutto sembra funzionare. Te ne accorgi solo quando provi a prendere una decisione — un budget da spostare, un prodotto da spingere — e i dati non reggono la domanda.

Come lavoro

1. Audit della property esistente

Prima di toccare qualsiasi cosa, fotografo lo stato attuale: eventi in arrivo (DebugView e report), parametri presenti e mancanti, key events configurati, impostazioni di property (retention, signals, internal traffic, referral exclusion), collegamenti attivi. Se il setup è ereditato da Universal Analytics, mappo cosa è recuperabile e cosa va rifatto. Ti consegno l’elenco dei problemi in ordine di impatto — e se il setup è già a posto, te lo dico e finisce lì.

2. Data model: eventi nativi GA4

Definisco gli eventi sulla tassonomia standard di GA4, non su nomi inventati: view_item, view_item_list, add_to_cart, begin_checkout, add_payment_info, purchase, più gli eventi custom che servono davvero al tuo business. Per ogni evento specifico i parametri obbligatori — in particolare l’array items completo, che è quello che rende utilizzabili i report e-commerce e gli export. Il documento è la spec che il dataLayer dovrà rispettare.

3. Implementazione via GTM

Configuro i tag GA4 nel container (o lo sistemo, se esiste già — vedi il servizio GTM Implementation): mapping dei parametri dal dataLayer, registrazione delle custom dimensions e custom metrics in property, gestione di user_id e consent. Tutto in un workspace separato, niente modifiche al container live finché non è testato.

4. Configurazione della property

La parte che i setup “veloci” saltano sempre:

• Key events marcati sugli eventi che contano davvero (non tutti).
• Data retention portata a 14 mesi.
• Cross-domain measurement se il funnel attraversa più domini (sito → checkout → payment).
• Filtro traffico interno e developer traffic.
• Collegamento Google Ads (import conversioni e audience) e Search Console.
• Audience di base per remarketing e analisi.

5. QA contro la realtà

Verifico ogni evento in DebugView e nei report, ma soprattutto confronto i purchase di GA4 con gli ordini reali del backend su una finestra di giorni. Se c’è uno scarto, lo misuro e lo spiego (consent, ad-blocker, duplicati) invece di far finta che non esista. Il QA finisce quando lo scarto è noto e documentato, non quando “i numeri sembrano giusti”.

6. Handover e documentazione

Una sessione con chi userà GA4 ogni giorno: dove trovare gli eventi, come leggere i report e-commerce, come funzionano le Explore costruite per te. Più il documento che descrive tutto il setup, scritto per chi arriverà dopo di me.

Cosa ricevi a fine progetto

• Property GA4 configurata e in produzione: eventi nativi, key events, retention, cross-domain, filtri.
• Documento di data model: spec degli eventi e dei parametri con esempi JSON, incluso l’array items.
• Custom dimensions e metrics registrate e documentate.
• Collegamenti Google Ads e Search Console attivi e verificati.
• QA report con il confronto fra dati GA4 e ordini backend, scarti misurati e spiegati.
• Explore di partenza (funnel e-commerce, path analysis) pronte all’uso.
• Sessione di handover registrata, se vuoi rivederla.
• 30 giorni di supporto post-release: se qualcosa non gira, intervengo subito.

Tempi e costi

• Durata: 1–3 settimane dall’avvio al go-live.
• Prezzo: da 1.200€. Il prezzo sale con il numero di eventi custom, lo stato del dataLayer (se va riscritto, è un lavoro in più), il numero di domini da coprire e l’eventuale attivazione dell’export BigQuery.
• Pagamento: 50% all’avvio, 50% al go-live.