Google Tag Manager

UPDATED 20 March 2026: Shortly after publishing this article, Google Cloud changed how Load Balancer frontend certificate management works. Instead of directly mapping a frontend to a certificate, GCP now wants you to use a certificate map. Luckily, creating one is (fairly) simple, and I’ve updated the guide below to instruct how to do this.

If you’re running server-side Google Tag Manager on Google Cloud Run behind an External Application Load Balancer, your tagging endpoint is currently reachable only over IPv4 with a default installation.

Server-side Google Tag Manager is essentially a server application (running on Node.js), which Google has helpfully composed into a Docker image.

Docker, on the other hand, is an environment for creating, sharing, and running applications, right from the Docker platform itself.

In short, it’s a way to package an entire application and its execution environment, so that anyone (or any environment) can deploy a Docker container and instantly get the application up and running.

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…

This is a guest post by Jude Nwachukwu Onyejekwe. He is a prolific content creator, and he curates the DumbData portal, which is full of great, free resources for measurement enthusiasts.

In this article, he shares some useful learnings for working with click identifiers.

Click IDs are URL parameters used by ad platforms. They are attached to outgoing links (ad clicks), so that when the user lands on a website, the URL would include this identifier. Pixels and scripts that then run on the landing page can take this identifier and forward it to the vendor, who can then correlate behavior on the landing page with the ad that was clicked.

Google’s Consent Mode is a way to control how tags react to the user’s consent for different tracking purposes. It is specifically designed to work with Google’s tags, but especially through Google Tag Manager, you can use Consent Mode’s features and APIs to control other tags, too.

Consent Mode comes in two “flavors”:

• Advanced Consent Mode is specifically designed for Google’s products. Tags for GA4, Ads, and Floodlight are sensitive to the user’s consent choices and change their behavior accordingly. Advanced Consent Mode is very easy to implement because it basically requires no changes to tags’ existing triggering mechanisms.

  Read More…

Google Tag Manager users received an email on March 11th, where Google announced a very cryptic update to Google Tag Manager:

As is typical with Google’s email communications, the email raised more questions than it answered.

Even though I tackled the email in a LinkedIn thread, there’s still a lot of misunderstanding (and misinformation) going about.

In this short article, I’ll explain what Google is going to do on April 10th.

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.

In this guide, I’ll show you how to add first-party cookie values client-side, which your server-side Google Tag Manager processes can then access.

You might be wondering: “Why bother?”. After all, if server-side GTM is running same-site with the website sending the requests, why can’t it just read the cookies on its own, right?

Well, true. But there are cases where the website and web server seem to be same-site but are in fact not. One such case is Shopify’s Checkout Extensibility.

There are two new custom templates available in server-side Google Tag Manager. These templates have been designed to facilitate Piwik PRO tracking in a server-side container.

1. Piwik PRO Client -> This Client template interacts with the Piwik PRO JavaScript tracker and lets you route Piwik PRO tracking through a server-side GTM container. GitHub repo.
2. Piwik PRO -> The tag template works in unison with the Piwik PRO Client, forwarding the hits to the Piwik PRO endpoint. GitHub repo.

Read this article to learn more about how these templates work.