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.
When Google released gtag.js, the new, global tracking library designed to (eventually) replace analytics.js, many Universal Analytics practitioners and users were confused (see e.g. Jeff’s great overview here). It seemed like gtag.js wasn’t really solving any immediate problem, since analytics.js had done a bang-up job with Universal Analytics tracking for all these years. However, gtag’s modus operandi is the ability to leverage the same semantic information (distributed across dataLayer!) across a number of Google products, starting with GA and AdWords.
One of the things I’ve recommended from the get-go is to always send the Client ID to Google Analytics with your users’ hits. This is very useful for adding a level of granularity to your tracking. At first, I recommended using an Event tag to do this. Then I modified my approach a little so that you could send it with your initial Page View (thus not inflating your hit counts).
This article is a collaboration between Simo and Dan Wilkerson. Dan’s one of the smartest analytics developers out there, and he’s already contributed a great #GTMTips guest post. It’s great to have him back here sharing his insight on working with Accelerated Mobile Pages (AMP). So, we’re back on AMP! Simo wrote a long, sprawling AMP for Google Tag Manager guide a while ago, and Dan has also contributed to the space with his guide for AMP and Google Analytics.
Since writing my rant about the schema conspiracy of web analytics platforms, I’ve been giving the whole idea of hit-level data collection a lot of thought. Sessionization is very heavily implemented in Google Analytics, which is understandable, but the regular Google Analytics API just doesn’t give you the kind of information you’d need, if you wanted to stitch hits together differently in your own backend. In fact, there are four distinct levels of aggregation that are not exposed via the API, even though I think they should: