Analytics

This year I had the opportunity to present at eMetrics London and Berlin on a topic that is very close to my heart. I’m psychotically neurotic about data quality. I’ve written about it many times before, and it’s pretty much why I want to keep on blogging and writing about analytics and tag management customizations. At eMetrics, I stepped out of my comfort zone of development and implementation, and chose to talk about organization practices.

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.

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.

(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.

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).