Simo Ahava's blog

While Google App Engine, the default implementation pattern of server-side Google Tag Manager, is straightforward to setup with the automatic provisioning steps, it’s certainly not the only way to deploy the server.

• You can set it up in Amazon AWS (this blog)
• You can set it up in Microsoft Azure (this blog)
• You can set it up with Cloud Run (Mark Edmondson’s blog)

In fact, the manual setup guide gives you the details on how to deploy a Google Tag Manager Server in any environment that runs Docker.

While Google App Engine, the default implementation pattern of server-side Google Tag Manager, is straightforward to setup with the automatic provisioning steps, it’s certainly not the only way to deploy the server.

• You can set it up in Amazon AWS (this blog)
• You can set it up in Microsoft Azure (this blog)
• You can set it up with Cloud Run (Mark Edmondson’s blog)

In fact, the manual setup guide gives you the details on how to deploy a Google Tag Manager Server in any environment that runs Docker.

One of the key skills for anyone working with web analytics and tag management is understanding how to identify where things went wrong, why they went wrong, and ideally how to fix them.

There are plenty of excellent browser extensions for helping you debug, and we’ll discuss these in the guide, too. But most of all we’re going to use browsers’ own developer tools, as they are always the best source of truth for anything that happens within the browser window.

Although most of Server-side Tagging in Google Tag Manager revolves, quite rightfully, around Clients, there’s still plenty of value to be derived from tags, too.

Naturally, the most common use case for server-side tags is to map the incoming requests to the Server container (filtered through Clients) and dispatch them to their respective endpoints.

But in addition to dispatching HTTP requests, tags can do so much more.

In this article, I’ll share with you a neat way how to utilize tags to manipulate the HTTP responses the Server container sends back to the request source.

To continue my extensive collection of Google Tag Manager’s server-side tagging articles, in this guide I’ll walk you through how to set up a Server container in Microsoft Azure’s App Service platform.

For my previous guides on manually provisioning a Server container, follow these links:

• Amazon AWS (Elastic Beanstalk): Deploy Server-side Google Tag Manager In AWS
• Google Cloud (App Engine): Provision Server-side Tagging Application Manually

Azure’s App Service is similar to AWS Elastic Beanstalk and GCP App Engine, in that it lets you create a web application from scratch with minimal effort.

Setting up cross-domain tracking in Google Analytics 4 has been well-documented.

The main departure from Universal Analytics is how cross-domain measurement is something you configure through the Google Analytics user interface rather than through implementation and JavaScript.

While this approach is obviously beneficial especially for those who lack the know-how or the resources to configure the JavaScript trackers, it does lead to problems, too.

In this article, I want to tackle these edge cases. They are:

For many, it seems, one of the most important justifications for server-side Google Tag Manager is its resilience to ad and content blockers. After all, by virtue of serving the container JavaScript from your own domain, you escape many of the heuristic devices today’s blocker technologies employ.

Well, I’ve gone on record over and over again to say how this is poor justification for using server-side GTM. By circumventing the user’s wish to block scripts, you are disrespecting them and forcing their browser to download scripts that they wanted to avoid downloading in the first place.

Google has released the Google Ads Remarketing tag for server-side tagging in Google Tag Manager.

Functionally, it’s remarkably similar to the Conversion Tracking tag they released previously. In fact, you should go ahead and read that article first, so that you have an understanding of how Google Ads tracking works through Server containers!

Follow this link to read the official documentation.

In this article, I’ll walk you through how to set things up, and I’ll also provide an overview of how it works.

The FPID cookie in server-side tagging for Google Tag Manager is an HttpOnly, server-managed ID cookie that’s designed to replace the JavaScript-managed _ga cookie used by Google Analytics 4 and Universal Analytics.

For more details about the cookie itself, check out my previous article on FPID.

In that article, I mentioned one caveat for adopting FPID being the fact that cross-domain tracking will not work.

I mean, how could it? FPID is an HttpOnly cookie, which means it’s not available to JavaScript in the browser. Cross-domain tracking, on the other hand, decorates links dynamically as users click them, which means it needs the cookie to be available via JavaScript so that it could be decorated into the target page URL.

One of the biggest blockers for Google Tag Manager’s server-side tagging to slip out of beta is Google Ads. Until server-side tagging supports a solution for both conversions and remarketing capabilities to be reproduced server-side, it’s unlikely that Server containers will lose their beta label.

While I can’t say what will happen to the beta label now, the fact is that Google Tag Manager has now released support for Conversion tracking using server-side tagging.

Since Google Tag Manager released the manual setup guide for server-side tagging, my mind has been spinning with the idea of walking through the deployment into Amazon’s AWS.

I personally prefer Google Cloud Platform over AWS, because I think it’s so much more user-friendly. Even though in this guide we’ll be utilizing one of the simplest AWS services, Elastic Beanstalk, the deployment is still much more complex than if you were to use GCP’s App Engine.