Summary
A server-side GTM container normally has one client per tag type. From the Google documentation: “A client is a Tag Manager resource type that intercepts certain types of incoming HTTP requests and generates events that are passed to a destination, like Google Analytics.”
For example, the GA4 client claims everything arriving on the /g/collect path. That gives you a single, undifferentiated funnel: all client-side GA4 data collection lands in one pile, and the only lever you have is the event.
Considering that when using Server Side GTM, it’s normal, and indeed, advantageous to reduce client side tagging to the minimal GA4 requirements, triggering one tag execution per event: page_view, purchase, generate_lead, and so on – client side containers therefore, send the data using one tag type to the server side container where one GA4 client picks up the requests..
Following this, on the server side container, using the Client Name in a tag trigger is a normalised convention.
The anti-pattern
The data collected during one client side event is normally used across multiple server side tag types.
So, having one server side client responsible for the execution of multiple tag types exhibits unwanted behaviour. Depending on the type type, and data activation, data might need to be redacted, enhanced, transformed, or routed to a different destination.
Therefore, triggering tags, and transformations based on the client name is not ideal.
Solution
The pattern being built here replaces that with a custom client that claims requests based on the measurement ID sent by the client side GA4 tag.
Because a claimed request is stamped with the name of the client that claimed it, and because triggers can filter on Client Name, the measurement ID effectively becomes a routing key.
One stream of client-side collection arrives at the server; which tags fire, which destinations receive data, and what enrichment or redaction is applied are all decided by which client won the claim.
This is the substantive capability of a custom client template we’ve developed. Essentially a direct copy of the current GA4 client but with conditional logic to manage the claim:
What’s essential is to ensure that there is a backup client to handle the remaining requests or the sGTM container will start throwing 404 errors as no client claims the request – don’t leave a request hanging, it’s impolite…
Why this matters: the real applications
Once measurement ID is a routing key, several things become possible that are awkward or impossible with a single stock client.
Destination control and divergence. Genuine client-side collection can be diverted to different destinations per measurement ID. One site, one gtag deployment, but hits tagged with different IDs land in different GA4 properties, different ad platforms, or different warehouses, decided server-side and changeable without a site release.
Property governance. Which GA4 property receives which data becomes a server-side decision rather than a front-end one. A 360 property and a free property can be fed different subsets of the same stream; a client property and an agency property can be separated cleanly; a test ID can be quarantined so it never contaminates production data.
Enrichment scoped by route. Transformations and variables can differ per client, so one route gets item-list attribution, user attributes, or Firestore lookups while another stays lean. No conditional spaghetti inside a single tag set.
Obfuscation and redaction. A route can strip, hash, or coarsen identifiers before anything leaves the server, giving different privacy postures for different destinations from the same inbound hit.
Governance and allow-listing. The allow-list is the policy. An ID not on any aware client’s list falls through to the default GA4 client and behaves normally; an ID that is listed gets exactly the treatment defined for it. Combined with the ed.allowedEvent flag on the GA4 Client trigger, you have both coarse control (which route) and fine control (which events within a route).
Blast-radius containment. Because the aware client claims by explicit allow-list and declines everything else, new routing rules ship without any risk to existing collection.
Measurement ID is the right lever but G-12345 is the wrong value
The typical accepted measurement ID today is G-12345. Using measurement ID with a genuine value has advantages over another lever, or a place holder value. Setting a measurement ID is part of the client side setup. Different events will be used for different destinations and activations. Using a unique configuration for data that’s never destined for GA keeps your genuine GA data payload clean. Using one client side GA4 config doesn’t afford this capability.
Accepting the MEasurement ID is the right tool for the job, the problem with G-12345 is that it has no genuine GA4 configuration behind it. That creates real risk rather than a harmless stub:
- No real property to fall through to. Every other route in this design has a valid GA4 property as its safety net. This one does not, so any behaviour that depends on a working GA configuration (consent signalling, session stitching, the linker, FPID cookie handling) is being exercised against nothing.
- The client-side half is fictional. For a hit to carry tid=G-12345 at all, something on the page has to be configured to send it. That is either a hand-forged request or a fake gtag configuration, and neither exercises the code path real traffic will take.
- It is not a value you control. A short, guessable, non-owned ID is exactly the kind of string that could collide with something real, or be sent deliberately by a third party. A client sitting at priority 99999 that claims on an ID you do not own is an unauthenticated route into your tag configuration.
- Placeholders survive. A test ID in an allow-list at the highest priority in the container is the kind of thing that gets published and then forgotten.
Recommendation: replace G-12345 with a real measurement ID from a real GA4 property that you own and that is deliberately designated for this route, either a dedicated test or staging property, or the genuine second-destination property this pattern is ultimately for. The test then exercises the actual path: real gtag on the page, real ID, real property, real consent and identity plumbing, and a meaningful comparison against what lands in the default GA4 route.