Universal Analytics can collect Page Timing data from users that load your pages. This data is populated in to the Behavior -> Site Speed -> Page Timings report, and it’s a very useful feature for optimizing your website.
However, there’s a murky underside to this generous feature. The way Page Timings collection works is that when Pageview hits are sent from the site, a sample of these (1% by default) are automatically followed by a timing hit which includes page performance data grabbed from the Navigation Timing API.
Here we are again, revisiting an old theme. When using Google Tag Manager, we often want to send the contents of the same tag to multiple Universal Analytics properties. With on-page GA, this used to be quite simple, as all you had to do was create a new tracker and then just remember to run the ga('trackerName.send'...) commands to all the trackers (or you could use my duplicator plugin). With GTM, your options are more limited, since Google Tag Manager abstracts the tracker object, giving you far fewer tools to work with.
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).
Let’s face it - most of us use Google Tag Manager for one main purpose: to deploy and configure Google Analytics tracking on a website. I’d wager that once you start using GTM, you won’t be implementing Universal Analytics the old-fashioned way, with on-page code, any more. But running Universal Analytics tags through GTM isn’t yet a perfect workflow. We’re still missing things like proper plugin support and the option to properly differentiate between the tracker and the hit - both of which are easy to do with an on-page implementation.
Google Analytics’ Site Speed reports are pretty darn great. They report automatically on various milestones in the process the browser undertakes when rendering content. These reports leverage the Navigation Timing API of the web browser, and they are (typically) collected on the first Page View hit of a page.
And this is all fine. As I said, it’s a great feature of Google Analytics, and lends itself handily to spotting issues in the quite complex client-server negotiation that goes on when your web browser requests content from the web server.
This is a guest post by Stephen Harris from Seer Interactive . He was kind enough to share his awesome solution in this blog, so I’m very grateful indeed for his contribution.
If Google Tag Manager is loaded as the primary instrument for tracking on a webpage (as it should be), then all webpage tracking could and should be configurable via GTM. But we don’t always control the circumstances, and it’s not uncommon to face hardcoded Google Analytics tracking outside of GTM.
First of all, I’m sorry about the title. I should really stop throwing the word “simple” around, since people always tell me that the stuff I claim to be easy and straightforward is rarely so. But since this is my blog, I reserve the right to use whatever stupid and misleading terminology I want. I maintain that what follows IS quite simple, especially when considering the amount of complexity it reduces in your Universal Analytics setup.