Simo Ahava's blog

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. These headers include geolocation headers, based on the IP address of the machine that sent the hits.

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. These headers include geolocation headers, based on the IP address of the machine that sent the hits.

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.

Last updated 27 April 2023 with details about preventing FPID access in cookieless scenarios.

With Server-side tagging, the developer community has a chance to vastly improve the data collection capabilities of Google’s analytics platforms (Universal Analytics and App+Web). The ability to build our own templates is particularly potent with a Server container.

However, it’s not as if Google themselves are just sitting idly by and seeing what the community can come up with.

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…

When you use Google Analytics on the web, you are most likely implementing one of analytics.js, the global site tag (gtag.js), or Universal Analytics tags via Google Tag Manager.

These libraries all end up doing the same thing: compiling a payload-rich HTTP request to an endpoint at https://www.google-analytics.com.

What if you want to have the JavaScript libraries do their job, but instead of sending the data to Google’s servers, you send them to a new, custom endpoint?

Ever since Server-side tagging was publicly announced at SUPERWEEK 2020, Google and the trusted tester community have been hard at work, building something that just might change the landscape of digital analytics for good.

Google Tag Manager has now released Server-side tagging into public beta. In this lengthy article, we’ll take a look at what Server-side tagging is, how it should (and should not) be used, and what its implications are on the broader digital analytics community.

In this step-by-step guide, I’ll show you how to build a Lookup Table generator in Google Sheets, utilizing Apps Script and the Google Tag Manager API.

The purpose of the Lookup Table generator is to automate the often tedious task of adding many, many rows to a Lookup Table within the Google Tag Manager UI. There are other solutions for this, but none (as far as I know) that uses the Google Tag Manager API.

With the rise of ad and content blockers (think Ghostery and uBlock Origin), as well as browser tracking protections (see www.cookiestatus.com), marketing technology vendors have their work cut out for them. And when I refer to “their work”, I mean they have to proactively identify and exploit any loopholes they can find to keep on collecting their precious data.

In this article, I’ll take a look at one such exploit vector, the Canonical Name (CNAME) DNS record, in particular.

Since updating to Google Chrome 83, you might have noticed that Google Tag Manager’s Preview mode no longer works when browsing Chrome in Incognito mode.

This is because starting with Chrome 83, third-party cookies are blocked by default in Incognito windows.

Google Tag Manager uses third-party cookies to serve browsers in Preview mode with the container draft rather than the live container.

There’s a simple workaround to make sure Preview mode continues working for any site you want to browse in Preview mode.

Let me start by proclaiming with clarity and sincerity:

No, Safari 14 (or any other version of Safari) will not block Google Analytics from loading and running on a website.

In the midst of Apple’s yearly Worldwide Developers Conference, the company showcased some of the privacy improvements to the upcoming version of the Safari web browser (version 14).

In fact, the biggest revelation was the new Privacy Report, which is designed to elucidate how much the browser is working towards mitigating the damage caused by cross-site trackers.