Tagging lato server
Sposti i tag sul server
Tagging lato server è una lezione Digital Marketing Academy gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Digital Marketing Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Digital Marketing Academy include 4 lezioni in totale.
Che cos'è il tagging lato server
Il tagging lato server sposta l'esecuzione dei tag dal browser dell'utente a un server sotto il Suo controllo. Anziché inviare pixel direttamente a Google e Meta, la pagina invia una singola richiesta al proprio endpoint di tagging.
Quel server decide poi cosa inoltrare, a chi e in quale formato. Il browser comunica esclusivamente con il Suo dominio first-party.
Flusso client vs server
Nel modello classico, ogni pixel del fornitore viene eseguito nel browser e invia una propria richiesta di terze parti. Nel tagging lato server, il browser invia un evento a un server di tagging, che lo distribuisce a più destinazioni.
Questo offre il controllo sui dati, riduce le richieste bloccate e limita il codice lato client che rallenta il caricamento delle pagine.
CLIENT-SIDE (old)
Browser --> google-analytics.com
Browser --> facebook.com/tr
Browser --> tiktok.com/pixel
(each blockable, leaks data)
SERVER-SIDE (new)
Browser --> sgtm.yoursite.com (1 request)
|
+----------+----------+
v v v
GA4 Meta CAPI TikTok
(server-to-server, controlled)Il server di tagging (sGTM)
Server-Side Google Tag Manager (sGTM) di Google è l'implementazione più comune. È un container che viene eseguito su Cloud Run, App Engine o qualsiasi altro host, riceve le richieste e le elabora tramite client e tag.
Un 'client' analizza le richieste in entrata trasformandole in eventi; i 'tag' inviano poi questi eventi alle destinazioni. È GTM, ma eseguito sul server anziché nella pagina.
Sottodominio first-party
Il principale vantaggio in termini di affidabilità deriva dal collegare il server di tagging a un sottodominio del proprio sito, ad esempio sgtm.example.com tramite un record DNS A o CNAME.
Poiché le richieste ora vanno al proprio dominio, i cookie impostati nella risposta sono first-party e hanno l'attributo HttpOnly. Sfuggono alle limitazioni più severe di ITP e hanno molte meno probabilità di essere bloccati dagli ad blocker.
DNS + cookie setup
--------------------------------------
sgtm.example.com -> Cloud Run host
Response header from server:
Set-Cookie: FPID=abc123; Domain=.example.com;
HttpOnly; Secure; SameSite=Lax;
Max-Age=63072000
=> first-party, server-set, long-lived
=> survives ITP better than JS cookiesCome viaggia un evento
Un acquisto avviene nella pagina. Il container web (o gtag) invia un evento a sgtm.example.com. Il client GA4 ricostruisce l'hit, lo arricchisce e un tag GA4 lo inoltra all'endpoint di raccolta di Google.
Lo stesso evento può attivare simultaneamente un tag Meta Conversions API, una conversione Google Ads lato server e altro ancora, tutto da un'unica richiesta in entrata.
Event payload sketch (purchase)
--------------------------------------
{
"event_name": "purchase",
"client_id": "FPID.abc123",
"value": 89.90,
"currency": "EUR",
"transaction_id": "T-10482",
"items": [{"id":"SKU1","qty":2}],
"consent": {"ad_user_data":"granted"},
"user_data": {"em_hashed":"<sha256>"}
}Conversions API (CAPI)
Conversions API di Meta, Enhanced Conversions di Google ed Events API di TikTok sono tutti endpoint server-to-server. Accettano eventi direttamente dal server, evitando completamente il pixel del browser.
Questo recupera le conversioni perse a causa degli ad blocker e di ITP e consente di inviare identificatori first-party sottoposti ad hashing, come e-mail e telefono, per un matching migliore, a condizione di disporre del consenso.
Arricchimento e controllo dei dati
Poiché il server vede l'evento non elaborato, è possibile arricchirlo: aggiungere il valore effettivo dell'ordine dal database, rimuovere i dati PII che non si desidera condividere, aggiungere timestamp lato server o deduplicare rispetto agli eventi client.
Si diventa così editor dei propri dati, inviando a ogni piattaforma solo i campi minimi di cui ha bisogno. Questa è la minimizzazione dei dati applicata concretamente, non solo una policy.
Server-side transform rules
--------------------------------------
INCOMING -> TRANSFORM -> OUTBOUND
- hash email (SHA-256) before send
- drop raw IP for non-consented users
- overwrite value w/ DB net revenue
- add event_id for dedup w/ pixel
- block forwarding if consent=deniedDeduplicazione degli eventi
Se si eseguono sia un pixel del browser sia un evento server per la stessa conversione, le piattaforme non devono conteggiarla due volte. La deduplicazione utilizza un identificatore condiviso.
Invii lo stesso event_id (e event_name) sia dal pixel client sia dalla chiamata CAPI server. Meta e le altre piattaforme li associano e ne mantengono uno solo, offrendo ridondanza senza gonfiare i risultati.
Dedup with event_id
--------------------------------------
Browser pixel:
fbq('track','Purchase',{...},
{eventID:'evt_T-10482'})
Server CAPI:
event_id: 'evt_T-10482'
event_name: 'Purchase'
Meta sees same id+name -> counts onceHosting e costi
Il server di tagging è un'infrastruttura reale. Su Google Cloud Run si adatta automaticamente al traffico; si paga per le risorse di calcolo e il traffico in uscita. Un sito piccolo potrebbe usare un paio di istanze, uno grande molte di più.
Preveda il monitoraggio, un server di anteprima per il debug e un'adeguata disponibilità, perché se il server di tagging si arresta, si interrompe anche la misurazione. È ormai un servizio di produzione, non uno snippet.
Limiti e trasparenza
Il tagging lato server non è un modo per aggirare il consenso. È comunque necessaria una base giuridica e l'invio di dati senza consenso è illegale, indipendentemente da dove vengono elaborati.
Inoltre, non ripristina magicamente il tracciamento cross-site deterministico. Migliora l'affidabilità e il matching per i dati first-party basati sul consenso; è un livello di resilienza, non una scappatoia.
Checklist di implementazione
Un'implementazione reale segue una sequenza: predisporre il server, collegare il sottodominio, collegare a esso il container web, configurare client e tag, quindi connettere le destinazioni CAPI.
Convalidi con la vista di anteprima/debug, verifichi che la deduplicazione funzioni, controlli la gestione del consenso e solo allora trasferisca il traffico. Lo consideri come la distribuzione di qualsiasi servizio backend.
Rollout checklist
--------------------------------------
[ ] Deploy sGTM (Cloud Run)
[ ] Map sgtm.example.com (CNAME)
[ ] Web container -> send to sGTM
[ ] GA4 client + GA4 tag configured
[ ] Meta CAPI tag + event_id dedup
[ ] Consent checks on every tag
[ ] Preview/debug verified
[ ] Monitoring + alerts on uptimeVerifica rapida
Verifichi la propria comprensione del tagging lato server.
Riepilogo
Il tagging lato server instrada gli eventi del browser verso un server di tagging sul proprio sottodominio, che imposta cookie first-party e inoltra i dati basati sul consenso alle piattaforme tramite API server-to-server come Meta CAPI.
Vantaggi: meno richieste bloccate, cookie più compatibili con ITP, arricchimento e minimizzazione dei dati e deduplicazione degli eventi. È un livello di affidabilità e controllo, un'infrastruttura reale da gestire e non sostituisce mai il consenso.
Domande Frequenti
La lezione «Tagging lato server» è gratuita?
Sì — il testo completo di «Tagging lato server» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Digital Marketing Academy, passa a CoddyKit PRO. Il corso Digital Marketing Academy include 4 lezioni in totale.
Cosa imparerò in «Tagging lato server»?
Sposti i tag sul server Eserciti Digital Marketing Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Digital Marketing Academy?
Non è richiesta alcuna esperienza precedente. Digital Marketing Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Tagging lato server»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Digital Marketing Academy?
Sì. Ogni lezione Digital Marketing Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Perché il monitoraggio non funziona più
- Tagging lato server
- Consent Mode e CMP
- Strategia dei dati proprietari