La convinzione diffusa è che il server-side sia un interruttore: lo accendi e tutto il tracciamento passa dal container server. Quello che succede davvero è diverso. Il container server è una destinazione selettiva, e ogni evento che ci fai passare è una richiesta che paghi, un tag che devi mantenere e un potenziale punto di doppio conteggio.
La risposta breve: dal server mandi gli eventi che hanno valore di conversione o di remarketing e che sul client vengono persi o degradati. Tutto il resto — scroll, click su menu, video progress — resta dove sta. Il criterio non è "quanto è importante l’evento per me", ma "quanto perdo se lo lascio sul client e quanto mi costa spostarlo".
Definizione di riferimento: Google Tag Manager server-side (sGTM) è un container ospitato su un dominio di tua proprietà che riceve le richieste dal sito e le ridistribuisce alle piattaforme di destinazione (GA4, Google Ads, Meta, CRM). Se la distinzione tecnica non ti è ancora chiara, parti dal confronto tra tracciamento client-side e server-side.
Prima di iniziare: cosa ti serve sul tavolo
Non puoi scegliere gli eventi a memoria. Ti servono quattro cose, prima di aprire il container.
- L’elenco reale degli eventi che il sito invia oggi: dal container web (tag GA4 configurati) e dal report Eventi di GA4, con i volumi degli ultimi 90 giorni.
- L’elenco delle conversioni e dei pubblici attivi su Google Ads e Meta Ads. Serve a capire quali eventi alimentano davvero una decisione di spesa.
- Il numero di ordini o lead reali presi dal gestionale o dal back-office, nello stesso periodo. È il tuo metro di verità.
- Un Data Layer leggibile, con nomi di evento e parametri coerenti. Se il Data Layer è un caos, spostare gli eventi sul server non risolve niente: struttura prima il Data Layer dell’e-commerce.
Se manca il quarto punto, fermati lì. Il server-side amplifica la qualità del Data Layer che gli dai in pasto, nel bene e nel male.
Perché non conviene mandare tutto dal server
Ci sono tre costi che non vedi finché non li paghi.
Costo economico
Ogni hit che arriva al container server è una richiesta elaborata da un’infrastruttura. Che tu usi Cloud Run a consumo o un hosting gestito, la logica di fondo è la stessa: più eventi, più risorse. Un sito editoriale che manda ogni page_view, ogni scroll e ogni user_engagement dal server genera un volume di richieste di un ordine di grandezza superiore a un e-commerce che manda solo gli eventi di funnel. Per capire come si traduce in euro al mese nel tuo caso, c’è l’analisi dedicata su quanto costa un container server-side.
Costo di rumore
Gli eventi micro-comportamentali gonfiano il volume senza cambiare nessuna decisione. Sapere che molti utenti scrollano fino al footer è interessante in un report, ma non entra in una strategia di bidding. Portarlo sul server significa pagare richieste per un dato che non ottimizza nulla.
Costo di manutenzione
Ogni evento server-side è un tag, un trigger e una o più variabili da mantenere. Soprattutto: è un punto in più di rottura silenziosa. Un evento sbagliato sul client lo vedi in Tag Assistant in trenta secondi. Un evento sbagliato sul server te ne accorgi quando le conversioni in piattaforma non tornano, e nel frattempo hai ottimizzato le campagne su dati storti.
La mia posizione, netta: replicare 1:1 il container web dentro il container server è l’errore più costoso e più frequente. Chi lo fa non ha fatto una scelta, ha fatto un copia-incolla.
Come si valuta un evento: i 4 criteri della matrice
Assegna a ogni evento un punteggio da 0 a 2 su quattro criteri. Somma e confronta con la soglia.
Criterio 1 — Valore di business
L’evento alimenta una conversione, un valore economico, un pubblico di remarketing o un’offerta di bidding?
- 2 — è una conversione primaria con valore (purchase, lead qualificato)
- 1 — alimenta un pubblico o una conversione secondaria
- 0 — serve solo a un report di lettura
Criterio 2 — Fragilità del dato
Quanto è esposto l’evento a perdita sul client? Gli ad-blocker intercettano le chiamate verso domini noti di tracciamento; ITP su Safari limita la durata dei cookie first-party impostati via JavaScript. Più l’evento è fragile, più guadagna dallo spostamento. Se vuoi un ordine di grandezza del problema, parti dall’articolo su quanti dati si perdono con gli ad-blocker.
- 2 — evento di conversione che dipende da script di terze parti (pixel Meta, tag Ads)
- 1 — evento GA4 standard
- 0 — evento che vive solo nel browser e non ha destinazione pubblicitaria
Criterio 3 — Destinazione
Dove deve arrivare il dato?
- 2 — serve a Google Ads (Enhanced Conversions, cioè conversioni avanzate con dati utente hashati) e/o a Meta Conversions API (CAPI, l’endpoint server-to-server di Meta)
- 1 — serve a GA4 e a un CRM
- 0 — serve solo a GA4 per lettura
Le API di conversione sono il caso d’uso più forte in assoluto: sono proprio quelle costruite per ricevere dati da un server.
Criterio 4 — Volume
Qui il punteggio è inverso: pesi il costo.
- 2 — volume basso o medio rispetto al traffico
- 1 — volume alto ma sostenibile
- 0 — altissima frequenza (page_view su un sito editoriale, scroll)
Soglia pratica: da 6 in su si va sul server. Tra 4 e 5 si valuta. Sotto 4 resta sul client.
Le tre fasce: sempre server, da valutare, meglio client
| Fascia | Eventi tipici | Perché | Destinazione |
|---|---|---|---|
| 1 — Sempre server | purchase, generate_lead, subscribe, conversioni offline da CRM |
Valore economico diretto, massima fragilità, alimentano il bidding | GA4 + Google Ads + Meta CAPI |
| 2 — Da valutare | add_to_cart, begin_checkout, view_item, sign_up, view_cart |
Utili per pubblici e segnali intermedi, ma volume più alto | GA4 + pubblici Ads/Meta |
| 3 — Meglio client | scroll, click UI, video_progress, form_start, eventi di test A/B e heatmap |
Nessun impatto su decisioni di spesa, volume alto | Solo GA4 |
Una nota che genera confusione: session_start e user_engagement non li scegli singolarmente. Viaggiano con il client GA4 del container server quando il flusso GA4 passa da lì. Se configuri GA4 in server-side, quegli eventi arrivano insieme agli altri. La scelta è a monte, sul flusso, non sul singolo evento. Il dettaglio operativo è in come collegare GA4 al container server-side.
Ibrido o full server-side: come gestire la convivenza
Tre configurazioni possibili.
| Configurazione | Qualità del dato | Costo | Complessità | Rischio doppio conteggio |
|---|---|---|---|---|
| Client puro | Bassa su conversioni | Nullo | Bassa | Nullo |
| Ibrido selettivo | Alta sugli eventi che contano | Contenuto | Media | Medio, gestibile |
| Full server-side | Alta ovunque | Alto | Alta | Basso |
Nella maggior parte dei casi l’ibrido selettivo è la scelta giusta: eventi di fascia 1 e 2 dal server, fascia 3 dal client. Costo proporzionato al valore.
Il doppio conteggio e come si evita
Per Meta CAPI e per Google Ads è normale inviare lo stesso evento da entrambi i lati: il browser copre il contesto, il server copre i casi persi. La condizione è che i due invii portino lo stesso identificatore.
window.dataLayer.push({
event: 'purchase',
event_id: 'ord-10452', // usato per la deduplica Meta
ecommerce: {
transaction_id: 'ord-10452', // usato da GA4 e Google Ads
value: 129.90,
currency: 'EUR',
items: [
{ item_id: 'SKU-881', item_name: 'Scarpa running', price: 129.90, quantity: 1 }
]
}
});
Stesso valore su event_id e transaction_id: così Meta scarta il duplicato e GA4 non conta due acquisti. Il procedimento completo è spiegato in come deduplicare eventi tra browser e server.
L’errore classico è un altro: lasciare acceso il tag GA4 web e aggiungere in parallelo l’invio server dello stesso evento senza reindirizzare il transport_url. Risultato: sessioni gonfiate e conversioni doppie. Verifica sempre in Anteprima del container server e in DebugView di GA4 prima di pubblicare.
Esempi per piattaforma
WooCommerce
Gli eventi che vale la pena portare sul server sono purchase e generate_lead (form contatto, richiesta preventivo). add_to_cart va sul server solo se usi il remarketing dinamico su carrelli abbandonati. Attenzione ai plugin che generano eventi duplicati: controlla il Data Layer su una pagina di thank you prima di decidere.
Shopify
Gli eventi del Customer Events (Web Pixel) e quelli del checkout hanno cicli di vita diversi. Il checkout_completed è il candidato numero uno per il server, anche perché è dove il pixel browser soffre di più. Gli eventi di navigazione catalogo, su store ad alto traffico, conviene tenerli sul client: il volume è alto e il valore marginale basso.
PrestaShop
Checkout multi-step: hai begin_checkout, add_shipping_info e add_payment_info. Non portarli tutti. Scegli il passaggio che segnala intenzione reale — di solito add_payment_info — e lascia gli altri sul client, a meno che tu non costruisca pubblici su ogni step.
Naming: decidilo prima, non dopo
Un container server con venti tag senza convenzione diventa ingestibile. Usa uno schema rigido:
GA4 - purchase - SS
Meta CAPI - purchase - SS
Google Ads - conversion purchase - SS
Trigger - purchase (consent marketing granted)
Il consenso cambia la selezione, non solo l’implementazione
Il server-side non aggira il consenso. Se l’utente nega la finalità marketing, l’evento verso Google Ads o Meta non deve partire, nemmeno dal container server. Chi vende il contrario ti sta esponendo a un rischio legale.
Questo ha due conseguenze sulla scelta degli eventi.
La prima: per gli eventi di fascia 1 devi propagare lo stato di consenso fino al server e usarlo come condizione nei trigger, non come filtro a valle. La configurazione è descritta in come configurare Consent Mode v2 server-side, e il controllo a posteriori in come verificare che il consenso venga rispettato.
La seconda: la copertura reale degli eventi marketing è inferiore al volume di sito. Quando stimi i costi, calcola il volume sul tasso di consenso effettivo, non sul traffico totale.
Ultimo punto, non negoziabile: nessun dato personale in chiaro nel payload. Email e telefono vanno hashati in SHA-256 prima dell’invio. E togli debug_mode dai tag in produzione: non serve a niente e sporca i dati.
Checklist di audit in 6 passi
- Esporta l’elenco completo degli eventi dal container web e dal report Eventi di GA4, ultimi 90 giorni, con i volumi.
- Marca ogni evento se è usato in una conversione, in un pubblico o in un report che qualcuno legge davvero. Se non lo è in nessuno dei tre casi, è candidato all’esclusione totale, non solo dal server.
- Stima la perdita attuale confrontando il numero di
purchaseregistrati in GA4 con gli ordini reali del gestionale. Lo scarto è il tuo punto di partenza. - Assegna i punteggi della matrice e classifica nelle tre fasce.
- Stima il volume mensile delle sole fasce 1 e 2, applica il tasso di consenso marketing e calcola il costo di hosting corrispondente.
- Implementa a ondate. Prima
purchaseegenerate_lead. Verifica per due settimane. Poi carrello e prodotto. Mai tutto insieme: se qualcosa si rompe non sai cosa.
La metrica di controllo dopo il rilascio è una sola: scostamento tra conversioni in piattaforma e ordini reali, prima e dopo. Se non si riduce, qualcosa nella configurazione non funziona — e il posto dove guardare è spesso il mismatch tra conversioni Google Ads e GA4.
Gli errori che vedo più spesso
- Replicare il container web nel server senza filtrare. Paghi richieste per eventi che nessuno guarda.
- Dimenticare
transaction_ideevent_id. Conversioni doppie, bidding falsato, e ci metti settimane ad accorgertene. - Lasciare parametri inutili o sensibili nel payload. Ogni parametro di troppo è peso e rischio.
- Non documentare la scelta. Senza un registro eventi — nome, fascia, destinazione, motivazione, data — al primo cambio di consulente la logica si perde e qualcuno ricomincia da zero.
- Valutare gli eventi una volta sola. Il catalogo cambia, le campagne cambiano. Rivedi la matrice almeno due volte l’anno.
Quando puoi procedere da solo e quando no
Puoi gestire l’audit e la selezione in autonomia se hai pochi eventi di conversione, una piattaforma standard con Data Layer pulito, un solo dominio e volumi contenuti. La matrice qui sopra ti basta.
Conviene farsi affiancare quando hai configurazioni multi-dominio o cross-domain, un checkout headless, conversioni offline da importare dal CRM, o volumi che superano il milione di eventi al mese — lì la scelta sbagliata ha un impatto economico immediato sull’hosting. Se sei a questo punto, vale la pena ragionare prima su quando conviene davvero implementare il server-side e poi su come dimensionare l’infrastruttura.
Domande frequenti
Devo per forza mandare tutti gli eventi di GA4 lato server?
No. Puoi reindirizzare il flusso GA4 verso il container server e continuare comunque a far partire dal client gli eventi che non ti servono dal server. Detto questo, una volta che il flusso GA4 passa dal container, gli eventi automatici come session_start e user_engagement viaggiano insieme agli altri: quelli non li selezioni uno a uno. La scelta selettiva ha più senso sugli eventi personalizzati e su quelli con destinazione pubblicitaria.
Se invio lo stesso evento sia dal client sia dal server, viene contato due volte?
Solo se non imposti un identificatore condiviso. Per Meta serve lo stesso event_id nei due invii, per GA4 e Google Ads lo stesso transaction_id sugli acquisti. Con l’identificatore corretto la piattaforma riconosce il duplicato e lo scarta. Senza, conti due conversioni e il bidding ottimizza su numeri gonfiati.
Gli eventi inviati dal server funzionano anche se l'utente ha negato il consenso?
Tecnicamente partirebbero, ma non devono partire. Se l’utente nega la finalità marketing, gli eventi verso Google Ads e Meta vanno bloccati a monte, usando lo stato di consenso come condizione nei trigger del container server. Per la finalità analitica, Consent Mode v2 prevede ping senza cookie che alimentano la modellazione. Il server-side non è una scorciatoia per raccogliere dati senza consenso.
Da quali eventi conviene partire nella prima implementazione su un e-commerce?
Da purchase e dai lead. Sono gli eventi con il valore economico più alto, quelli più colpiti da ad-blocker e restrizioni sui cookie, e quelli che alimentano direttamente il bidding delle campagne. Verifica per due settimane che il numero di acquisti registrati si avvicini agli ordini reali del gestionale, poi passa a add_to_cart e begin_checkout.