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.

Continue reading

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.

Continue reading

In a recent update to server-side tagging in Google Tag Manager, Google switched the default deployment of a server-side tagging backend from Google App Engine to Google Cloud Run. Now, when you create a new container and choose the automatically provisioned tagging server option, this service will be created in Google Cloud Run instead of in Google App Engine. While I’ve written about Cloud Run before, this update gives me an opportunity to review what actually happens when you provision a Cloud Run environment, how you can upgrade it, and how you can add enhancements such as multi-region load balancing to it (with ease, I might add!

Continue reading

In January 2020, when Google Tag Manager’s server-side tagging was first introduced to the general public at SuperWeek, I wrote a flurry of tweets, sharing my vision of a server-side tagging future. In one of the tweets, I discussed how you could do these: Hit validation and fixing before the hit is sent to the endpoint PII and privacy controls for the requests before dispatch Fast forward to today, over three years later, and we are finally treated to a feature that grants us scalable controls to properly interrupt data flows within server-side GTM.

Continue reading

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.

Continue reading

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?

Continue reading

I have been a strong supporter of server-side tagging, in particular Google’s server-side tag management solution. I admire the way it seeks to readjust the balance of control that typically has been in favor of the marketing vendors whose JavaScript libraries have been free to wreak havoc in the user’s browser. By inserting a buffer between the user and the vendor, the owner of the server-side tagging setup can take control over what data the marketing vendors can actually process of the user.

Continue reading