Single-page sites (or single-page apps) typically have just one page load. When navigating the site, subsequent content is either uncovered from the DOM, where it’s been in a hidden state, or loaded from the server using HTTP requests that do not invoke a new page refresh. This behavior, however, has some implications for Google Analytics tracking, especially when configured via Google Tag Manager.
The crux of the problem is this: When you create a Google Analytics tracker, the URL of the page (without a possible #hash) from when the tracker was created is sent as the value of the Document Location field with every hit that uses this tracker.
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.
What better way to celebrate the 50th #GTMTips article than, well, a really useful Google Tag Manager tip?! This tip is so useful and simple; it encapsulates everything that I had in mind when starting this series. The tip is about restricting scope of Custom HTML Tags. This is an important concept, because it’s possible that you’re stuffing your page’s global JavaScript namespace with all sorts of junk, and thus inadvertently causing conflicts.
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.
Google Tag Manager can be quite the hierarchical mess. You have accounts which comprise containers. Containers are split into container versions, and you use workspaces to create new versions. Phew! Trying to keep tabs on all the activity within these layers can be quite the chore.
In this #GTMTips article, I’ll do a quick walkthrough of (almost) all the places where you can review changes made in your Google Tag Manager account and container.
I’ve already written extensively about JavaScript in web analytics implementation. Suffice to say, understanding at least the basics is absolutely necessary to survive in the technical medium of the web browser.
This article expands on a conference talk I gave at MeasureCamp IX, London a short while ago. I’ve always been quite single-minded about the importance of JavaScript in web analytics development, and it was a pleasure for me to get some of that off my chest.
It’s been a crazy week. Just crazy. Not only did Google Tag Manager introduce Workspaces, arguably one of its most important releases ever for GTM, but they also revamped the user interface! So very big changes have been underfoot, and I’m so happy to be writing about them, because in my completely biased opinion these changes are amazing and well worth the long wait.
In this article, I want to quickly walk you through what I think are the most meaningful changes in the interface.