Posts

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.

With the advent of Enhanced Ecommerce for Universal Analytics, a new scope was introduced for Custom Dimensions and Metrics. Product scope can be used to send information about each product that is sent through Enhanced Ecommerce, but it’s not exactly the most logical or intuitive thing to wrap your head around.

In this #GTMTips post, we’ll take a look at how to implement Product-Scoped Custom definitions via Google Tag Manager, and I’ll quickly explain how they work in relation to queries and reports you might want to build on top of them.

To prevent a Tag from firing in Google Tag Manager, you can:

1. Delete the Tag

2. Remove all Triggers from the Tag

3. Add an Exception Trigger to the Tag

The third option is usually the best if the blocking is just temporary. Exceptions are what used to be called blocking rules in the first version of GTM. To add them is easy enough. In the Fire On step of Tag creation, you can click Create Exceptions, and choose the Trigger that will block this Tag from firing.

The inimitable Craig Sullivan gave me an idea for a continuation to my latest post on form abandonment tracking. In this short tutorial, I’ll show you how to track the time users spend on your form fields. We’re going to use the User Timings hit type, and we’ll send the data for just one form. With small modifications, you can expand the script to cover multiple forms on a page.

This simple solution tracks the time the user spends on each form field by measuring the distance between the focus event and the blur or change event. The first one occurs when a form field is entered, and the latter depends on if a value changed (change) or no change was registered (blur).

Form abandonment isn’t always easy to define. Most often, it refers to when someone starts to fill in an HTML form, but leaves the page without submitting it. As a definition, this works nicely. However, with multi-page forms it naturally refers only to the last page of the form. Also, especially with government institutions, forms can be saved to be submitted later. Here, again, form abandonment must be reconsidered.

In this article, I’ll go over four different ways to track form abandonment in Google Analytics, using Google Tag Manager to setup the tracking. The definition I’ll use is the first one: abandonment occurs when someone enters a form page, but leaves it without submitting the form. Do note that GA might not be the right tool to actually track issues with your form. There are dedicated resources for that, such as ClickTale or Hotjar. But if you want to measure form engagement as part of a more coherent visitor journey, then it might make sense to track this engagement (or lack thereof) in Google Analytics.