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.
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.
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.