What can move server-side and what can't
When you set up server-side tracking for GTM/GA4, you’re not moving everything. Some parts of your setup translate directly to server-side equivalents. Some need manual review. Some stay in the browser permanently. Knowing the difference before you start saves time and prevents surprises.
The four categories
Every tag, trigger, and variable in your web GTM container falls into one of these categories:
| Category | What it means | Examples |
|---|---|---|
| Routable as-is | Standard GA4 patterns with direct server-side equivalents. These move cleanly. | GA4 event tags with literal event names, Google tag, data layer variables, constants |
| Needs review | Likely works server-side but needs human verification. The pattern is sound, the specifics need checking. | GA4 tags with variable-based event names, custom parameter mappings, Meta CAPI or Floodlight via sGTM template |
| Browser-only | Depends on browser or DOM execution. Stays client-side permanently. | Custom HTML tags, DOM element variables, custom JavaScript variables, pixel tags |
| Unsupported in this setup | No known server-side equivalent in the GTM ecosystem. Stays in the browser unless a server-side template becomes available. | Third-party vendor tags without sGTM templates, custom integrations using browser-specific APIs |
“Unsupported” does not mean broken — it means there is no server-side path for this item in this architecture. The tag keeps working exactly as it does today in your web container.
What moves easily
Most standard GA4 tracking moves cleanly:
- Page views — the GA4 page_view event routes through sGTM without changes
- Standard events — purchase, add_to_cart, begin_checkout, generate_lead, sign_up, and other recommended events
- Custom events with literal names — if your event tag has a hardcoded event name and standard parameters, it routes as-is
- Data layer variables — these are already structured data; they translate directly
- Constants, URL variables, cookie variables — straightforward server-side equivalents exist
What needs review
Some patterns work but need human verification:
- Variable-based event names — if the event name comes from a GTM variable (like a data layer lookup), you need to confirm the variable resolves correctly in the server context
- Custom parameters — parameters that map from GTM variables may need their mappings recreated in the server container
- Third-party vendor tags with sGTM templates — Meta CAPI, Floodlight, and others have community or official sGTM templates, but configuration differs from the web version. These are examples of patterns that may be reviewable, not guaranteed compatibility.
- Consent mode — if your setup uses consent mode, it tends to push an otherwise-routable tag into “needs review.” Consent mode is an overlay on top of the other categories, not a separate fifth category. The server-side consent behavior may differ and needs testing, but consent usually means review, not impossible.
What stays in the browser
These cannot move:
- Custom HTML tags — anything that injects scripts, modifies the DOM, or reads from the page
- DOM element variables — variables that scrape text or attributes from HTML elements
- Custom JavaScript variables — variables that execute JavaScript in the browser context
- Pixel/image tags — tags that load tracking pixels in the browser
- Tags that depend on browser APIs — anything using
window,document,navigator, or cookies directly
This is not a limitation of your setup — it’s how server-side works. The browser-side tags keep running in your web container exactly as they do today. Only the GA4 path changes.
Why this matters for setup
If you try to move everything server-side, you’ll get stuck. The right approach is to identify what can move, validate that subset safely, and leave the rest where it is. Your web GTM container doesn’t go away — it just sends GA4 traffic through a different route.
The guide covers the full setup path. The assistant automates the scanning and classification.