Lesson 1 of 8
What Server-Side Tagging Is, And Why
In a normal GTM setup, every tag runs in the visitor's browser. The browser loads the container, builds each request, and sends it straight to Google, Meta, and every other vendor. That is client-side tagging, and it is what the rest of this playground teaches.
Server-side tagging adds a second container that runs on a server you control, usually on Google Cloud Run or a host like Stape. The browser sends one request to your server endpoint; the server container then decides what to forward, and to whom, server-to-server.
Why teams move server-side
- Data quality: fewer hits lost to ad blockers and tracking-prevention.
- Cookie lifetime: first-party cookies set server-side survive browser caps like Safari ITPITPIntelligent Tracking Prevention: Safari's anti-tracking feature that caps JavaScript-set cookie lifetimes, often to 7 days.'s 7-day limit.
- Control: you decide what data leaves your server and what each vendor receives.
- Performance: heavy vendor pixels move off the page, so less runs in the browser.
The trade-offs (be honest about these)
- It needs real infrastructure (Cloud Run / a host), which costs money and effort to run.
- It is harder to set up and debug than client-side.
- It does not magically "fix" consent, you still must respect the user's choices.
Key takeaway
Server-side tagging routes the browser through a container you own, then forwards data server-to-server. You gain data quality, durable cookies and control, at the cost of infrastructure and complexity.