GTM Tips

Google Tag Manager has a new, AI-powered feature. It’s not flashy, it’s not prominent, and it’s not something you’d make a big deal out of. However, it contributes to an absolutely vital part of container management that many, many people neglect: version naming.

With this new feature, Google Tag Manager generates a Version Name and Version Description automatically from your workspace changes.

Container versions are often named lazily or not named at all. However, proper naming ensures that the version history is actually useful. Having a consistent log of what was updated makes it easier to review key milestones in the container history, and it also helps avoid this:

There’s a somewhat understated feature in the Google Tag Manager Community Template Gallery, which should certainly prove useful, especially to template authors.

The template status page shows a list of all the GitHub commits handled by the gallery importer, along with any associated errors that the template author should check, especially if there are noticeable problems with integrating the latest changes to the template in the gallery entry.

Tip 143: The status page

The easiest way to find the status page for any given template is to open the gallery (either via a GTM container’s Templates section or by browsing directly to the gallery), open the template you want to inspect, and then click the Status link in the sidebar:

Thanks to Giovani Ortolani Barbosa for reminding me about this possibility within Google Tag Manager and thus inspiring this blog post.

If you’re running server-side Google Tag Manager (SGTM), you’re probably sending your Google Analytics events directly to SGTM, where they are then forwarded to Google, Meta, LinkedIn, and any number of other vendor endpoints.

While doing so, you might have considered the possibility of only sending a part of the GA stream to SGTM, and having the rest go directly to Google’s CDN. Now, why would you consider this? Well, here are some reasons:

On June 30, 2025, Google announced that they are consolidating how Google’s script libraries for the web (e.g. gtm.js and gtag.js) are loaded when using a server-side Google Tag Manager container.

Before, you had the Web Container Client for loading the gtm.js file, and you had the Google Analytics 4 Client for loading the gtag.js file.

Now, you only use the former.

There is also the Google Tag Gateway option, which might be a better idea in case you really want to load Google’s scripts from a first-party context. Server-side Google Tag Manager isn’t necessarily the best content delivery option. Read more about the Google Tag Gateway here.

Read More…

One of the most popular use cases for server-side Google Tag Manager, often shared on this blog, too, is to split an incoming stream into multiple different endpoints.

Since the demise of customTask for Universal Analytics (Rest In Peace!), there hasn’t really been a solid, officially supported way of splitting a single GA4 stream into multiple endpoints. This is useful in case you want to create a “global rollup” property that combines data from multiple local sites, for example.

There are many reasons why you might want to duplicate your tags (or triggers, or variables, or templates) in Google Tag Manager.

One prime example is server-side tagging, where it’s sensible to first build and validate your tracking setup before migrating fully to a server-side approach.

Alternatively, you might want to collect analytics data to a second property, for example when you want to have a local and a global dataset for site visit data.

If you’re using server-side Google Tag Manager, Google (Advanced) Consent Mode and you’re collecting hits to Google Analytics 4, you might have noticed something odd happening when switching consent to granted state.

It looks as if your page_view hits as well as any other hits marked as “Conversions” (or key events now, I guess) are automatically redispatched to the server-side Google Tag Manager endpoint when consent is granted!

This sounds incredibly useful. You no longer need to reconfigure the dispatch of important events after consent is granted.

This will be a quick tip, but it’s here to correct my previous statements in the comments section of different articles on this blog.

When using Advanced Consent Mode, Google Analytics 4 collects hits when consent is in "denied" state. These hits have a lot of parameters stripped off them, including identifiers like the Client ID and the Session ID.

The hits will not surface in reports directly, but they will instead go through a modeling process to enrich the reports once modeled.

The FPID cookie is what server-side Google Tag Manager would prefer to use for your Google Analytics 4 tracking.

It’s a cookie set in the HTTP response from the server, and it’s flagged as HttpOnly, which means it’s only accessible by a web server running on the domain on which it was set.

There’s nothing wrong with the technology, and I do recommend that server-side setups toggle it on by default.

However, there might be cases where you want the server-side GA4 client (which handles the incoming GA4 requests) to occasionally not use the FPID cookie. Perhaps it’s because you have a custom consent system in place, or perhaps you want some GA4 measurement IDs to use the regular JavaScript cookies and others to use the FPID.

Server-side tagging is all about control. Being able to intercept, modify, and even block requests as they come in before they are dispatched to their actual endpoints is extremely valuable.

The built-in Google Analytics 4 tag template has options for modifying event parameters and user properties in the Google Analytics 4 request, but did you know you can use these options to modify some of the fields as well, such as Client ID, User ID, and event Engagement Time?