Molto ImportanteMolto Importante
Server-Side Tracking con sGTM: lo standard del 2026 per i dati di prima parte

Server-Side Tracking con sGTM: lo standard del 2026 per i dati di prima parte

Server-side Google Tag Manager bypassa ad-blocker e prolunga i cookie fino a 400 giorni: cos'è, perché serve, come si implementa, costi e benefici reali.

In questa pagina

Introduzione

Il client-side tracking è morto e nessuno lo ha avvisato ufficialmente. Tra ad-blocker, Safari ITP che riduce i cookie a 7 giorni, e Consent Mode v2 che lavora meglio con dati reali, il server-side via sGTM è diventato uno standard di fatto per chi fa pubblicità seria nel 2026. Capirlo non è opzionale.

Se nel 2024 il server-side era una nicchia da nerd, oggi è il modo in cui le campagne di chi vende ancora online vedono i dati. La quota di utenti italiani che usano un qualche ad-blocker viaggia stabilmente sopra il 30%, Safari conserva la sua quota mobile importante e taglia i cookie a sette giorni, e nel frattempo Google Ads chiede misurazione sempre più granulare per alimentare Smart Bidding. Il vecchio container web non basta più. Vediamo come si sale di livello senza farsi male.

Cosa è il server-side tracking (in due righe per chi non lo sa)

Nel modello tradizionale, ogni evento sul tuo sito parte dal browser dell'utente e va dritto a Google, Meta, TikTok, eccetera. Nel modello server-side, l'evento parte dal browser e arriva prima a un server che è tuo (o gestito per te), e poi da lì viene smistato verso le destinazioni. È un cambio di residenza dei dati: dal browser del visitatore al tuo dominio.

Sembra un dettaglio di routing, è una rivoluzione di affidabilità. I dati passano da un endpoint riconducibile a te, quindi non vengono bloccati dagli ad-blocker che agiscono sui domini dei tracker noti. I cookie diventano di prima parte (HttpOnly, dal tuo dominio), quindi sopravvivono molto più a lungo ai meccanismi ITP/ETP dei browser.

Cosa cambia rispetto al GTM tradizionale

Il container web di GTM continua a esistere: è il punto di raccolta degli eventi sul browser. Quello che cambia è la destinazione. Invece di spedire dal browser a `google-analytics.com`, il container web spedisce al container server (un endpoint tipo `metrics.tuodominio.it`), e da lì il container server inoltra ai vari servizi.

Sul piano del lavoro, cambia poco per chi mappa gli eventi: i trigger, le variabili, il dataLayer restano. Cambia tutto sul piano dell'infrastruttura: serve un hosting per il container server, una configurazione DNS che esponga il sotto-dominio, e un setup dei tag server (che hanno una sintassi vicina ma non identica al web).

Sul piano dei costi, il container server non è gratis: il web container lo è, il server container vive su un'infrastruttura cloud che paghi. Il prezzo dipende dal volume di eventi e dalla scelta dell'hosting. Vediamoli.

"Due cavi, uno passa per un nodo rosso intermedio: il server side vs client side"

I benefici concreti (numeri reali)

Tre benefici, tre ordini di grandezza diversi.

Recupero conversioni 20-40%. Sui siti italiani con buon traffico desktop e mobile misto, l'attivazione di sGTM ha portato in audit recenti un recupero netto di conversioni misurabili che oscilla tra il 20 e il 40%. Il numero esatto dipende dalla quota di traffico Safari e dall'incidenza degli ad-blocker sul pubblico.

Cookie 400 giorni invece di 7. Safari ITP, dal 2019, taglia i cookie client-side a 7 giorni. Con sGTM, i cookie sono di prima parte e impostati dal server: la durata massima diventa quella nominale (400 giorni per i cookie di tracciamento Google). Il ritorno del visitatore a 30, 90, 180 giorni torna attribuibile.

Smart Bidding nutrito meglio. Google Ads ottimizza sui dati che riceve. Più dati di conversione veri arrivano, meno deve estrapolare. Sui conti che gestisco con sGTM attivo, il primo segnale è la stabilità dei ROAS giorno-su-giorno: non meno volatilità per magia, ma meno volatilità perché il dato è meno bucato.

Quanto costa un sGTM (e dove abita)

Tre strade, tre profili di spesa.

Google Cloud Platform in autogestione: il container vive su una App Engine o su un Cloud Run, paghi per traffico effettivo. Per un sito da 100k visite/mese si sta tra 15 e 50 euro/mese di hosting. Servono competenze cloud, almeno per il setup iniziale.

Stape.io, Addingwell, CustomCookie: hosting gestiti specifici per sGTM. Si paga un abbonamento mensile (15-100 euro a fascia traffico) e ci si dimentica del cloud. Setup in 30 minuti, supporto incluso, dashboard pronta. È la strada che consiglio a quasi tutte le PMI italiane sotto le 500k visite/mese.

Hosting interno (per chi ha già un'infrastruttura): si installa il container su un VM del cliente. Costo marginale zero, complessità di manutenzione alta. Ha senso per chi ha già un sistemista.

Come si implementa (alto livello)

Il flusso minimo, in cinque passi.

Si crea il container server in GTM (è gratis nell'interfaccia GTM, paghi solo l'hosting). Si sceglie l'hosting e si fa il provisioning: nella maggior parte dei casi è un wizard di 10 minuti. Si configura il DNS, esponendo un sotto-dominio del cliente (`metrics.dominio.it`, `sgtm.dominio.it`) verso l'endpoint del server container.

Si rimappa il container web per spedire al server container invece che direttamente ai servizi: tag GA4, Google Ads Conversion, Meta CAPI puntano al server. Si configurano i client sul server (GA4 client, Meta CAPI client) che ricevono e inoltrano.

Si testa in parallelo col vecchio setup per almeno due settimane: si confrontano i numeri, si verificano discrepanze accettabili, si trovano i tag dimenticati. Solo quando i numeri tornano si dismette il client-side. Il server-side si integra poi perfettamente con il Consent Mode v2 avanzato: i due sistemi si potenziano a vicenda perché sGTM garantisce che i ping di consenso arrivino anche quando il client-side è bloccato da ITP o ad-blocker.

Cosa succede se NON lo implementi

Tre conseguenze, in crescendo. Smart Bidding al buio: l'algoritmo riceve dati monchi (Safari tagliato, ad-blocker tagliato, ITP tagliato), e ottimizza su un universo distorto. Il sintomo è il classico "spendiamo tanto e non capiamo dove va": è il sistema che sta cercando di leggere il libro col 35% delle pagine strappate.

ROAS sottostimato: le conversioni reali avvengono, ma metà non viene attribuita ai canali giusti. Le campagne sembrano deficitarie e vengono spente. È il modo migliore per chiudere campagne profittevoli per errore di misurazione.

Consent Mode v2 fragile: il client-side viene bloccato a monte da ITP e ad-blocker proprio sugli utenti dove Consent Mode dovrebbe lavorare meglio. La modellazione delle conversioni ha bisogno di volume per attivarsi: senza sGTM, in molti account italiani quel volume non arriva.

Roadmap di adozione a 60 giorni

Sessanta giorni per fare le cose con la testa sul collo.

Giorni 1-15, setup tecnico: scelta hosting (Stape o Addingwell come default sicuro per le PMI), creazione container server, configurazione DNS, primo health check. A fine mese, l'infrastruttura è in piedi e silente.

Giorni 16-40, migrazione eventi critici: Google Ads conversion, GA4 purchase/lead, Meta CAPI. Si rimappa in container web, si configura il routing nel container server, si testa per due settimane in parallelo confrontando con il vecchio setup. Si dichiara migrato un evento solo quando i numeri tornano a +/- 5%.

Giorni 41-60, dismissione progressiva del client-side: si spengono i tag client-side uno alla volta, si monitora 3-5 giorni per ognuno, si verifica la stabilità del dato. A fine sessantesimo giorno, sei server-side. Da lì in avanti, monitoraggio mensile e basta.

Se questi 60 giorni li devi fare mentre vendi, gestisci, paghi fornitori e rispondi ai clienti, ha senso valutare un partner che faccia il setup mentre tu fai il tuo mestiere. Una telefonata inquadra il caso in venti minuti. Le altre novità Google Ads e gli strumenti advertising sono nelle categorie. Per il quadro servizi pubblicitari, Google Ads e Meta.

Hai bisogno di un chiarimento?

Contattaci per ricevere indicazioni precise sul servizio piu adatto.