Blog

The sGTM request flow from browser to destination

A request leaves the browser, lands in your container, runs through clients and tags, and exits to N destinations. Here is the full path.

Most teams adopt server-side tagging without ever drawing the request path on a whiteboard. That is fine until something breaks, at which point the path matters more than any individual configuration. This is the full sequence, in the order it happens.

1. Browser fires an event

A user clicks a button. Your client GTM container has a trigger on that click. The trigger fires a tag. The tag is configured to send to your custom tagging URL rather than directly to GA4 or Meta.

2. Request leaves the browser

The HTTP POST goes to https://data.example.com/g/collect. Because data.example.com is a first-party subdomain, ad blockers do not recognise it as a tracker and let it through. Cookies for example.com are sent with the request; this is the entire reason for using a same-origin subdomain rather than a third-party endpoint.

3. The container receives the request

Your sGTM container receives the request on the /g/collect path. It checks the path against its registered clients. The GA4 client claims this path. The client parses the request body, extracts the event name, parameters, and user properties, and emits a normalised event into the container's runtime.

4. Tags fire on the event

Every tag in your container that has a trigger matching the event fires. Your GA4 tag forwards the event to the GA4 measurement protocol. Your Meta CAPI tag transforms the event into Meta's expected shape and POSTs it to Meta. Your TikTok tag does the same for TikTok. Each tag runs in parallel and independently.

5. Container responds to the browser

Once all tags have fired (or after a short timeout), the container sends a 204 No Content back to the browser. The browser is unaware of which tags ran or whether any of them failed. This is intentional: the browser does not need to know.

Where things break

  • Step 2: ad blockers, CSP, missing CORS headers. Symptom: no requests reach the container.
  • Step 3: wrong path, missing client, malformed request body. Symptom: container returns 404 or 400.
  • Step 4: tag template errors, missing required fields, downstream rate limits. Symptom: data shows in preview mode but not in the destination dashboard.
  • Step 5: timeouts, never seen by the browser. Symptom: silent. Check container logs.

When something is wrong, walk the path in order. The breakage is almost always at the earliest step that fails, and the later steps just cannot run.