Article
GA4 server-side su Shopify: quanto costa, quanto recupera, e perché il CNAME non basta
Il sottodominio di tagging via CNAME non ti restituisce il cookie a due anni su Safari: da novembre 2020 ITP lo riconosce e lo riporta a sette giorni. Cosa recupera davvero il server-side, e quanto costa.
Il passaggio che quasi tutte le guide descrivono come risolutivo, il sottodominio di tagging via CNAME, non ti restituisce il cookie a due anni su Safari. Da novembre 2020 ITP lo riconosce e lo riporta a sette giorni. Questa guida spiega cosa recupera davvero il server-side, quanto costa, e quale configurazione produce l’effetto che tutti gli danno per scontato.
Categoria: implementazione · 13 minuti di lettura · Mattia Minafò · aggiornato al 18 agosto 2026
Di cosa parliamo
Hai letto che GA4 perde dati, che il server-side li recupera, e che bastano un container su Stape e un record DNS. Poi hai fatto il setup, il cookie è ancora a sette giorni su Safari, e non capisci se hai sbagliato qualcosa.
Le domande a cui questa guida risponde: quanto recupera davvero il server-side, quanto costa mantenerlo, e quale configurazione serve perché il cookie sopravviva su Safari.
Nell’ordine: cosa si perde nel browser, perché il CNAME da solo non basta, quanto costa nelle tre opzioni di hosting, quanto recupera secondo chi lo vende e secondo le nostre misure, i cinque passaggi, cosa non risolve, e la checklist.
Metodo e limite. Il comportamento di Safari è verificato sul blog ufficiale di WebKit e sulla documentazione dei fornitori, al 18 agosto 2026. I numeri sui progetti vengono da audit nostri, con finestra dichiarata. I prezzi cambiano spesso e vanno ricontrollati sulle pagine linkate. Questa non è una guida al debug del tuo setup specifico.
Nel testo trovi tre etichette. Documentazione quando la fonte è ufficiale, misurato da noi quando il numero viene da un nostro audit, raccomandazione quando è un giudizio professionale e non un fatto.
Indice
- Cosa perde davvero il tracciamento nel browser
- Perché il CNAME da solo non ti restituisce il cookie a due anni
- Quanto costa davvero, tre opzioni a confronto
- Quanto recupera, e chi ha misurato quel numero
- I cinque passaggi, con quello che di solito viene saltato
- Cosa il server-side non risolve
- La checklist prima e dopo il go-live
Cosa perde davvero il tracciamento nel browser
Tre cause, di peso molto diverso fra loro.
La prima è Safari. I cookie impostati da JavaScript, incluso il _ga che GA4 usa per riconoscere l’utente, vengono limitati a sette giorni di vita. Chi torna dopo la settimana risulta un utente nuovo. Su un negozio con ciclo di acquisto lungo questo gonfia i nuovi utenti e schiaccia i ritorni.
La seconda sono i blocchi a livello di rete. Gli ad blocker intercettano le richieste verso i domini noti di tracciamento prima che il browser le esegua. Il tag non viene scaricato e non parte nessun evento.
Il 29,5% degli utenti internet nel mondo usa un ad blocker, secondo la raccolta di Backlinko su dati DataReportal. Da leggere per quello che è: una media sugli utenti internet globali, non sui visitatori del tuo negozio. Sul tuo può essere il doppio o la metà.
La terza è la composizione del tuo traffico, ed è l’unica che puoi misurare prima di spendere.
Misurato da noi. Su uno store Shopify, nella finestra 8 luglio / 4 agosto 2026, il traffico era per il 64% Safari e per il 27% browser interno di Instagram su Android, oltre il 90% messo insieme. Sono i due ambienti dove il canale browser perde di più, e sono la ragione per cui su quel negozio il server-side aveva senso.
Raccomandazione. Prima di leggere il resto, apri GA4 sotto Tecnologia e guarda la quota Safari e la quota di browser in-app. Se stanno sotto il 25% combinate, il resto di questa guida ti serve molto meno.
Perché il CNAME da solo non ti restituisce il cookie a due anni
Questa è la parte che cambia il modo in cui va fatto il setup.
L’idea diffusa è: metti il container di tagging su un sottodominio tuo, il browser lo tratta come first-party, il cookie torna a due anni. La prima metà è giusta. La seconda non lo è più da sei anni.
Documentazione. Il 12 novembre 2020 WebKit ha scritto che «ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days», e ha definito il CNAME cloaking come «a first-party subresource that resolves through a CNAME that differs from the first-party domain».
Un sottodominio tag.tuodominio.com che risolve via CNAME verso l’endpoint del tuo fornitore rientra esattamente in quella definizione. Safari lo riconosce e riporta il cookie a sette giorni, anche se il cookie arriva da un header HTTP e non da JavaScript.
Poi la difesa si è allargata due volte. Nell’autunno del 2022 il limite è stato esteso alle risposte provenienti da indirizzi IP di terze parti. Con Safari 16.4 è arrivata la regola di corrispondenza dell’indirizzo: se il sottodominio di tagging risolve a un IP troppo distante da quello del sito, il cookie torna a sette giorni comunque.
Stape, che vende hosting per container di tagging, lo documenta sul proprio blog e non ha interesse a farlo: «Safari won’t decrease cookies’ lifetime if the IP address of the domain that sets first-party cookies is half matching», cioè i primi 16 bit su IPv4 e i primi 64 su IPv6 (Stape, Safari ITP guide).
Tradotto: il cookie sopravvive solo se il traffico del container esce dallo stesso indirizzo del tuo sito, o quasi.
| Configurazione | Cosa fa Safari al cookie | Quando ha senso |
|---|---|---|
| Sottodominio via CNAME verso il fornitore | Lo riporta a 7 giorni | Va bene per aggirare gli ad blocker, non per la durata del cookie |
| Sottodominio via record A verso l’IP del fornitore | Lo riporta a 7 giorni se l’IP non corrisponde al sito | Non risolve da solo, va verificato l’IP |
Percorso sullo stesso dominio, tipo tuosito.com/sgtm | Durata piena | La più solida, richiede un reverse proxy sull’origine |
| Traffico instradato sul tuo CDN, stesso IP del sito | Durata piena | Buon compromesso, richiede Cloudflare o equivalente |
Raccomandazione. Se il tuo obiettivo è aggirare gli ad blocker, il CNAME basta e puoi fermarti lì. Se il tuo obiettivo è la durata del cookie e il riconoscimento dell’utente di ritorno, serve una configurazione same-origin o un instradamento sul tuo CDN. Sono due lavori diversi e vengono venduti come se fossero lo stesso.
Quanto costa davvero, tre opzioni a confronto
I prezzi cambiano, il modello di prezzo no. Si paga per richieste al container, non per traffico del sito, e le due cose divergono in fretta quando cominci a inoltrare eventi a più piattaforme.
Servizio gestito. Stape ha un piano gratuito limitato e piani a pagamento a partire da circa 17 o 20 dollari al mese per container, con soglie di richieste crescenti. Il listino aggiornato è l’unica fonte da usare, perché queste cifre si muovono.
Google Cloud Run. Qui il numero che gira nelle guide, meno di dieci dollari al mese, merita una precisazione. Google raccomanda di allestire il server «as a cluster for better availability, scalability, and performance». Sotto i dieci dollari al mese si sta pagando una singola istanza che scala a zero, cioè l’opposto di quello che Google consiglia, e le partenze a freddo perdono eventi. Un ambiente di produzione vero costa parecchio di più.
Autogestito. Funziona, costa poco, e ti carichi manutenzione, aggiornamenti dell’immagine e monitoraggio. Ha senso se qualcuno in azienda quel lavoro lo fa già.
Raccomandazione, e la soglia che usiamo con i clienti. Il costo dell’infrastruttura è quasi sempre la voce minore. Quello che conta è il costo di configurazione e manutenzione. La soglia che dichiariamo in preventivo è che il server-side comincia ad avere senso sopra i 1.000 o 1.500 euro al mese di spesa pubblicitaria, dove l’infrastruttura pesa il due o tre per cento della spesa. Sotto quella cifra il lavoro non si ripaga, e conviene sistemare prima le UTM e il data layer.
Quanto recupera, e chi ha misurato quel numero
Qui la maggior parte dei contenuti italiani riporta una cifra sola e non dice da dove viene.
Il numero del fornitore. Stape ha pubblicato un’analisi su oltre sette milioni di richieste e riporta un recupero del 20,71% degli eventi e del 30,67% sui soli acquisti. È un dato reale, ed è pubblicato da chi vende il servizio che quel dato giustifica. Va letto sapendolo.
La nostra misura indipendente. Su un negozio Shopify, nella finestra 8 luglio / 4 agosto 2026, abbiamo contato gli eventi che esistono solo sul canale server e non su quello browser. Il contributo netto è di 1.774 eventi, cioè il 23,9% del segnale complessivo e il 31,7% sulle sole visualizzazioni prodotto. Nel dettaglio, visualizzazioni di pagina 4.025 contro 3.327, più 21%. Visualizzazioni prodotto 3.389 contro 2.316, più 46%. Il tasso di deduplica era del 78%, sopra la soglia operativa di riferimento del 75%.
Che una misura nostra e una del fornitore cadano a tre punti di distanza è la cosa più utile di questa sezione. Non perché confermi il numero, ma perché mostra l’ordine di grandezza: si recupera qualcosa attorno a un quarto del segnale, non la metà e non il dieci per cento.
Il controesempio, che vale quanto il resto. Su un altro progetto abbiamo verificato una dichiarazione ufficiale di Google secondo cui una delle sue soluzioni di tagging lato server porta un aumento delle conversioni intorno al 14%. Sui nostri test quel numero non si è confermato. Non lo abbiamo pubblicato come smentita generale, perché un campione piccolo non smentisce niente, ma non lo usiamo nemmeno per vendere.
Un caso in cui il server-side ha peggiorato un numero. Su una proprietà GA4, dopo il rilascio, la quota di sessioni senza sorgente è salita al 17%. Una parte di quell’aumento era traffico che prima si perdeva del tutto e che il server aveva cominciato a vedere, senza però etichetta di provenienza. Il sistema stava lavorando meglio e il report peggiorava.
I cinque passaggi, con quello che di solito viene saltato
1. Scegliere dove far girare il container. Servizio gestito se non hai un team tecnico, Cloud Run se hai già Google Cloud e qualcuno che lo presidia. La scelta pesa meno del passaggio successivo.
2. Configurare il dominio, e verificare l’indirizzo IP. È il passaggio dove si decide se otterrai la durata del cookie oppure no. Imposta il sottodominio, poi confronta l’indirizzo IP a cui risolve con quello del tuo sito. Se non corrispondono nei primi blocchi, hai aggirato gli ad blocker e nient’altro. Per la durata piena serve un percorso same-origin o l’instradamento sul tuo CDN.
3. Aggiornare il container web. Nel tag di configurazione GA4 imposta l’indirizzo del server come destinazione degli eventi. Da quel momento il browser parla con il tuo dominio invece che direttamente con Google, ed è questo che fa passare le richieste attraverso gli ad blocker basati su liste di domini.
4. Impostare il cookie dal server. Nel container server abilita la scrittura del cookie via header HTTP. Senza il passaggio 2 fatto bene, questo passaggio non produce l’effetto che ti aspetti, e in produzione è la combinazione più fraintesa delle due.
5. Verificare, prima di dichiarare chiuso il lavoro. La verifica utile non è che gli eventi arrivino. È che l’identificativo utente resti lo stesso fra una sessione e l’altra a distanza di più di sette giorni, su Safari, su un dispositivo reale.
Raccomandazione. Fai la verifica del passaggio 5 su un iPhone vero, non su un simulatore e non su Chrome. È l’unico ambiente dove il difetto si manifesta, ed è il motivo per cui passa inosservato per mesi.
Cosa il server-side non risolve
Il consenso. Se l’utente non acconsente, non parte niente, né dal browser né dal server. Il server-side e la gestione del consenso convivono, non si sostituiscono, e spostare la raccolta sul server non rende lecito raccogliere quello che non potevi raccogliere prima.
Le UTM sbagliate o assenti. Il server raccoglie di più, non raccoglie meglio. Se i link delle campagne non sono etichettati, avrai più eventi attribuiti allo stesso modo sbagliato.
La separazione della sandbox su Shopify. Il pixel nativo di Shopify e il tuo container restano due strati indipendenti. Se mandi gli stessi eventi da entrambi senza deduplica, il problema che crei è peggiore di quello che risolvi.
Gli ad blocker più aggressivi. Le liste avanzate riconoscono anche gli schemi degli indirizzi, non solo i domini. La perdita cala molto, non va a zero.
La discontinuità nelle serie storiche. Il giorno del rilascio i numeri salgono e non è crescita. Annota la data in GA4, altrimenti fra sei mesi qualcuno leggerà quel gradino come un risultato di marketing.
La checklist prima e dopo il go-live
Prima
- Quota Safari e browser in-app misurata in GA4, non stimata
- Spesa pubblicitaria mensile sopra la soglia che giustifica la manutenzione
- UTM e data layer già corretti, verificati su un ordine reale
- Deciso se l’obiettivo è aggirare gli ad blocker, la durata del cookie, o entrambi
Dopo
- L’indirizzo IP del sottodominio confrontato con quello del sito
- Scadenza del cookie
_gacontrollata su un iPhone reale, oltre i sette giorni - Identificativo utente stabile fra due sessioni distanti più di una settimana
- Tasso di deduplica misurato, se stai inoltrando anche alle piattaforme pubblicitarie
- Data di rilascio annotata in GA4
- Confronto fra ordini del gestionale e transazioni GA4 rifatto dopo il rilascio, sulla stessa finestra di prima
In sintesi
Il server-side recupera una quota reale di segnale, nell’ordine di un quarto sui negozi con molto traffico Safari e da app.
La durata del cookie, che è il beneficio per cui viene venduto più spesso, dipende da come risolve il tuo sottodominio e non dal fatto di avere un container. Vale la pena verificarlo prima di firmare, non dopo.
Fonti
- WebKit, CNAME Cloaking and Web Privacy, 12 novembre 2020, recuperato il 18 agosto 2026
- WebKit, Intelligent Tracking Prevention, 2017 e aggiornamenti successivi, recuperato il 18 agosto 2026
- Google Developers, Server-side tagging manual setup guide, recuperato il 18 agosto 2026
- Google Developers, Introduction to server-side tagging, recuperato il 18 agosto 2026
- Stape, Safari ITP guide, recuperato il 18 agosto 2026, fornitore di hosting per container di tagging
- Stape, listino, recuperato il 18 agosto 2026
- Stape, analisi sul recupero eventi lato server, luglio 2025, fornitore interessato
- Backlinko, Internet statistics, su dati DataReportal, recuperato il 18 agosto 2026
- Misurazioni interne su audit di store Shopify, finestre dichiarate nel testo
Il primo passo
Apri un terminale e confronta due indirizzi: quello a cui risolve il tuo sottodominio di tagging e quello del tuo sito. Se i primi due blocchi non coincidono, il cookie che stai scrivendo dal server su Safari vive sette giorni.
È una verifica da due minuti. Se il risultato non ti torna, scrivici e guardiamo insieme che configurazione serve.
Contenuti verificati sulla documentazione ufficiale al 18 agosto 2026. Le regole di Safari e i listini cambiano spesso, se leggi molto dopo questa data ricontrolla i link.