Blog
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.
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.
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.
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.
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.
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.
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.