How server-side GTM works
This article describes the server-side architecture that GetServerSide uses: one web GTM container, one server GTM container running on Cloud Run, a temporary shadow GA4 property for validation, and a controlled production cutover. The point is not to "move everything server-side." The point is to set up safely, validate before you switch live, and end up with one maintained server-side setup.
This article is the architecture introduction. The guide is the reference for the full path.
Quick reference diagram
This is what you're building toward: existing browser-side tracking stays in place during validation, while a second server-side path is added temporarily so you can test and compare before switching production.
Server-Side Architecture
Browser path
This is the normal browser-only setup most teams already use before adding any server-side tagging.
Server path
This is the change in this setup: the website still uses Web GTM, but now forwards your data to your server-side tagging layer.
Both paths start with the same website and the same Web GTM runtime. The browser path is the default non-server-side path most teams already use. The server path is the additional path this guide adds, forwarding data through your server-side tagging layer into your GA4 property.
Website
Your website and your customer's session in the browser.
Web GTM
The JavaScript running on your website that watches events and communicates with services such as GA4.
Browser GA4
Google's Analytics servers receiving the normal browser-side data. This is the default path most teams already have.
Your Tagging Service
Your server-side tagging layer, running GTM on your infrastructure. This is the new part we add so data can flow server-side to GA4 and, if needed later, to other destinations.
Server GA4
Google's Analytics servers receiving the server-side copy of the data in a separate GA4 property.
How the setup works
The setup uses a temporary shadow property as a safe validation environment. Your existing production GA4 property stays untouched until validation is complete.
- Connect and classify — Understand what you have. Which tags can move server-side, which stay in the browser, which need manual review.
- Validation — Create a temporary test GA4 property and server container. Route a copy of traffic through the server path to the test property. Compare results.
- Go live — Once the server path validates, update your existing production setup to route through the server container. Retire the temporary setup.
- Health checks — Check the production server-side setup for drift, missing events, and routing failures over time.
The temporary property exists only for validation. After cutover, you have one production setup routed through your server container.
Why a temporary shadow property
If you validate against your production property directly, you risk polluting your production data during testing. A separate temporary property gives you a clean validation environment where mistakes don't affect your reporting.
The shadow property is not permanent. After cutover, you remove it.
Why both paths start from one web GTM container
One shared web container keeps event production centralized. You define the client-side instrumentation once, then branch it into:
- the normal browser GA4 destination (your existing production path)
- the server forwarding path (through sGTM to the shadow property during validation, then to production after cutover)
That reduces drift. If browser and server collection start from different client-side setups, validation becomes harder because the inputs are already different before the server layer even runs.
How the architecture works
This section focuses on the server-side path you are adding. The browser path is not repeated in the diagrams below because it is already shown in the quick reference diagram above.
How the Architecture Works
1
Your website loads and the customer does something worth tracking
A page loads, a purchase starts, a form submits, or another event happens. Web GTM is already present on the page and can react to that event.
2
Web GTM packages the event and forwards it to your server-side layer
This is the key architecture change. In addition to the normal browser-to-Google path, Web GTM now also sends a server-side request to your infrastructure.
3
Your tagging service receives, processes, and standardizes the request
In the reference architecture, the server runs on Cloud Run. It hosts the server-side GTM container, applies the tagging logic, and becomes the business-controlled controller for the server path.
4
The processed event is sent into a separate GA4 property
That separate property is what makes comparison possible. It gives you a clean server-side dataset instead of mixing everything together in the default browser-side property.
Here is what is inside the server-side layer — the part you actually deploy and configure.
Server-Side Component Details
Server-Side Layer
Runs on infrastructure you control
You will deploy two services here: a Tagging Service for production traffic and a Preview Service for GTM debugging and preview mode.
Your tagging service
The production service. This is the endpoint that receives the forwarded request from the browser and passes it into your server-side GTM container.
Preview service
The debugging service. It supports GTM preview mode so you can inspect requests and tag behavior, but it is not the production data path.
Server-side GTM setup
This is the configuration inside your server-side GTM container.
In practical terms, this includes things like:
- which incoming requests it accepts
- how it interprets those requests
- which destinations it sends data to
- what fields it adds, changes, or passes through
You examine, create, and edit this in the Google Tag Manager web UI, specifically inside the server container workspace.
GTM debug view
This is GTM's web-based debugging interface for the server-side setup.
You open preview/debug mode from GTM, then use it to inspect what the server container is receiving and doing.
The preview service exists to support that debugging flow, so it is not the production path. It is the debug path for the server-side GTM setup.
In this guide these services run on Cloud Run, but the architectural role is the same on any equivalent host.
GTM Preview is GTM's web-based debug interface for the server-side setup. In this architecture, the preview service exists to support that debugging flow; it is not the production data path.
Why the server container runs on Cloud Run
Cloud Run is the narrowest infrastructure choice that fits this architecture cleanly:
- GTM server containers already fit the request-driven model well
- you get a standard HTTPS endpoint for the server path
- the deployment is explicit enough that you can inspect it, test it, and own it
This architecture is opinionated about Cloud Run because the goal is not to cover every hosting pattern. It is to define one repeatable setup path that can actually be validated.
What this setup path is for
This path is for teams that want:
- a specific, understandable server-side setup for GTM/GA4
- safe validation before touching production
- a single maintained server-side setup, not a permanent dual system
- ongoing health checks after you switch live
It is a good fit when the goal is a controlled setup with clear validation, not a rushed production cutover.
When not to use this approach
This is not the right model if you need:
- a general-purpose event routing platform
- a managed done-for-you tracking vendor
- a broad multi-destination server-side data pipeline
- an architecture that removes the web GTM container entirely
GetServerSide is narrower than that by design. The architecture is opinionated so the setup path and validation workflow can stay concrete.
How to use this with the guide
Read this article first if you want the framing and tradeoffs. Then use the guide for the full reference:
- platform setup and prerequisites
- scanning and classification
- server-side validation
- production go-live
- ongoing health checks
This article explains why the architecture exists. The guide covers the full setup path.