Dal 2019 Safari limita a sette giorni la durata di qualsiasi cookie di prima parte scritto via JavaScript: è la regola introdotta con Intelligent Tracking Prevention 2.1. Tradotto in termini pratici: l’utente che clicca il tuo annuncio lunedì e compra dodici giorni dopo da iPhone arriva alla cassa come utente nuovo, senza sorgente e senza attribuzione. È da qui che nasce quasi sempre la domanda sulla differenza tra tracciamento client side e server side.
Differenza tra tracciamento Client side e server side: due definizioni operative
Nel tracciamento client side la raccolta e l’invio avvengono dentro il browser dell’utente. Il tag gtag di GA4, il pixel di Meta, il tag di conversione di Google Ads girano come JavaScript sulla pagina e inviano la richiesta direttamente ai domini dei vendor.
Nel server-side tagging il browser invia l’evento a un endpoint che controlli tu: un container server di Google Tag Manager, raggiungibile su un sottodominio del tuo sito. Da lì il container smista l’evento verso GA4, Google Ads, Meta Conversions API e qualsiasi altra destinazione configurata.
L’equivoco da togliere subito di mezzo
Il server side non elimina il codice dal browser. Nella configurazione più diffusa resta un container web, resta un Data Layer, resta uno script che raccoglie l’interazione. Quello che cambia è la destinazione del primo invio: non più sei domini di terze parti, ma uno solo, tuo. Il server side prolunga il tracciamento client side, non lo sostituisce.
Esiste un’eccezione parziale: gli eventi generati direttamente dal backend (ordine confermato dal gestionale, rimborso, cambio di stato di un abbonamento) nascono fuori dal browser e arrivano al container server via HTTP. Ma per il comportamento on-site il browser serve ancora.
Attenzione all’omonimia
Per uno sviluppatore "server side" significa rendering lato server, logica applicativa, API. Qui parliamo di altro: di server-side tagging, cioè di dove viene eseguita la logica dei tag di analytics e advertising. Chi cerca informazioni su questo tema trova spesso discussioni che riguardano l’architettura di un’applicazione web e non il tracciamento. Sono due mondi diversi.
Lo stesso acquisto da 89 €, due percorsi
Scenario: e-commerce, utente su Safari da iPhone. Prima visita da un annuncio Google Ads, nessun acquisto. Torna cinque giorni dopo da ricerca organica e compra per 89 €.
Percorso client side
L’utente atterra, il container web carica gtag e il pixel. Il cookie _ga viene scritto via JavaScript: su Safari, per la regola citata in apertura, ha una vita di sette giorni. Il gclid viene salvato nel cookie _gcl_aw, anch’esso scritto lato browser.
Cinque giorni dopo l’utente torna. Il cookie c’è ancora, per poco. Arriva al checkout e completa l’ordine. Il tag di acquisto scatta sulla thank you page e deve inviare tre richieste a tre domini esterni. Qui si aprono i punti di caduta:
- un’estensione di blocco intercetta i domini dei vendor e la richiesta non parte;
- lo script si carica lentamente e l’utente chiude la pagina prima del firing;
- un errore JavaScript di un’altra libreria interrompe l’esecuzione;
- il valore inviato è quello presente nel DOM, che può includere spedizione, IVA o un coupon già scalato in modo incoerente.
Se l’utente avesse aspettato dieci giorni invece di cinque, il cookie sarebbe scaduto: nuova sessione, nuovo utente, conversione attribuita all’organico.
Percorso server side
Stesso utente, stesso acquisto. Il container web invia l’evento purchase al container server su sgtm.tuodominio.it. La risposta HTTP del container imposta i cookie di prima parte lato server, con una durata che non ricade nel limite di sette giorni applicato ai cookie scritti via JavaScript.
Il container server riceve l’evento e lo arricchisce: recupera il valore netto reale dal backend, aggiunge user_id se l’utente è loggato, scarta l’ordine se risulta annullato in fase di pagamento, normalizza la valuta. Poi inoltra in parallelo a GA4, a Google Ads e a Meta via Conversions API, con lo stesso event_id usato dal pixel browser per permettere la deduplica.
Due giorni dopo il gestionale conferma la spedizione. Un evento purchase_confirmed parte dal backend e arriva al container server senza passare da alcun browser: cosa impossibile lato client.
Dove il dato cambia di qualità, non solo di quantità
Il punto che si trascura: il server side non aggiunge soltanto conversioni, cambia il contenuto di quelle che già arrivavano. Valore d’ordine corretto, ordini annullati esclusi, identificatore utente coerente tra sessioni. Un dataset più piccolo ma pulito vale più di uno gonfio e sbagliato.
Un chiarimento onesto: se l’utente blocca anche il container web, o se il consenso viene negato, l’evento non parte proprio. In quel caso il server side non recupera nulla, perché non c’è niente da recuperare.
Differenza tra tracciamento client side e server side: cosa conta nelle decisioni quotidiane
| Criterio | Client side | Server side |
|---|---|---|
| Dove gira il codice dei tag | Browser dell’utente | Container su infrastruttura cloud che controlli tu |
| Chi riceve il primo invio | Direttamente i vendor (GA4, Meta, Ads) | Il tuo endpoint di prima parte, che poi smista |
| Cookie | Scritti via JavaScript, soggetti ai limiti di durata dei browser | Impostati via HTTP lato server, durata più stabile |
| Controllo su cosa esce | Limitato: il tag invia il payload previsto dal vendor | Totale: filtri campi, rimuovi PII, decidi destinazione per destinazione |
| Ad-blocker | Blocca i domini noti dei vendor | Il sottodominio è meno noto, ma classificabile nel tempo |
| Eventi dal backend | Non gestibili | Nativi (ordini confermati, rimborsi, upsell telefonici) |
| Peso sulla pagina | Ogni vendor aggiunge script e richieste | Meno script di terze parti, carico spostato sul server |
| Costo infrastruttura | Zero diretto, pagato in performance | Canone mensile proporzionale alle richieste |
| Manutenzione | Un container | Due container, un dominio e un servizio in più da sorvegliare |
| Consenso | Gestito nel browser | Gestito nel browser e replicato lato server |
Sulla privacy va detto chiaramente: Consent Mode e i tag di consenso funzionano anche nel container server, e il server side non autorizza a tracciare chi ha rifiutato. Semmai dà un punto unico in cui applicare le regole, invece di sei tag da controllare uno per uno.
Sulla performance il bilancio è reale ma va misurato: togliere quattro script di terze parti dalla pagina aiuta INP e peso trasferito, però introduce una latenza lato server e una dipendenza in più. Se il container va giù e nessuno se ne accorge, perdi dati su tutte le destinazioni insieme.
Quello che il server side non risolve
Questa è la parte che manca nella maggior parte dei confronti, e per me è quella che evita gli acquisti sbagliati.
Non recupera il 100% degli utenti. Una quota di traffico resta fuori a monte, per consenso negato o blocchi aggressivi. Chi promette il recupero totale dei dati sta vendendo male un buon strumento.
Non ripara un Data Layer sbagliato. Se l’evento parte senza transaction_id, con il valore lordo o con i prodotti mal popolati, arriva sporco anche al container server. Prima di migrare, va messo in ordine il livello dati del sito.
Non rende legittimo il tracciamento senza consenso e non elimina gli obblighi informativi verso l’utente.
Non migliora da solo le campagne. Migliora il segnale inviato alle piattaforme; perché Smart Bidding o le campagne Advantage+ ne traggano beneficio servono settimane di dati e un volume minimo di conversioni. L’effetto sulle offerte automatiche è spiegato meglio nell’approfondimento su come il server side lavora con Google Ads.
Non è invisibile per sempre. Un sottodominio molto diffuso può finire nelle liste di blocco. La resilienza è maggiore, la garanzia non esiste.
Prerequisiti, hosting e costi prima di dire sì
I requisiti minimi sono quattro: accesso al DNS per creare il sottodominio, un Data Layer coerente, una gestione del consenso già funzionante e qualcuno in grado di leggere un debug e confrontare due numeri che non tornano.
Tre modi di ospitare il container
- Gestione autonoma su Cloud Run o App Engine. Massimo controllo, nessun intermediario, in cambio ti occupi di scaling, aggiornamenti, certificati e monitoraggio della spesa.
- Hosting gestito da terzi. Il container è pronto, il dominio configurato, i costi prevedibili; cedi parte del controllo sull’infrastruttura.
- Soluzioni ibride, con infrastruttura tua e supervisione esterna, tipiche delle agenzie che seguono molti clienti.
Il confronto dettagliato fra autogestione e servizio gestito è trattato in modo specifico nell’articolo su Cloud Run come alternativa all’hosting gestito, mentre le cifre e il modo in cui la spesa scala con il numero di richieste sono raccolte nell’analisi su quanto costa mantenere un container server side.
Tempo uomo e rischi di una migrazione affrettata
Un setup base con GA4 e Google Ads, su un sito già pulito, è lavoro di qualche giornata tra configurazione, test e verifica del primo periodo. Su e-commerce complessi, con più lingue, abbonamenti o eventi dal gestionale, serve più tempo e serve soprattutto una fase di confronto numerico.
I rischi concreti di una migrazione fatta male sono tre: doppio conteggio (pixel browser e CAPI senza event_id condiviso), conversioni importate due volte in Google Ads, e perdita di continuità storica in GA4 se si cambia stream o identificatori.
Quale scegliere in base al caso
Migra adesso se hai un budget pubblicitario rilevante gestito con offerte automatiche, uno scostamento marcato fra ordini nel gestionale e conversioni dichiarate dalle piattaforme, una quota alta di traffico Safari e iOS, oppure eventi che nascono fuori dal browser e che oggi non riesci a inviare.
Aspetta se il Data Layer è assente o incoerente, se gli ordini mensili sono pochi, se il sito è in rifacimento o se nessuno può controllare il container nelle settimane successive. In questi casi il server side aggiunge complessità senza produrre un ritorno misurabile: la mia opinione è netta, prima si sistema la raccolta, poi si sposta la destinazione.
Fai un test gratuito prima di spendere. Prendi 30 giorni, metti su un foglio gli ordini del gestionale, le transazioni di GA4 e le conversioni dichiarate da Google Ads e Meta. Il divario che leggi è la stima del recupero potenziale. Se è minimo, hai la risposta. Se è ampio e il budget adv è consistente, hai il business case. Il ragionamento esteso su soglie e priorità è in questa analisi su quando la migrazione conviene davvero.
L’ordine di migrazione conta: prima GA4, perché l’errore non costa budget e il confronto è immediato; poi Google Ads, con attenzione alla doppia importazione; infine Meta con la deduplica via event_id.
Checklist dei primi 28 giorni
- Confronto a 14 e 28 giorni fra ordini a gestionale, transazioni GA4 e conversioni adv, con una soglia di scostamento dichiarata in anticipo.
- Verifica della deduplica: nessun acquisto contato due volte fra pixel e API.
- Controllo che gli eventi senza consenso restino esclusi o anonimizzati.
- Monitoraggio delle richieste al container e dei picchi di spesa.
- Una pagina di documentazione con dominio, destinazioni attive, regole di consenso e contatto di riferimento.
Chi gestisce un solo sito, ha dimestichezza con il debug e un Data Layer in ordine può procedere in autonomia. Chi segue più clienti, lavora su e-commerce con flussi di pagamento complessi o non ha modo di presidiare il container dopo il go-live fa bene a farsi accompagnare almeno nella prima implementazione.
Domande frequenti
Il tracciamento server side permette di tracciare chi rifiuta i cookie?
No. Il server-side tagging non modifica gli obblighi normativi né le preferenze dell’utente: se il consenso viene negato, gli eventi non devono partire o devono essere inviati in forma anonimizzata, esattamente come lato client. Consent Mode e i tag di consenso funzionano anche nel container server, e anzi offrono un punto unico in cui applicare le regole a tutte le destinazioni invece di configurarle tag per tag.
Posso usare client side e server side insieme?
Sì, ed è la configurazione normale. Nella maggior parte dei casi il container web resta attivo e invia gli eventi al container server, che poi li smista ai vendor. In alcuni scenari si mantiene anche il pixel browser affiancato all’invio server to server, condividendo lo stesso event_id per permettere alla piattaforma di deduplicare le conversioni.
Con quanti ordini al mese il passaggio al server side si ripaga?
Non esiste una soglia universale, ma il criterio è semplice: il recupero deve valere più del costo di infrastruttura e manutenzione. Fai il test dei 30 giorni confrontando ordini a gestionale, transazioni GA4 e conversioni dichiarate dalle piattaforme adv. Se il divario è ampio e investi un budget pubblicitario rilevante con offerte automatiche, il ritorno arriva in fretta. Con pochi ordini al mese e budget contenuti conviene rimandare e investire prima sulla qualità del Data Layer.
Cosa succede ai dati storici di GA4 dopo la migrazione?
Se mantieni lo stesso measurement ID e lo stesso stream di dati, lo storico resta intatto e la proprietà continua a raccogliere senza interruzioni. Le discontinuità nascono quando si cambia stream o si modificano gli identificatori utente: in quel caso i confronti anno su anno diventano poco affidabili. Prima del go-live conviene annotare la data esatta del passaggio, così da spiegare eventuali scalini nei grafici.