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.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
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. In the built-in Universal Analytics Client template in a Server container, there’s an option to migrate to a Server Managed Client ID.
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.