Google Tag Manager

NOTE! This solution has been upgraded, and the new approach can be found here.

If you’re unfamiliar with the lingo, cross-domain tracking is a hack used by Google Analytics to circumvent the web browser’s same-origin policy. Essentially, the policy dictates that browser cookies can only be shared with a parent domain and all its sub-domains. In other words, domainA.com and domainB.com do not share cookies.

Since Google Analytics calculates sessions and users by using a cookie, this is problematic. If the user navigates from domainA.com to domainB.com, they will, by default, browse domainB.com in a different session (often a different user as well) from that on domainA.com.

I’ve been meaning to write about Google Tag Manager for mobile apps for such a long time. Finally, I have some great use cases to share, as well as some useful examples for implementing GTM for iOS. That’s right, this is an iOS guide, and, to be more specific, geared towards a successful Swift implementation.

If you didn’t know, Swift is a relatively new programming language, developed by Apple for iOS and OS X programming. It’s got some nice synergies with existing Objective-C implementations, which means you can either gradually migrate to Swift, or just start writing new apps with it instantly.

So, looks like iOS 9 has built-in support for integrating “content blocking” extensions on your iPhone. Now, blocking ads and other intrusive content is nothing new, nor do I want to get into a debate about whether it’s a good thing or not. But as a data geek I’m very interested in knowing just what share of my site tracking has some content blocker enabled. In this post, I’ll show two tricks (easy and advanced) to expose these content blockers. It’s always a good idea to keep tabs on the numbers, especially if you’re concerned about them blocking your analytics tools as well (as you should be!).

Here’s an interesting and hacky use case for you. It’s all about uncovering bounce metrics for visits which originate from organic Google search results. In particular, the metric we’re interested in is how long user dwelled on the landing page after arriving from organic Google search AND returned to the search engine results page (SERP) using the browser’s back button.

The inspiration for this post came from an audience question at the Best Internet Conference in Lithuania, which I recently attended as a speaker. They were concerned that Google is using Bounce Rate as a search ranking signal, and I was fairly strongly opinionated that it’s simply not possible, as all the “native” GA metrics are really easy to manipulate. However, Dr. Pete from Moz wrote about dwell time in 2012, and it makes a lot of sense. Google should be very interested how long the visitor stays out of the SERP when following a link. If users tend to immediately return to the SERP, it’s very likely the result was not relevant for them.

Every now and then we want to create a bridge between the stateful machines we send data to (e.g. Google Analytics), and the stateless environment where we collect the data itself (e.g. Google Tag Manager). This is not easy. There is no synergy between Google Analytics and Google Tag Manager which would let the latter understand anything about things like sessions or landing pages or Bounce Rates.

One thing we can reliably measure, however, is whether or not the visitor is a New User in Google Analytics. This is done by checking whether or not the Universal Analytics cookie _ga exists in the user’s browser when they enter the site. Naturally, this check needs to happen before the Universal Analytics Tag has time to create the cookie, which is the only difficult thing to solve here.

Enhanced Ecommerce is undoubtedly an excellent feature of Google Analytics. It provides us with a set of reports that truly extend the capabilities of funnel-based website analysis. As I’ve shown before, it’s also very useful for tracking other transactional events on your site, such as content engagement.

However, here’s the thing. It’s not very easy to implement. Even if you get everything right according to the documentation, there are still quite a number of pitfalls, and many of the learnings emerge only through experience. This is where I want to help out, so I composed this post with some of my key findings about Enhanced Ecommerce implementation and use.

Unfortunately, iFrames still exist. They are used to embed content from one page into another. Frames are horrible, nasty things, very often riddled with cross-domain problems, performance issues, responsive design obstructions and other crap from the nether pits of hell. Regardless, if you’re stuck with an iFrame which also collects data to your Google Analytics property, for example, you probably want to prevent at least the first Page View from firing, since otherwise you’ll be double-counting Page Views: once on the main page and once in the iFrame. In this tip, I’ll show you how to prevent a Tag from firing if it’s executed in a document that is in an iFrame.

(Updated 13 August 2017)

A little over a year ago, in April 2014, I wrote the post “Advanced Form Tracking In Google Tag Manager”, and it’s been at the top of my best seller list ever since. Turns out that many people are rightfully passionate about making the web forms on their websites as fluid and intuitive as possible, since a web form is often the only thing that stands between a prospect and their transformation into clienthood.

A recent update to Google Tag Manager introduced a feature which has been on the wishlist of many users for a long time. It’s called Tag sequencing, and its purpose is to facilitate the sequential firing of Tags. The idea is that you can specify a setup and a cleanup for each Tag in your container.

This article is intended to function as a quick tour of the feature. It’s not the simplest feature to understand, as Tag sequencing runs parallel but separate from the normal flow of your container. Don’t worry, I’ll get back to this soon.

The web is stateless. It’s basically blind to your past, and it does a poor job of predicting what you might do in the future. When you browse to a website, the browser requests the page from the web server, and then proceeds to render it for you. This is a detached, clinical process, and any personalized or stateful data transfer is left to the sophistication of your web server.