[ Article ]

GA4 server-side: quando conviene davvero e come si implementa su Shopify

Il tracking GA4 client-side perde dati per tre motivi strutturali: ITP Safari, ad blocker e cookie di terza parte. Server-side risolve tutti e tre — ma non è la risposta giusta per tutti. Guida completa con architettura, step e limiti reali.

5 luglio 2026·Mattia Minafò

ga4server-side trackingsgtmshopifygtmitpad blockerimplementazione

In sintesi

GA4 client-side perde dati per tre ragioni strutturali: ITP Safari (cookie _ga cappato a 7 giorni), ad blocker (fino al 29,5% degli utenti), cookie di terza parte in dismissione

Server-side GTM risolve tutti e tre — ma aggiunge complessità e costo operativo

Conviene quando: audience iOS/Safari significativa, spesa pubblicitaria rilevante, necessità di cookie first-party longevi

Non conviene quando: store piccoli, traffico basso, problemi di tracking più fondamentali non ancora risolti (UTM errati, dataLayer rotto)

Implementazione: 5 step — hosting sGTM, custom domain, aggiornamento Web container, cookie first-party, verifica

Il tag gtag.js di Google Analytics 4 è un file JavaScript che gira nel browser dell’utente. Raccoglie dati, li processa localmente, li invia a Google. È il modello di tracking che tutti conoscono e che funziona bene — finché qualcosa non lo blocca.

Tre cose lo bloccano, e le tre cose insieme stanno crescendo.

Server-side tracking è la risposta tecnica a questo problema. Ma prima di installare un container GTM su un server, vale la pena capire esattamente cosa si sta risolvendo, cosa rimane irrisolto, e se per il tuo store ne vale la pena.

Tre motivi per cui GA4 client-side perde dati

1. ITP Safari — il cookie `_ga` dura 7 giorni, non 2 anni

Apple ha introdotto Intelligent Tracking Prevention (ITP) con iOS 12 nel 2018. Ogni versione successiva ha ristretto ulteriormente i cookie impostati da JavaScript.

Il risultato attuale: i cookie impostati via JavaScript — incluso il _ga che GA4 usa come identificatore utente — hanno un massimo di 7 giorni di vita su Safari. Dopo 7 giorni, l’utente che ritorna è trattato come nuovo utente.

Per un ecommerce con ciclo di acquisto lungo (prodotti considerati, confronti tra brand, riacquisti stagionali), questo significa che una quota significativa degli utenti ritornanti non viene riconosciuta. Sessioni mal attribuite, metriche di retention distorte, e-mail di remarketing che riacquisiscono utenti già clienti.

A giugno 2026, Safari aveva una market share globale intorno al 19-20%, significativamente più alta su mobile dove iOS domina (StatCounter, Browser Market Share Worldwide, giugno 2026). In Italia, dove iPhone ha penetrazione elevata, il dato è ancora più alto.

Capsule citabile: Il cookie _ga di Google Analytics 4 viene impostato via JavaScript dal tag gtag.js o da GTM. Su Safari con ITP attivo (iOS 12+, macOS Mojave+), i cookie impostati da JavaScript hanno una durata massima di 7 giorni. Dopo 7 giorni, GA4 non può riconciliare la sessione dell’utente ritornante con le sessioni precedenti — l’utente risulta nuovo. Per ecommerce con ciclo di acquisto superiore alla settimana, questo crea una sottostima sistematica dei clienti fidelizzati e una sovrastima del traffico di nuovi utenti.

2. Ad blocker — bloccano gtag.js prima che parta

Gli ad blocker operano a livello di rete: intercettano le richieste verso domini noti (come google-analytics.com, googletagmanager.com) e le bloccano prima che il browser le esegua. Il tag di GA4 non viene mai scaricato. Nessun evento viene tracciato.

In marzo 2026, il 29,5% degli utenti internet globali usa un ad blocker (Backlinko, Internet Statistics & Facts, citando DataReportal, marzo 2026). Il dato è più alto tra gli utenti desktop, tra gli utenti tech-savvy, tra chi usa browser come Firefox con Enhanced Tracking Protection attivo di default.

Per store con audience prevalentemente desktop o con profilo tecnico dell’utente elevato, questa perdita è concreta e misurabile.

GA4 ha già migrato a cookie first-party (_ga è sul tuo dominio, non su google-analytics.com). Ma il tag GTM e gtag.js vengono serviti da domini di terza parte. Safari e Firefox li trattano già come cross-site tracking e applicano restrizioni. Chrome sta rallentando il deprecation dei cookie di terza parte, ma la direzione è quella.

Il problema non è “futuro” — è già presente su Safari e Firefox.

Quando server-side conviene davvero — e quando no

Server-side tracking aggiunge complessità e costo operativo. Non è la risposta giusta per tutti.

La decisione dipende da due variabili: quanto pesano ITP e ad blocker sulla tua audience, e quanto costa un'attribuzione imprecisa sul tuo budget pubblicitario.

Conviene quando:

La tua audience è principalmente iOS/Safari (prodotti lifestyle, moda, beauty — alta penetrazione iPhone)
Stai spendendo in advertising e l’attribuzione di conversione è critica
Il ciclo di acquisto è superiore ai 7 giorni (il limite ITP)
Hai già il tracking base corretto (UTM corretti, dataLayer sano) e vuoi il passo successivo

Non conviene (ancora) quando:

Il tracking base è rotto — UTM mancanti, dataLayer con dati sbagliati, duplicazioni. Server-side amplifica un segnale già distorto: risolvi prima il problema di base.
Il traffico è basso e il budget pubblicitario è contenuto. Il costo di implementazione e manutenzione non si ammortizza.
L’audience è prevalentemente desktop Chrome con pochi utenti Safari. Il beneficio di ITP resistance è marginale.

Come funziona l’architettura: Web container + sGTM

Il server-side tracking non sostituisce GTM — aggiunge un secondo container che gira su un server.

Circuiti elettronici stampati visti dall’alto, infrastruttura server-side tracking

Il flusso:

Il browser dell’utente carica il Web container GTM (come sempre)
Il Web container invia gli eventi a un endpoint sul tuo server (il container sGTM) invece che direttamente a Google
Il container sGTM riceve gli eventi, li elabora, e li inoltra a GA4 tramite le API di Google

Il vantaggio chiave: il passaggio 2 avviene verso un sottodominio del tuo sito (tag.tuodominio.com). Il browser lo tratta come first-party. Il cookie _ga viene impostato da questo server via header HTTP — non da JavaScript nel browser.

Un cookie impostato via header HTTP da un server first-party non è soggetto al cap di 7 giorni di ITP. Può avere la durata di 2 anni come configurato.

Prerequisito non negoziabile: sGTM deve girare su un sottodominio del tuo dominio. Se gira su un dominio di terze parti (es. il dominio default di Stape prima della configurazione custom), i benefici first-party scompaiono. Il cookie _ga sarebbe di terza parte e soggetto alle stesse restrizioni di ITP.

Come implementarlo: 5 step

Step 1 — Scegliere dove hostare il container sGTM

Tre opzioni principali, in ordine di complessità:

Stape.io (opzione consigliata per iniziare) Servizio managed di hosting sGTM. Setup in circa 15 minuti. Supporta custom domain. Prezzi: piano free limitato, poi ~10 USD/mese per store a traffico normale, scalabile.

Il vantaggio di Stape: include tag preconfigurati per Shopify, funzionalità aggiuntive (consent mode, enrichment), e una console di monitoraggio integrata. Per la maggior parte degli store Shopify, è la scelta corretta.

Google Cloud Run / App Engine Il container sGTM è un’immagine Docker. Può girare su qualsiasi infrastruttura cloud. Google Cloud Run è stateless, scala a zero, paga per invocazione. App Engine è sempre attivo.

Costo indicativo: meno di 10 USD/mese per traffico normale su Cloud Run. Richiede familiarità con Google Cloud.

Render.com / alternativa self-hosted Funzionale, costo contenuto (~7 USD/mese piano Starter), deploy automatico da GitHub. Meno funzionalità native rispetto a Stape per il contesto GTM.

Step 2 — Configurare il custom domain

Questo è il passaggio più critico e quello che più spesso viene saltato.

Sul DNS del tuo dominio, aggiungi un record CNAME che punta al tuo container sGTM:

tag.tuodominio.com  CNAME  <endpoint del tuo sGTM provider>

Dopo la propagazione DNS (tipicamente 1-24h), verifica che https://tag.tuodominio.com/ risponda correttamente.

Perché è critico: senza custom domain, il cookie _ga viene impostato dal dominio del provider (es. stape.io) e non è first-party per il tuo sito. ITP lo tratta come cookie di terza parte. Tutto il beneficio principale va perso.

Step 3 — Aggiornare il Web container GTM

Nel tuo container GTM web (quello che gira nel browser), devi modificare il tag GA4 per inviare gli eventi al tuo sGTM invece che direttamente a Google.

Nella configurazione del tag GA4 (o nella Configuration Tag), imposta il Server container URL:

https://tag.tuodominio.com

Da questo momento, ogni evento GA4 dal browser viene inviato prima al tuo server, che lo elabora e lo inoltra a Google. Il browser non comunica più direttamente con i server di Google per questi eventi.

Cosa succede agli ad blocker: Il browser invia la richiesta verso tag.tuodominio.com — un dominio che l’utente ha visitato, un dominio tuo. Gli ad blocker basati su liste di domini bloccati non lo riconoscono come dominio di tracking. La richiesta passa.

Gli ad blocker più sofisticati (uBlock Origin con filtri avanzati, Brave Shield avanzato) possono ancora rilevare e bloccare il traffico per pattern. Non è una soluzione al 100% — ma riduce significativamente la perdita.

Step 4 — Cookie first-party `_ga` via sGTM

Con il setup degli step 1-3, il traffico GA4 passa già per il tuo server. Ma il cookie _ga è ancora impostato da JavaScript nel browser (dal tag GA4 nel Web container).

Per renderlo veramente first-party e immune a ITP, devi configurare il container sGTM per impostare il cookie _ga via header HTTP.

In sGTM: nel tag GA4 (server), abilita l’impostazione del cookie lato server. Il container sGTM imposta il cookie _ga nell’header Set-Cookie della risposta HTTP. Il browser riceve il cookie come proveniente dal server di tag.tuodominio.com — che è un sottodominio del tuo dominio — e lo tratta come first-party.

Durata del cookie: configurabile fino a 2 anni (GA4 default). Nessun cap ITP. L’utente che torna dopo 30 giorni viene riconosciuto.

Capsule citabile: Il cookie _ga di Google Analytics 4 impostato via JavaScript (da gtag.js o dal tag GTM nel browser) è soggetto al cap di 7 giorni di Apple ITP su Safari. Lo stesso cookie, impostato via header HTTP Set-Cookie da un server che gira su un sottodominio first-party, non è soggetto al cap — può durare fino a 2 anni. La differenza non è nel contenuto del cookie ma nel meccanismo di impostazione. ITP restringe i cookie JS-set; non restringe i cookie impostati da risposte HTTP di server first-party.

Step 5 — Verificare con GA4 DebugView

Dopo ogni step, verifica. Non assumere che funzioni.

Verifica del container sGTM:

Apri https://tag.tuodominio.com/ — deve rispondere (non errore 404)
In GTM sGTM, usa Preview mode per vedere gli eventi in arrivo

Verifica del cookie:

Apri DevTools → Application → Cookies → tuo dominio
Cerca _ga — deve comparire con domain .tuodominio.com (con punto iniziale = first-party per tutti i sottodomini)
Verifica la data di scadenza — deve essere ~2 anni nel futuro

Verifica degli eventi in GA4:

Attiva DebugView in GA4 (menu Amministratore → DebugView)
Naviga sul sito — gli eventi devono comparire in DebugView
Controlla che client_id sia consistente tra le sessioni

Verifica del bypass ad blocker:

Installa uBlock Origin su Chrome
Attiva il blocco, naviga sul sito
Controlla DevTools → Network: le richieste verso tag.tuodominio.com devono passare anche con uBlock attivo

Cosa rimane irrisolto: i limiti reali

Server-side tracking non è una soluzione universale. Ci sono cose che non risolve.

Non risolve il consenso mancante. Se l’utente non ha dato il consenso al tracking, nessun cookie viene impostato e nessun evento viene inviato — né client-side né server-side. Server-side e Consent Mode devono coesistere, non si sostituiscono. Consent Mode Advanced (con i ping anonimi di Google) rimane necessario.

Non risolve UTM errati o mancanti. Se le campagne hanno UTM sbagliati, il segnale raccolto — anche più completo grazie al server-side — riflette errori a monte. L’attribuzione rimane sbagliata, solo con meno dati persi.

Non copre il Shopify Web Pixel. Il Shopify Web Pixel (sandbox) e il tuo container GTM sono layer separati. Il Shopify Pixel invia i propri eventi a Shopify Analytics indipendentemente dalla tua infrastruttura GTM. Se stai confrontando GA4 con Shopify Analytics, le discrepanze possono aumentare — perché GA4 ora raccoglie di più, avvicinandosi ai numeri Shopify.

uBlock Origin avanzato può ancora bloccare. La lista uBlock Filters — Privacy include alcune regole che bloccano per pattern di URL (es. endpoint che contengono /collect o payload con measurement_id). Non è il 100% degli utenti con ad blocker, ma esiste. La soluzione è un custom loader per GTM stesso (oltre che per sGTM) — uno step aggiuntivo raramente implementato.

Quanto recupera davvero il server-side?

A luglio 2025, Stape ha pubblicato un’analisi empirica su 7.032.096 richieste reali che ha misurato un recupero del 20,71% di eventi che non sarebbero arrivati con il solo tracking client-side — e del 30,67% per gli eventi Purchase specificamente (Stape.io, Server-Side Tracking Recovery Analysis, luglio 2025).

Il numero varia significativamente per:

Quota Safari dell’audience: più alta → più impatto ITP → più recupero
Tipologia di prodotto: prodotti tech o privacy-oriented attraggono utenti con più ad blocker
Paese: Nord Europa e USA hanno penetrazione di ad blocker più alta dell’Italia

Il modo corretto di misurarlo sul proprio store: confronta il numero di sessioni GA4 con gli ordini Shopify sullo stesso periodo, prima e dopo il go-live server-side. Se il rapporto sessioni/ordini migliora (più sessioni tracciate a parità di ordini), il server-side sta recuperando traffico reale.

Server-side per Shopify: nota specifica

Su Shopify, l’implementazione segue lo stesso schema descritto — ma ci sono alcune particolarità.

Il Shopify Web Pixel e GTM non comunicano direttamente. GTM viene caricato via script nel tema (o tramite custom pixel), ma il Shopify Web Pixel (sandbox) è separato. Hai due fonti di eventi: il tuo dataLayer GTM e gli eventi nativi Shopify. Assicurati di non tracciare gli stessi eventi da entrambi senza deduplicazione.

Il dataLayer Shopify standard è limitato. Non include LTV, numero ordini storici, stato New/Returning affidabile. Per questi dati serve un layer aggiuntivo — come il microservizio Customer Data API descritto in un caso studio separato.

Il GA4 tag in sGTM deve ricevere il client_id correttamente. Il client_id è l’identificatore utente GA4. Deve essere letto dal cookie _ga e passato negli eventi — altrimenti GA4 crea un nuovo utente per ogni evento server-side. Verifica nella configurazione del tag GA4 in sGTM che il campo client_id sia popolato correttamente.

Vuoi sapere se server-side vale per il tuo store?

Prima di implementare, due verifiche rapide:

Misura la quota Safari: Google Analytics → Pubblico → Tecnologia → Browser. Segna la percentuale di sessioni Safari.
Misura la perdita stimata: confronta gli acquisti GA4 con gli ordini Shopify sullo stesso periodo. Se GA4 ne vede il 70-80%, c’è spazio per il recupero.

Con LayerData facciamo questa analisi in 20 minuti e ti diciamo se il server-side ha senso per il tuo store — e cosa recupererebbe.

Domande frequenti

GTM server-side costa di più del tracking client-side?

Sì. Aggiunge il costo di hosting del container sGTM (da ~7-10 USD/mese su Stape o Render) e il costo operativo di configurazione e manutenzione. Per store con budget pubblicitario significativo, l’impatto sull’attribuzione giustifica ampiamente il costo. Per store piccoli, può non farlo.

Posso usare GA4 Measurement Protocol direttamente invece di sGTM?

Sì, ma è più complesso da gestire. Il Measurement Protocol permette di inviare eventi a GA4 direttamente da server senza passare per sGTM. Il vantaggio: massimo controllo. Lo svantaggio: devi gestire tu client_id, session_id, e tutti i parametri — che normalmente sGTM legge dal cookie e dai dati del browser automaticamente. Per la maggior parte degli store, sGTM è la scelta più manutenibile.

Sì, e si integra bene. Il segnale di consenso viene propagato dal Web container al container sGTM. Se l’utente ha rifiutato il consenso, il container sGTM non invia eventi a GA4 (o invia solo i ping anonimi di Consent Mode Advanced, se configurato). La compliance GDPR dipende dalla corretta propagazione del segnale di consenso — non dall’infrastruttura server-side di per sé.

Dopo il go-live, vedo un aumento di sessioni in GA4. È normale?

Sì, è il recupero di sessioni che prima venivano perse (ad blocker, ITP). Questo può creare una discontinuità nelle serie storiche: GA4 sembrerà crescere improvvisamente, ma è solo un miglioramento della raccolta dati, non crescita reale del traffico. Documenta la data di go-live come annotation in GA4 per non confondere i report futuri.

Fonti

Backlinko, Internet Statistics & Facts, citando DataReportal, recuperato 2026-07-05
StatCounter, Browser Market Share Worldwide, recuperato 2026-07-05 (giugno 2026)
Stape.io, Server-Side Tracking Recovery Analysis, luglio 2025, recuperato 2026-07-05
Apple, Intelligent Tracking Prevention, WebKit Blog, 2018
Google Developers, Introduction to server-side tagging, recuperato 2026-07-05

Torna al blog