Server-Side Tagging
Move tags to the server.
Server-Side Tagging is a free Digital Marketing Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Digital Marketing Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What Server-Side Tagging Is
Server-side tagging moves your tag execution out of the user's browser and into a server you control. Instead of the page firing pixels directly to Google and Meta, it sends one request to your own tagging endpoint.
That server then decides what to forward, to whom, and in what shape. The browser only ever talks to your first-party domain.
Client vs Server Flow
In the classic model, every vendor pixel runs in the browser, each making its own third-party request. In server-side, the browser sends one event to a tagging server, which fans it out.
This gives you control over data, reduces blocked requests, and shrinks the client-side code footprint that slows pages down.
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)The Tagging Server (sGTM)
Google's Server-Side Google Tag Manager (sGTM) is the most common implementation. It is a container that runs on Cloud Run, App Engine, or any host, receiving requests and processing them through clients and tags.
A 'client' parses incoming requests into events; 'tags' then send those events onward to destinations. It is GTM, but executing on the server instead of the page.
First-Party Subdomain
The key reliability win comes from mapping the tagging server to a subdomain of your own site, like sgtm.example.com via a DNS A or CNAME record.
Because requests now go to your domain, cookies set in the response are first-party and HttpOnly. They escape the harshest ITP caps and are far less likely to be blocked by ad blockers.
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 cookiesHow An Event Travels
A purchase happens on the page. The web container (or gtag) sends an event to sgtm.example.com. The GA4 client there reconstructs the hit, enriches it, and a GA4 tag forwards it to Google's collection endpoint.
The same event can simultaneously trigger a Meta Conversions API tag, a server-side Google Ads conversion, and more, all from one inbound request.
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)
Meta's Conversions API, Google's Enhanced Conversions, and TikTok's Events API are all server-to-server endpoints. They accept events directly from your server, bypassing the browser pixel entirely.
This recovers conversions lost to ad blockers and ITP, and lets you send hashed first-party identifiers (email, phone) for better matching, provided you have consent.
Data Enrichment and Control
Because the server sees the raw event, you can enrich it: append true order value from your database, strip PII you do not want shared, add server-side timestamps, or deduplicate against client events.
You become the editor of your own data, sending each platform only the minimal fields it needs. This is data minimization in practice, not just 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=deniedEvent Deduplication
If you run both a browser pixel and a server event for the same conversion, platforms must not count it twice. Deduplication uses a shared identifier.
Send the same event_id (and event_name) from both the client pixel and the server CAPI call. Meta and others match them and keep only one, giving you redundancy without inflation.
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 and Cost
The tagging server is real infrastructure. On Google Cloud Run it autoscales with traffic; you pay for compute and egress. A small site might run a couple of instances, a large one many.
Plan for monitoring, a preview server for debugging, and uptime, because if your tagging server goes down, so does measurement. It is now a production service, not a snippet.
Limits and Honesty
Server-side tagging is not a consent bypass. You still need a lawful basis, and sending data without consent is illegal regardless of where it executes.
It also does not magically restore deterministic cross-site tracking. It improves reliability and matching for consented first-party data; it is a resilience layer, not a loophole.
Implementation Checklist
A real rollout follows a sequence: stand up the server, map the subdomain, wire the web container to it, configure clients and tags, then connect CAPI destinations.
Validate with the preview/debug view, confirm dedup works, check consent gating, and only then cut over traffic. Treat it like deploying any backend service.
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 uptimeQuick Check
Test your grasp of server-side tagging.
Recap
Server-side tagging routes browser events to a tagging server on your own subdomain, which sets first-party cookies and forwards consented data to platforms via server-to-server APIs like Meta CAPI.
Benefits: fewer blocked requests, ITP-friendlier cookies, data enrichment and minimization, and event deduplication. It is a reliability and control layer, real infrastructure to operate, and never a substitute for consent.
Frequently asked questions
Is the “Server-Side Tagging” lesson free?
Yes — the full text of “Server-Side Tagging” is free to read here on the web, and the Digital Marketing Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Digital Marketing Academy course, upgrade to CoddyKit PRO.
What will I learn in “Server-Side Tagging”?
Move tags to the server. You practise Digital Marketing Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Digital Marketing Academy?
No prior experience is required. Digital Marketing Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Server-Side Tagging” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Digital Marketing Academy lesson?
Yes. Every Digital Marketing Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Why Tracking Broke
- Server-Side Tagging
- Consent Mode and CMPs
- First-Party Data Strategy