Per spostare la raccolta dati di GA4 dal browser al tuo server basta compilare un campo: transport_url nel tag di configurazione. Un solo parametro. Tutto il resto del progetto, cioè la parte che decide se ti ritrovi con numeri affidabili o con un mese di dati inutilizzabili, non sta dentro Tag Manager: sta nel metodo con cui gestisci il periodo in cui vecchio e nuovo tracciamento convivono.
Questa è la sequenza operativa che conviene seguire, nell’ordine in cui si fanno le cose, con i punti in cui si rompe quasi sempre qualcosa.
Cosa si sposta davvero, e cosa resta dov’è
Prima di toccare qualsiasi cosa, chiarisci la semantica con chi ti ha chiesto la migrazione. Qui "client side" e "server side" indicano dove viene elaborato l’hit di tracciamento. Non c’entrano il rendering delle pagine, il server su cui gira il sito o lo spostamento di file. Se approfondisci la differenza tra tracciamento client side e server side ti risparmi metà dei malintesi con sviluppatori e titolari.
Quello che non cambia
Il Data Layer resta identico. I trigger di pagina restano dove sono. Gli eventi continuano a nascere nel browser, perché è lì che l’utente clicca. La proprietà GA4 esistente resta la stessa, con le sue dimensioni personalizzate e i suoi pubblici.
E soprattutto: lo storico non si perde mai. I dati già scritti in GA4 e in BigQuery sono immutabili, nessuna modifica al container li tocca. Il rischio reale è un altro, ed è la discontinuità della serie storica futura: se i numeri cambiano scalino da un giorno all’altro, i confronti anno su anno diventano discutibili per i dodici mesi successivi.
Quello che cambia
Cambia l’endpoint a cui il browser manda la richiesta. Cambia chi scrive i cookie, che passano da JavaScript a un header HTTP Set-Cookie. Cambia il punto in cui arricchisci il dato. E cambia il mittente delle chiamate ai vendor: non più il browser dell’utente, ma il tuo container.
Tieni a mente tre categorie. Migrano subito GA4, le conversioni Google Ads e Meta Conversions API. Migrano dopo le integrazioni CRM, le conversioni offline e gli export verso il data warehouse. Non migrano mai heatmap, registrazioni di sessione, chat e strumenti di A/B test lato client: hanno bisogno del DOM, e non è una sconfitta lasciarli dove sono.
Fase 0: l’inventario e la baseline numerica
È la fase che quasi nessuno fa, ed è quella che salva il progetto.
Esporta l’elenco completo di tag, trigger e variabili del container web e classificalo per criticità di business: prima le conversioni, poi gli eventi di funnel, infine quelli informativi. Per ogni evento annota nome, parametri inviati, destinazione e volume medio giornaliero degli ultimi 28 giorni. Questo foglio è la tua baseline: i numeri congelati contro cui misurerai tutto.
Poi vai a cercare le dipendenze nascoste, quelle che nessuno ricorda di avere attivato:
- conversioni importate in Google Ads da GA4, con relative colonne usate in offerta;
- pubblici costruiti su eventi specifici e condivisi con Ads;
- export BigQuery attivo e query o dashboard Looker Studio che ci girano sopra;
- integrazioni di terze parti che leggono il
_gadal browser.
Ultimo controllo: lo stato del consenso. Quale CMP è installata, se Consent Mode v2 è attivo e quali tag sono bloccati prima della scelta dell’utente. Se questa parte è già fragile lato client, il server side non la aggiusta da solo.
Fase 1: infrastruttura, dominio e cookie
Crea il container server e scegli dove ospitarlo. Le opzioni sono il cloud fai da te oppure un hosting gestito; il confronto tra Google Cloud Run e un hosting dedicato al server side ti dà l’ordine di grandezza, mentre i costi reali in base al volume di eventi li trovi nell’analisi su quanto costa un container server side. Il parametro da non sottovalutare è il numero di istanze minime: con una sola istanza, al primo picco di traffico perdi eventi e non te ne accorgi subito.
DNS e certificato
Il sottodominio personalizzato è ciò che rende la migrazione utile. Se l’endpoint resta su un dominio di terza parte, i cookie tornano a essere di terza parte e buona parte del vantaggio evapora. La procedura completa è nella guida su come configurare il dominio personalizzato per GTM server side.
Gli inciampi sono sempre gli stessi tre: CNAME verso il provider con il proxy del DNS attivo, record non ancora propagato, certificato non emesso perché la validazione non è andata a buon fine. Verifica con una chiamata all’endpoint /healthz del container: deve rispondere ok prima ancora che tu abbia configurato un solo tag. Se non risponde, è inutile andare avanti.
Cookie first-party
Un cookie scritto dal server via Set-Cookie ha una durata diversa da uno scritto in JavaScript, e sopravvive alle restrizioni dei browser basate su ITP. Attenzione però al passaggio: se cambi lo schema di identificazione, una parte degli utenti già noti verrà riconosciuta come nuova e nei primi giorni vedrai un picco artificiale di nuovi utenti. Nella prima fase mantieni la continuità del client_id esistente e rimanda ogni esperimento sull’identità a migrazione conclusa.
Fase 2: il doppio binario
Qui sta il cuore del metodo. La produzione non si tocca: il container web continua a mandare i dati alla proprietà GA4 di sempre. In parallelo imposti una seconda configurazione che punta al container server tramite transport_url e scrive su una proprietà GA4 di collaudo, separata.
In pratica: crei una variabile costante con l’URL del container server, la assegni solo al tag di collaudo e limiti l’attivazione con un trigger controllato. Puoi usare una quota di traffico, un parametro in URL o l’ambiente di anteprima. Ti bastano anche il 20 o il 30% delle sessioni per avere numeri confrontabili.
La regola che non si viola mai: lo stesso evento non va mai duplicato verso la stessa proprietà GA4. Il risultato sarebbe sessioni gonfiate, conversioni contate due volte e attribuzione inquinata proprio nel periodo in cui ti serve leggere bene i dati.
Tieni il doppio binario per due o quattro settimane: abbastanza da coprire un ciclo di acquisto completo, un weekend e almeno un giorno di picco. Il costo aggiuntivo è proporzionale alla quota di traffico che hai deviato, quindi è una leva che controlli tu.
Fase 3: riconciliazione, i numeri che devono tornare
Confronta sempre a parità di condizioni: stesso intervallo di date, stesso fuso orario della proprietà, stessa definizione di evento. Lavora sui conteggi di evento grezzi prima che sulle metriche derivate. Se hai l’export attivo, il confronto più pulito lo fai in SQL: su questo ti aiuta la guida su come inviare gli eventi di GTM server side a BigQuery.
Le soglie che uso per dire "ci siamo"
Non sono numeri ufficiali di nessuno, sono criteri di accettazione. Scegline di tuoi, ma scrivili prima di guardare i dati:
page_viewe sessioni: scostamento entro un paio di punti percentuali;- eventi di conversione: entro un punto;
purchasedi un e-commerce: zero tolleranza sul confronto transazione per transazione contro il gestionale, non solo sui totali;- revenue: a parità di transazioni, l’importo deve coincidere.
Scostamento che è errore, scostamento che è guadagno
Se il server misura meno, hai un errore: client_id non propagato, session_id rigenerato a ogni hit, parametri persi nella trasformazione, eventi senza mapping nel client GA4.
Se il server misura di più, prima di festeggiare verifica. Un recupero legittimo da ad blocker e da restrizioni dei browser si riconosce perché è concentrato su alcuni browser e perché le transazioni extra esistono davvero nel gestionale. Se invece le transazioni extra non esistono, hai un problema di duplicazione.
Fase 4: i tag che si rompono durante il passaggio
Google Ads
Decidi se tenere le conversioni importate da GA4 o passare a un tag di conversione dedicato lato server. Qualunque strada scegli, non farlo in alta stagione: una variazione nel segnale di conversione fa ripartire l’ottimizzazione delle campagne, e il momento sbagliato ti costa in asta. Gennaio sì, Black Friday no. Sul rapporto tra container server e piattaforma pubblicitaria ho già scritto in GTM server side come alleato di Google Ads.
Enhanced Conversions e Meta CAPI
I dati utente vanno comunque raccolti dal browser: quello che sposti lato server è l’hashing e l’invio. Per Meta, genera un event_id univoco e passalo sia al pixel sia alla Conversions API: senza deduplicazione ti ritrovi ogni acquisto contato due volte, ed è l’errore più frequente in assoluto in questa fase.
Consenso
Il consenso non è una proprietà del container server: viaggia come parametro dentro la richiesta che arriva dal browser. Se il segnale non parte correttamente dal client, il server non ha modo di inventarselo. Controlla che i parametri di consenso siano presenti nelle richieste in ingresso seguendo la guida su come configurare Consent Mode v2 lato server.
Fase 5: il cutover e il piano di rollback
Dai il via libera solo con criteri oggettivi: scostamento sotto soglia per almeno sette giorni consecutivi, conversioni dell’ultimo mese verificate contro una fonte autorevole come il gestionale o il back office, nessun errore ricorrente nei log del container.
La sequenza del passaggio è breve: sposti il transport_url sulla configurazione di produzione, pubblichi, verifichi in tempo reale che gli eventi arrivino alla proprietà principale. Non cancelli niente per almeno trenta giorni. Il container web resta pubblicato e la versione precedente resta a portata di clic: il rollback deve essere un’operazione da cinque minuti, non un progetto.
Scegli una mattina infrasettimanale, con traffico prevedibile, e assicurati che chi gestisce le campagne sia reperibile. Inserisci un’annotazione in GA4 con la data del cutover: tra sei mesi, quando qualcuno chiederà perché i numeri cambiano passo in quella settimana, l’annotazione risponderà al posto tuo. E avvisa chi legge i report prima, non dopo: il mese del passaggio non è pienamente confrontabile con il precedente, e va scritto nero su bianco.
Fase 6: i primi 30 giorni e quando chiedere aiuto
Il cruscotto minimo da guardare ogni giorno: volumi per evento, tasso di errore del container, latenza di risposta, costo dell’hosting. Quattro numeri, due minuti.
Alcuni problemi emergono solo dopo giorni: istanze esaurite durante un picco promozionale, timeout verso un endpoint di terze parti lento, richieste malformate da browser poco comuni. Per isolarli, leggi i log del container invece di affidarti all’anteprima: l’anteprima mostra la tua sessione, i log mostrano la realtà.
Tre diagnosi tipiche, in sequenza. Traffico diretto che esplode: controlla referral exclusion, linker tra domini e cookie. Attribuzione che cambia: controlla che i parametri di campagna arrivino integri al server. Conversioni Ads crollate di colpo: controlla mapping dei parametri e segnali di consenso, in quest’ordine.
Puoi farlo da solo?
I prerequisiti reali sono tre: accesso al DNS del dominio, permessi di amministratore su GTM e GA4, capacità di leggere una richiesta HTTP e capire cosa contiene. Se ne manca uno, non è questione di bravura: ti mancano gli strumenti.
Un sito vetrina con GA4 e un pixel si migra in autonomia, nell’arco di una settimana di calendario e poche ore di lavoro effettivo. Un e-commerce multi-dominio con CRM collegato, conversioni offline e più piattaforme pubblicitarie è un progetto da settimane, con fasi di test che non si comprimono. La differenza la fa il costo dell’errore: un mese di dati di conversione sbagliati su un budget pubblicitario a cinque cifre vale molto più di qualsiasi affiancamento. Se sei nel mezzo, valuta un percorso di tutoring su Tag Manager server side e fai la migrazione con qualcuno che guarda i log insieme a te.
Domande frequenti
Migrando al server side perdo lo storico dei dati di GA4?
No. I dati già raccolti in GA4 e in BigQuery sono immutabili e nessuna modifica al container li cancella. Il rischio da gestire è la continuità della serie storica futura: se i volumi cambiano di colpo dopo il cutover, i confronti periodo su periodo vanno letti con l’annotazione della data di passaggio, non al buio.
Posso tenere attivi insieme il tracciamento client side e quello server side?
Sì, ed è il metodo consigliato, a una condizione: i due flussi devono scrivere su proprietà GA4 diverse. Il client side continua ad alimentare la proprietà di produzione, il server side una proprietà di collaudo. Duplicare lo stesso evento sulla stessa proprietà significa sessioni gonfiate, conversioni doppie e attribuzione inquinata.
Quanto dura una migrazione da client side a server side?
Per un sito vetrina con GA4 e un pixel, una settimana di calendario e poche ore di lavoro. Per un e-commerce con più piattaforme pubblicitarie, CRM e conversioni offline servono dalle quattro alle otto settimane, di cui due o quattro sono solo di convivenza tra vecchio e nuovo tracciamento per poter confrontare i numeri.
Cosa succede alle campagne Google Ads durante la migrazione?
Se cambi la fonte del segnale di conversione, l’ottimizzazione automatica delle campagne ricalibra. Per questo non si migra in alta stagione né durante un lancio: scegli un periodo di traffico stabile, verifica le conversioni contro il gestionale prima del cutover e tieni pronta la versione precedente del container web per un rollback immediato.