Server-side Google Tag Manager gives you a second GTM container that runs on your own cloud instead of the visitor's browser. That single shift recovers events lost to ad blockers and lets cookies live longer under Safari's Intelligent Tracking Prevention.
The setup
- In GTM, create a container of type Server. Copy the container config string.
- Deploy Google's provided image to Cloud Run or App Engine using that config value. A single small instance is free while you validate.
- Point a custom subdomain such as data.yoursite.com at the deployment. This is what makes cookies read as first-party.
- Add a GA4 client and GA4 tag inside the server container.
- Update the web container's GA4 tag so it sends events to your subdomain endpoint instead of Google directly.
- Verify events in GA4 DebugView before touching other platforms.
Where the wins come from
Cookies set through your subdomain look first-party, so Safari does not trim them at seven days. Traffic to your own subdomain sits outside typical ad blocker rules. Fewer marketing scripts run in the browser, so pages get lighter. PII can be hashed or stripped inside the container before events leave for vendors.
Consent routing is not optional
Handling consent once at the server layer means every downstream vendor inherits the correct state instead of each tag reimplementing it. The Seers server-side GTM migration walkthrough covers the exact CMP-to-container mapping for Google Consent Mode, which is the wiring most teams get wrong on the first attempt.
Rollout order
Migrate GA4 first, then Google Ads, then Meta Conversions API and TikTok Events API in the order that reflects your spend share. Run client-side and server-side in parallel for a week and diff the numbers before decommissioning anything.
Cost expectation
A single instance is free for testing. Production usually runs on three instances for redundancy, which typically sits in a low three-figure monthly range at moderate traffic.
Top comments (0)