Apri GA4 il lunedì mattina e trovi le sessioni del fine settimana quasi raddoppiate. Hai pubblicato il container server venerdì pomeriggio, l’anteprima mostrava gli eventi in arrivo, e adesso non sai se il dato gonfiato sia un errore tuo o un effetto normale del passaggio. Non è normale, ha una causa precisa, e nove volte su dieci è sempre la stessa.
Cosa cambia davvero nel flusso dei dati
Prima dello switch il browser invia la richiesta di misurazione direttamente agli endpoint di Google. Dopo, la stessa richiesta parte dal browser verso un tuo sottodominio (per esempio sgtm.tuodominio.it), entra nel container server, viene ricostruita come evento e solo a quel punto viene inoltrata a Google.
I ruoli sono tre e conviene tenerli distinti. Il tag Google nel container web decide dove mandare la richiesta, tramite il parametro server_container_url. Il Client GA4 nel container server riconosce quella richiesta, la rivendica e la trasforma in un evento leggibile. Il tag GA4 nel container server prende quell’evento e lo spedisce alla proprietà.
Cosa non cambia: il Measurement ID resta identico, la proprietà GA4 resta la stessa, lo storico non si tocca, il Data Layer del sito non va riscritto. Se qualcuno ti dice che devi creare una nuova proprietà per passare al server-side, sta sbagliando.
Il malinteso più diffuso riguarda il container server stesso: non osserva nulla, non rileva click né scroll, non ha accesso alla pagina. Elabora soltanto ciò che qualcuno gli manda. Se un evento non parte dal browser, lato server non esiste. Se questa logica ti è ancora confusa, parti dalla differenza tra tracciamento client side e server side prima di procedere.
Prerequisiti: cosa deve essere pronto prima di toccare un tag
Container server raggiungibile. Apri l’URL di tagging seguito da /healthz: devi ottenere una risposta ok. Se non la ottieni, fermati qui: nessuna configurazione a valle funzionerà.
Dominio personalizzato di primo livello. Un sottodominio del tuo sito, non un dominio di un fornitore terzo. È il punto che determina metà dei benefici: cookie impostati in contesto first-party, minore esposizione alle liste di blocco, coerenza con il dominio principale. Se non l’hai ancora impostato, segui la procedura per configurare il dominio personalizzato del container server e verifica che il certificato sia valido prima di andare avanti.
Accesso in modifica sia al container web sia a quello server, e accesso alla proprietà GA4 con diritti di editor per leggere DebugView e creare annotazioni.
Consenso già implementato lato client. Il Consent Mode continua a funzionare, perché gli stati del consenso viaggiano nella richiesta in ingresso e il tag GA4 server li rispetta. Rimandarlo a dopo lo switch significa dover rifare la validazione due volte.
Baseline numerica. Esporta da GA4 gli ultimi 14 giorni: utenti, sessioni, eventi chiave per nome, acquisti e revenue, suddivisi per giorno. Mettili in un foglio. Senza questo file non potrai dire se dopo lo switch i numeri sono giusti, e lavorerai a sensazione.
I 7 passaggi della configurazione
1. Attiva il Client GA4 nel container server. È il componente che rivendica le richieste in arrivo. Lascia i percorsi predefiniti attivi se il sito usa gtag.js standard. Se hai più client, controlla le priorità: il primo che rivendica la richiesta vince.
2. Imposta server_container_url nel tag Google. Nel container web apri il tag Google (quello con il Measurement ID), vai nei parametri di configurazione e aggiungi server_container_url con il valore del tuo sottodominio, completo di https://. Senza barra finale.
3. Decidi se servire anche gtag.js dal tuo dominio. Con transport_url indirizzi solo le richieste di misurazione; servendo anche lo script dal tuo sottodominio riduci ulteriormente la superficie bloccabile, ma aggiungi richieste al container e un passaggio di configurazione in più. Per un sito vetrina puoi saltarlo, su un e-commerce con traffico a pagamento vale la pena.
4. Crea il tag GA4 nel container server. Tipo "Google Analytics: evento GA4", imposta l’eredità dall’evento in ingresso per nome evento e parametri, trigger su tutti gli eventi del Client GA4. Non ricostruire manualmente i parametri: li stai già ricevendo.
5. Verifica in Anteprima lato server. Apri l’anteprima del container server, naviga il sito con l’anteprima web attiva e controlla tre cose per ogni evento: che compaia una sola volta, che il client corretto lo abbia rivendicato, che il tag GA4 risponda con codice 2xx. Guarda la scheda dei parametri in uscita, non solo quelli in ingresso.
6. Pubblica prima il server, poi il web. Se pubblichi prima il container web, per qualche minuto le richieste arrivano a un container che non sa ancora cosa farne e vanno perse. Nell’ordine inverso, al massimo hai un container server pronto che non riceve nulla.
7. Monitora le prime 72 ore. Tempo reale nei primi minuti, DebugView per i dettagli dei parametri, confronto giornaliero con la baseline dal giorno successivo. Metti un’annotazione in GA4 con la data dello switch: fra sei mesi ti servirà.
Doppio conteggio: le quattro cause reali
Quasi tutti i casi di eventi raddoppiati rientrano in quattro schemi.
Il tag GA4 lato client è ancora attivo. È la causa numero uno. Hai aggiunto server_container_url al tag Google, ma hai lasciato attivi anche i vecchi tag evento GA4 nel container web che puntano direttamente a Google. Risultato: ogni evento arriva due volte, le sessioni gonfiano, il tasso di conversione crolla. Correzione: metti in pausa i tag evento GA4 lato client, non eliminarli subito.
Più tag server sullo stesso evento in ingresso. Hai creato un tag GA4 "catch all" e un secondo tag specifico per purchase: entrambi si attivano sull’evento acquisto. Controlla i trigger, non i tag.
Configurazioni discordanti. Il tag Google ha il server_container_url, un tag evento GA4 nel container web ha una sua impostazione che punta altrove. Allinea tutto sul tag Google.
Misurazione avanzata attiva su eventi già inviati. Scroll, click uscenti e ricerca interna possono essere generati sia dalla misurazione avanzata sia da tag tuoi che li reinviano lato server. Scegli una sola sorgente per evento.
Qui ti do un’opinione netta: tenere client e server attivi in parallelo sulla stessa proprietà "per sicurezza" è la scelta peggiore possibile. Non ottieni una rete di protezione, ottieni dati sporchi su entrambi i canali e nessun modo di capire quale dei due sia affidabile. Se vuoi una fase di convivenza, usa una seconda proprietà GA4 di test collegata solo al tag server: confronti i due flussi in parallelo, e quando i numeri combaciano sposti il Measurement ID di produzione.
La verifica deve essere numerica, non visiva. Prendi i 7 giorni successivi allo switch, esporta eventi per nome e per giorno, metti a confronto con la baseline. Uno scostamento contenuto è fisiologico (cambiano deduplica, bot filtering, timing delle richieste). Un evento che raddoppia o che sparisce è un errore di configurazione: fermati e correggi prima di procedere.
Quando purchase non arriva e add_to_cart sì
Sintomo classico sugli e-commerce. La causa nella maggior parte dei casi è l’ordine di esecuzione: l’evento purchase parte nella thank you page prima che il tag Google si sia caricato, quindi non eredita il server_container_url e viene spedito direttamente a Google come prima.
Per diagnosticarlo apri l’anteprima web nella pagina di conferma ordine e guarda la sequenza dei tag: se il tag evento purchase compare prima del tag Google, hai trovato il problema. Le soluzioni sono tre: sequenziamento (il tag Google come tag di attivazione), priorità di attivazione più alta per il tag Google, oppure trigger su evento Data Layer dedicato invece che su Page View.
Se l’evento arriva ma i dati sono incompleti, il problema è a monte. Nell’anteprima server controlla che items contenga l’array completo, che value e currency siano valorizzati e che transaction_id sia presente e univoco. Quando il numero di acquisti in GA4 non torna con il gestionale, il colpevole è quasi sempre un transaction_id duplicato o un refresh della thank you page. Se il Data Layer del sito è disallineato rispetto a questo schema, il server-side non lo aggiusta: leggi perché il Data Layer è il punto di partenza di ogni tracciamento e sistemalo prima.
I parametri che cambiano dopo lo switch
Alcune variazioni nei report sono previste e generano falsi allarmi.
IP e geolocalizzazione. La richiesta a Google parte dal container, quindi serve che l’IP del client originale venga inoltrato. Se vedi tutti gli utenti concentrati in una sola città o regione, il parametro con l’IP non sta passando: è il primo controllo da fare.
User agent e dati del dispositivo. Stessa logica: se nei report spariscono i dettagli su browser e sistema operativo, vanno inoltrati esplicitamente dall’evento in ingresso.
Referral e self-referral. Il tuo sottodominio di tagging non deve comparire tra le sorgenti. Aggiungilo all’elenco di esclusione dei referral nelle impostazioni di raccolta dati GA4 prima di pubblicare, non dopo aver visto il traffico sporco.
Cookie di prima parte. Il _ga impostato dal container server in risposta HTTP non è soggetto alle stesse limitazioni di durata dei cookie scritti via JavaScript. In pratica, meno utenti riconosciuti come nuovi a ogni ritorno e attribuzione più stabile sulle campagne, che è il motivo per cui il server-side incide sui risultati di Google Ads.
Consenso. Gli stati di analytics_storage e ad_storage arrivano al container nella richiesta. Con consenso negato, il comportamento resta quello dei ping senza cookie: il server non aggira nulla e non deve farlo.
Checklist di validazione in 12 controlli
/healthzrispondeoksul dominio di tagging.- Il certificato del sottodominio è valido e non in scadenza.
- In anteprima server ogni evento è rivendicato dal Client GA4 corretto.
- Ogni evento compare una sola volta nell’anteprima.
- Il tag GA4 server risponde con codice 2xx.
purchasearriva conitems,value,currencyetransaction_id.- DebugView mostra i parametri attesi, non una versione impoverita.
- Tempo reale registra utenti nelle aree geografiche corrette.
- Il sottodominio di tagging è nell’esclusione dei referral.
- Gli stati di consenso arrivano al container e vengono rispettati.
- Confronto a 7 giorni con la baseline: nessun evento raddoppiato o sparito.
- Versione pubblicata documentata, annotazione inserita in GA4 con la data dello switch.
Il piano di rollback è semplice e va deciso prima: se qualcosa va storto, torni alla versione precedente del container web (quella senza server_container_url) e il traffico riprende a fluire direttamente a Google. Il container server può restare pubblicato, smetterà solo di ricevere richieste.
Quando puoi farlo da solo e quando no
Sito vetrina o blog con eventi standard e un solo dominio: è un lavoro di poche ore, con la checklist sopra lo chiudi in autonomia.
E-commerce con un Data Layer già solido, un solo dominio e checkout interno: fattibile, ma dedicaci una settimana di monitoraggio reale prima di spegnere i tag client.
Multi-dominio, checkout ospitato su un dominio esterno, app mobile, CMS headless, più proprietà GA4 sullo stesso sito: qui i passaggi si moltiplicano e gli errori non sono visibili subito. Lo stesso vale se prima dello switch il tracciamento client è già rotto, il Data Layer è incoerente o il consenso non è gestito: il server-side amplifica i problemi esistenti, non li risolve.
In quei casi conviene farsi affiancare su una configurazione reale, con un percorso di tutoring su Tag Manager server-side, oppure partire dai casi già documentati nella sezione di configurazioni pratiche e troubleshooting. Collegare GA4 è il passaggio più semplice dell’intera migrazione: se qui i numeri non tornano, non ha senso aggiungere Google Ads, Meta o BigQuery sopra una base che perde pezzi.
Domande frequenti
Devo disattivare il tag GA4 lato client dopo aver collegato il container server?
Sì. Una volta che il tag Google ha il parametro server_container_url e il tag GA4 nel container server inoltra gli eventi, i vecchi tag evento GA4 del container web vanno messi in pausa. Lasciarli attivi "per sicurezza" produce doppio conteggio di sessioni ed eventi sulla stessa proprietà. Mettili in pausa invece di eliminarli: se devi fare rollback li riattivi in un minuto.
Il Measurement ID cambia quando passo al server-side?
No. Il Measurement ID, la proprietà GA4 e lo storico dei dati restano identici. Cambia solo il percorso che la richiesta compie prima di arrivare a Google. Se vuoi testare senza rischi, crea una proprietà GA4 separata e usa il suo Measurement ID solo nel tag server finché i numeri non combaciano con quelli di produzione.
Perché l'evento purchase non arriva al container server mentre add_to_cart sì?
Quasi sempre è un problema di ordine di esecuzione: nella thank you page l’evento purchase parte prima che il tag Google abbia impostato la destinazione, quindi viene inviato direttamente a Google senza passare dal container. Verificalo nell’anteprima web guardando la sequenza dei tag, poi risolvi con il sequenziamento, con una priorità di attivazione più alta per il tag Google o con un trigger su evento Data Layer dedicato.
Posso collegare GA4 al container server senza un dominio personalizzato?
Tecnicamente funziona, ma perdi buona parte del vantaggio. Con un dominio di terze parti i cookie restano in contesto third-party e l’endpoint resta facilmente riconoscibile dalle liste di blocco. Un sottodominio del tuo sito, con certificato valido, è il requisito minimo perché lo switch abbia senso.