Server-side tagging, using a server-side GTM container to proxy and forward analytics events, is positioned as the solution to ad blockers, ITP, and third-party cookie deprecation. It offers real benefits, but it also introduces new complexity and new failure modes that require careful auditing.
What is server-side tagging?
In a traditional (client-side) setup, every tag fires directly from the user's browser. The browser loads GTM, GTM loads your GA4 tag, and the GA4 tag sends a hit directly to Google's collection endpoint. Each of those network requests is visible to the browser, to extensions, and to any ad blocker or privacy tool installed.
In aserver-side setup, your site sends a single event to a tagging server you control, typically running onGoogle Cloud Runor App Engine. That server receives the event, processes it, and fans it out to GA4, ad platforms, and any other destinations using theGA4 Measurement Protocol. The browser only ever talks to your own domain.
Average client-side GA4 hit loss due to ad blockers
Server-side cookie lifetime vs 7-day ITP limit client-side
Browser request instead of many, reducing payload exposure
Client-side vs server-side: the real differences
The decision to move to server-side tagging involves real trade-offs. Both approaches have distinct advantages and limitations, understanding these is essential before committing to migration or auditing an existing implementation. For a side-by-side breakdown of the consent implications, seeconsent mode vs server-side tagging.
Setting up server-side tagging for GA4
A complete server-side GA4 implementation involves provisioning a tagging server, updating your web container, and validating that events are flowing correctly end to end. Consent signals must continue to flow through the server container — see our guide toserver-side consent in GA4for the timing rules that catch most teams off guard.
Provision a server-side GTM container
Create a new Server container in GTM. Deploy it to Google Cloud Run (the managed option) or self-host on App Engine. Set a custom domain on your own subdomain (e.g. metrics.yourdomain.com) so requests appear first-party to the browser.
Update your web GTM container
In your existing web container, change the GA4 Configuration tag's transport URL to point to your tagging server's endpoint rather than https://www.google-analytics.com. All GA4 hits will now route through your server.
Add a GA4 client on the server container
On the server container, add a GA4 client to receive and parse incoming Measurement Protocol hits. This client decodes the events sent from your web container and makes them available as GTM event data.
Configure a GA4 tag on the server container
Add a GA4 tag on the server side. Set the Measurement ID and configure which events to forward. This is where you can enrich events with server-side data before they reach Google's collection endpoint.
Validate end-to-end in DebugView
Enable GA4 DebugView and trigger events on your site. Verify events appear in DebugView with correct parameters. Check that your server-side GTM preview mode shows events being received and forwarded correctly.
Monitor for data loss
For the first 2 to 4 weeks, compare event counts and session counts between your server-side implementation and any baseline period. Watch for unexplained drops in specific event types, which can indicate client-to-server transport issues.
One area where the server container can help is removing the duplicate hits that creep in when client-side and server-side tagging coexist during a migration. Our walkthrough ondeduplicating web and server eventscovers the specific transaction_id and event_id patterns to use.
Server-side tagging audit plan
Validate
- Confirm server container is deployed on a custom subdomain of your own domain
- Verify transport URL in web GA4 tag points to your server endpoint, not google-analytics.com
- Check that GA4 client on server container is correctly parsing incoming hits
- Confirm DebugView shows events with all expected parameters
- Validate server-side cookie is being set with correct expiry and domain scope
Fix
- If events show in DebugView but miss parameters, check server-side tag variable mapping
- If session counts drop after migration, confirm client ID is being forwarded in the transport URL
- If ad conversions are missing, ensure ad platform tags on server container have correct click ID forwarding
- If cookies are not persisting, verify server sets HttpOnly first-party cookie with correct domain
Watch for
- Event volume discrepancy greater than 5% between pre- and post-migration periods
- Client ID inconsistency causing user count inflation
- Missing consent signals not being respected server-side
- Cloud Run cold start latency causing event delivery delays under high traffic
Server-side tagging implementation checklist
- Server container deployed on custom subdomain (not.googletagmanager.com)
- Web GA4 tag transport URL updated to server endpoint
- GA4 client added to server container and parsing events correctly
- Server-side GA4 tag configured with correct Measurement ID
- First-party cookie set server-side with multi-year expiry
- Consent mode signals forwarded from web to server container
- Event volume validated against pre-migration baseline
- Ad platform tags migrated to server container
Related guides to read next
GA4 Conversion Tracking Setup
Ensure your conversions are correctly configured whether using client-side or server-side tagging.
Consent Mode v2 Guide
Understand how consent mode integrates with server-side tagging setups.
GA4 Custom Events Audit
Audit the custom events you're forwarding through your server-side container.
Ready to audit your GA4 property?
Run a full GA4 audit in under 2 minutes. Free to start.