Simo Ahava's blog

There might be many reasons you’d want to fire a single Tag multiple times in Google Tag Manager. The most common one is when you want to deploy multiples of a single tracking point on the web. Perhaps you have a roll-up account you want to send the hits to, in addition to the site-specific tracking property.

Quite a while ago, I gave a solution for this with a specific focus on Google Analytics Tags. It leveraged the hitCallback feature of the Universal Analytics library by increasing a global counter each time a Tag had fired. This solution had a number of drawbacks: being GA-specific, polluting the global namespace, and requiring a unique setup for every single Tag you wanted to fire.

There might be many reasons you’d want to fire a single Tag multiple times in Google Tag Manager. The most common one is when you want to deploy multiples of a single tracking point on the web. Perhaps you have a roll-up account you want to send the hits to, in addition to the site-specific tracking property.

Quite a while ago, I gave a solution for this with a specific focus on Google Analytics Tags. It leveraged the hitCallback feature of the Universal Analytics library by increasing a global counter each time a Tag had fired. This solution had a number of drawbacks: being GA-specific, polluting the global namespace, and requiring a unique setup for every single Tag you wanted to fire.

A while ago I wrote a blog post about how to install Google Tag Manager for iOS using the Swift programming language (you can read the article here). I’ve been doing a lot of work with Swift lately, and I’m more and more convinced that GTM is actually a very powerful utility for running in your iOS app instead of the Google Analytics SDK.

Why? Because it abstracts a lot of the nitty-gritty you’d otherwise need to explicitly manage in your GA installation. Also, by using the TAGDataLayer interface, you’re abstracting stuff yourself, not forced to adopt any specific syntax or semantic structure in your tracking. Instead, you’ll be leveraging generic key-value pairs and an object structure, which you’re probably already familiar with if you’ve worked with GTM for the web.

You might have noticed that the Referral Exclusion List in Google Analytics is difficult to maintain. You can’t copy a list from one property to another, the list is a wildcard match for domain names (so all subdomains are automatically excluded), and it’s just about the clunkiest user interface we’ve seen since ERP tools from the 1990s. A while ago, I wrote of a solution which lets you manage referral exclusions using Google Tag Manager, and it’s still a neat trick, as it’s way more flexible than said clunky UI.

Google Tag Manager, our favorite free tag management solution, has always struggled with its enterprise-worthiness. There are many features still lacking, most of which have to do with working in multi-user environments. Now, grab the last word of that sentence (see what I did there), and hug it tightly, for GTM just introduced a new, enterprise-friendly feature: Environments.

These Environments are actually browser cookies, which you use to link a Google Tag Manager container state with the browser of the user who needs to or wants to view that particular state. In other words, if you have a QA (quality assurance) process, as you should have, or if you do most of your testing on a staging server, as you should do, you can create an Environment in GTM, after which you can publish container versions (even the draft) into that particular Environment alone.

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.

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.