gtmtips

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. Read More…

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. Read More…

With server-side tagging, you can send any types of HTTP requests to the Server container. The Server container parses these, fires up container instances, and sends the data onwards to first-party data stores and third-party vendors alike. Often these requests contain URL strings encoded in query parameters. A prime example is the document location parameter in Universal Analytics requests. Server-side Clients would parse these URL strings and convert them into the format required by the event data object. Read More…

One of the biggest perks of working with server-side tagging is that you can establish a first-party context between the site sending the data and the server-side tagging endpoint itself. This leads to many benefits, including improved control of the data streams, the possibility to set cookies that extend beyond ITP’s restrictions, and reduced stress on an already very likely overloaded Content Security Policy. In this article, I’ll show you how to map multiple custom domains to your Google Cloud Project application. Read More…

There’s a new custom variable template in town! The Data Layer Picker template lets you create variables that have a singular, exceptional (in Google Tag Manager’s context, at least) purpose: You can access the keys and values that were in the object pushed into dataLayer itself. And … that’s it! Read on to understand why this might be useful. Tip 123: Direct access to the dataLayer.push() If you know your Data Layer Variable, you’ll know that it comes in two versions. Read More…

One of the big omissions, at least for now, in Google Analytics 4 is the customTask. It is unfortunate, but no such mechanism exists in the client-side SDKs. This means that you won’t be able to do all the magical things that customTask enables in Universal Analytics. One of the biggest headaches is how to collect extremely useful fields such as the Client ID, as these are not available by default in the Google Analytics 4 reporting interface. Read More…

A recent update to Google Tag Manager introduced container notifications. By subscribing to container notifications, your Google Tag Manager login email address can be configured to receive an email for some of the key workflows in Google Tag Manager: containers getting published, and containers being submitted for approval (Tag Manager 360 only), for example. Be sure to check out the official help center article about container notifications. In this article, I’ll walk you through the feature and share a couple of tips on how to make it even more useful! Read More…

When you create a Server container in Google Tag Manager, GTM creates an App Engine deployment in the Google Cloud Platform for you. App Engine is a managed serverless platform, which basically means it’s a (set of) virtual machine(s) running in the cloud, with some extra bells and whistles added to make managing it easier. A potentially useful thing that App Engine does is decorate all incoming HTTP requests with some HTTP headers that can be used in the app. Read More…

Since the release of Server-side tagging in Google Tag Manager, I’ve jumped at every opportunity to celebrate the tools it provides for improving end-user privacy and data security. One of the biggest benefits is obfuscation-by-default. Since all hits are passed through the server-side proxy, the default view for any third-party tool (such as Google Analytics) is that of the server in the Google Cloud rather than the browser and device with which the user was browsing the site. Read More…

You can utilize Server-side tagging in Google Tag Manager to build your own custom Universal Analytics proxy. This proxy comes in the shape of a new Client custom template, which takes the incoming /collect requests and sends them to Google Analytics. While doing so, it also returns the _ga cookie in a Set-Cookie header, thus preventing Safari’s Intelligent Tracking Prevention from capping its expiration to just 7 days. You might also be interested in reading what Google’s own solution is for migrating from JavaScript cookies to those set in HTTP headers. Read More…