Blog

How to Verify Your Server-Side GTM (sGTM) Is Working

Published 2026-07-15

verify server-side gtmsgtm not workingserver-side tagging setupcheck server container

"We set up server-side GTM (sGTM), but I'm not confident it's actually measuring through the server." This is a very common worry for teams that have adopted sGTM. Unlike the traditional setup where tags fire straight from the browser, sGTM adds a server hop in the middle — which makes it much harder to see where things break. You think you configured it, but if the server never receives the request, nothing gets recorded in GA4 or Ads.

Does any of this sound familiar?

After switching to sGTM, your GA4 events dropped or stopped
Watching browser traffic, requests aren't going to your own tagging-server domain
Not a single request shows up in the sGTM preview
GA4 was working before, but measurement vanished the moment you set transport_url

This guide organizes how to verify sGTM is working, what to look at, and the common failures — all from a practical, operations-first view.

First principle: where does sGTM actually route through?

The biggest reason sGTM verification goes wrong is not picturing the data flow as a single line. With sGTM, the browser doesn't send straight to GA4 — a server on your own domain (the tagging server) sits in between. Start by internalizing this flow.

Stage	What happens	Typical pitfall
① Send	The browser sends to a first-party tagging server (e.g. `gtm.example.com`)	`transport_url` not set, so it goes straight to Google
② Receive	The container on the server (Cloud Run, etc.) receives the request	Container not deployed / wrong URL
③ Forward	The server distributes and forwards to GA4, Ads, Meta	Client/tag mapping is misconfigured

The key point: sGTM has two containers — a "web container" (browser side) and a "server container" (server side). Even if a tag fires on the browser side, if its destination isn't pointed at the server, it's just going straight to Google as before — that is not "routing through sGTM." The whole aim of sGTM is to make cookies first-party via your own domain, so they're less affected by ITP (Safari's tracking prevention) and ad blockers. That's exactly why you need to verify the server is being routed through at all.

Step 1: Check the browser's destination (transport_url)

First, look at where the browser is sending. If this isn't pointed at your own tagging server, sGTM never even begins.

Open the page you want to check and open the "Network" tab in DevTools
Filter for collect
Watch the /g/collect request that fires on page interaction and look at its destination domain
Confirm the destination is a first-party domain of yours like gtm.example.com (if it's still google-analytics.com or analytics.google.com, it isn't configured)

What points the browser at your own domain is the transport_url parameter on the GA4 configuration tag (or Google tag). If it's blank or mistyped, the browser keeps sending straight to Google.

Common pitfall: you put your server container's URL in transport_url, but the DNS for that subdomain doesn't point to the server — so the request never arrives and fails. Even if the destination domain looks right, whether that domain actually resolves to the server is a separate matter.

Step 2: Is the server container deployed and receiving?

Even if the destination is your own domain, if the server container behind it isn't running, nothing gets received.

Is the tagging server (Cloud Run or similar hosting) deployed and running?
When you hit the tagging-server URL (e.g. https://gtm.example.com), does it return a healthy response?
Does the destination domain from Step 1 match the domain where you actually deployed the server?

What it tells you: whether the server exists and can accept requests (②). What it can't tell you: whether it then forwards correctly to GA4 or Ads (③ comes in the next step).

Common pitfall: the container may be deployed, but if you forgot the required Container Config ID, the server starts up empty — it receives requests but processes nothing. "It's running" does not mean "the config is loaded."

Step 3: Trace receive-to-forward in the sGTM preview

sGTM has a preview mode dedicated to the server side. This is the heart of verification.

Launch "Preview" in the sGTM (server container) admin
Open the target site in another tab, interact with it, and watch whether requests arrive in the preview
For each arriving request, confirm the GA4 tag, Ads tag, etc. fire, and that the destinations (Outgoing HTTP Requests) are what you intended

What it tells you: the server is receiving the request and forwarding it to each destination (the full ② → ③ chain). Only once you can see this can you say it's "routing through sGTM."

Common pitfall: if no request arrives in the preview at all, the problem is upstream (Steps 1–2), not the server. Conversely, if requests arrive but the GA4 tag doesn't fire, suspect a client, trigger, or mapping misconfiguration. "Doesn't arrive" and "arrives but isn't forwarded" send you to completely different places.

Step 4: Verify first-party cookie behavior and ad-blocker resilience

Preview mode confirms the data flow, but two of sGTM's core benefits — longer cookie lifetimes and reduced ad-blocker impact — need their own checks.

Check cookie expiry in Safari

Open Safari on the target site, then go to Develop > Show Web Inspector > Storage > Cookies. Find your tracking cookies (_ga, _gcl_aw, or any custom cookie set by your sGTM). Check the expiry date:

If it shows 1–2 years from today, the cookie is being set correctly as first-party by your server.
If it shows 7 days from today, Safari's ITP is capping it — this usually means the IP address of your tagging-server subdomain does not match your main domain's IP, so Safari classifies it as a "CNAME cloak" and shortens the lifetime.

This is easy to miss because Chrome won't exhibit the same behavior. Related: how Safari's ITP causes conversions to be lost.

Test with an ad blocker active

Enable a popular ad blocker (uBlock Origin, AdGuard) in your browser, then load your site and check the Network tab:

Do /g/collect requests still reach your first-party domain?
Does the sGTM preview still show incoming requests?

Be aware that major filter lists (EasyPrivacy, AdGuard) now include rules that target common sGTM subdomain patterns such as sgtm. or gtm. prefixes. If your subdomain is blocked, consider choosing a less obvious subdomain name. For more on how ad blockers affect tracking, see how ad blockers block pixels and what to do.

Check Cloud Run logs for silent production failures

The preview is a debugging tool — it doesn't tell you what happens in production when you're not looking. sGTM has no built-in health dashboard, so failures in production are silent unless you actively monitor them.

In the Google Cloud Console, go to Cloud Run > your tagging service > Logs (or use Logs Explorer) and look for:

Error- or Warning-level entries — these often indicate a tag failing to forward, a misconfigured variable, or a timeout when reaching a destination endpoint.
Volume drops — a sudden decrease in request volume may indicate a DNS change, a certificate expiry, or a container scaling issue, none of which appear in preview mode.
logToConsole output — if you use a Logger tag or custom templates that call the logToConsole API, their output appears in stdout logs. Filter with logName: "stdout" in Logs Explorer.

Set up a Cloud Monitoring alert on error rate or request count so you're notified when something breaks, rather than discovering it days later when conversion numbers drop.

Common failures with sGTM

When you're not routing through sGTM, the cause usually comes down to the following. Suspect them top to bottom.

1. transport_url isn't set

The most frequent one. If you don't add transport_url to the GA4 configuration tag (Google tag) on the web-container side, the browser keeps sending straight to Google and the server is never touched.

2. The server container isn't deployed / is stopped

When you haven't deployed the container to hosting (Cloud Run, etc.), or it's stopped. Step 2 checks whether the URL responds.

3. The first-party (subdomain) DNS isn't configured

Even if you prepare a subdomain like gtm.example.com, requests won't arrive unless DNS points it at the server. Check the DNS setup and the validity of the certificate (HTTPS).

4. Mapping / client misconfiguration

Cases where the server receives but doesn't forward — the GA4 client isn't enabled, or the tag's trigger conditions don't match. Trace forwarding in the Step 3 preview.

What checking on your own machine can't tell you

All of the steps above are useful, but checking once on your own machine has two structural limits.

Your environment isn't your visitors' environment. One of sGTM's main purposes is to reduce the impact of ITP (how Safari's ITP causes conversions to be lost) and ad blockers. Yet if the browser you check with is Chrome with extensions off, you can't reproduce the very conditions you were trying to work around. Losses that appear on real Safari or another environment won't show up in your single local pass.
Conversions involving an ad click are hard to verify. To properly see "does it really track through the server via an ad," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.

Because sGTM inserts a server hop, it's structurally prone to "works on my machine, but goes missing under real visitor conditions." That's exactly why verifying on the real production path matters.

A checklist to verify with confidence

Start with what's free and easy, and knock these out in order.

Frequently asked questions

Q. Why did my GA4 events drop after I set up sGTM? A. A common case: the moment you set transport_url, the browser's destination switched to your own server — but that server (container deployment, DNS) wasn't ready, so the request hits a dead end. Work through Steps 1–3, checking destination, receiving, then forwarding in order.

Q. If tags fire on the browser side, is sGTM working? A. No. Even if the web-container tag fires, if the destination is still Google (transport_url not set), it's the traditional direct send and the server isn't routed through. You can only judge after confirming the destination is your own domain and the server is receiving.

Q. No requests arrive in the sGTM preview. A. It's very likely an upstream problem, not the server. Check ① the transport_url setting, ② the subdomain's DNS, and ③ the container's deployment status. "Nothing arrives in preview" isolates it to "not reaching the server."

Q. GA4 is working, but only the Google Ads conversions don't come through. A. A classic isolation gap: in the sGTM server container, GA4 forwards fine but the Ads tag/mapping isn't configured. In the preview, confirm the outgoing request for Ads is actually being sent. Related: what to check when Google Ads conversions aren't tracking.

Q. Can I verify Meta and enhanced conversions through sGTM too? A. The approach is the same — trace forwarding to each destination in the preview. For individual checks see verifying the Meta CAPI (Conversions API) and verifying enhanced conversions are sent correctly, and for the big picture, the GA4 conversion tracking guide.

Conclusion: don't stop at firing — verify it routes through the server and forwards

Verifying sGTM isn't complete with browser-side tag firing alone. What matters is going further: confirming that the destination points at your own domain (①), the server receives (②), and it forwards correctly to GA4 and Ads (③) — that this whole chain connects in production. If it stops upstream, no amount of healthy browser-side firing gets the data recorded.

ConversionOK runs your live page in an independent, isolated browser and intercepts the requests actually sent to your tagging server, then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your server-side measurement.