Last weekend, I wrote a very simple web app that automatically creates a number of referral spam filters to tackle the problem that seems to have everybody all riled up. For a nice recap of the situation, take a look at this post by Jeff Sauer, or this article by Mike Sullivan. This isn’t an opinion piece, even though I’ve got a great number of opinions about this issue.
There are many tools and methods to make Google Analytics more manageable. Google Tag Manager is probably the best known of these, and you can find many, many articles about GTM on these pages as well. However, today I want to tell you about one of the features of Universal Analytics that hasn’t, as far as I know, received too much attention. It’s funny, because at the same time almost everyone uses the feature in the shape of eCommerce, enhanced link attribution, and cross-domain tracking.
Here’s a very quick tip this time, but one that’s caused a lot of headache for many Google Tag Manager users. Tip 21: Use the All Pages Trigger correctly Let’s face it, All Pages isn’t really an intuitive Trigger name. Many seem to interpret it as: enable the Tag to fire on all pages, but use the other Trigger (e.g. Link Click) to actually fire it. As it turns out, the All Pages Trigger will fire the Tag on all pages.
A year ago, I wrote a Year In Review post for one of the craziest 365 days of my life, both personally (got married), and professionally (started at NetBooster, and toured the world talking about Google Analytics and Google Tag Manager). Now it’s time for another recap, and the chance to announce a big change in the Simoverse. No, I will not be joining Google (made you think so!
If you read my previous post on fetching the Client ID from the Universal Analytics tracker object with Google Tag Manager, you might have agreed with me that it sucks you can’t access the tracker object interface in real time using Google Tag Manager. This is because all of the set commands you add to a Universal Analytics tag template take place before the analytics.js is loaded and the tracker object is properly created.
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:
On March 30th, right on (the latest) schedule, the Migration Assistant tool was published for Google Tag Manager V2. This tool lets you opt-in to account migration for your legacy Google Tag Manager Accounts. Migration means simply that the accounts will be converted to V2 accounts, and you will have access to all the new features the upgrade provides. In this #GTMtips post, we’ll go over the migration steps (it’s pretty simple), and I’ll leave you with a couple of tips on how to get started with the new features.