Menu

As simple as possible, as complex as necessary

The bad UX of Google Analytics cross-domain link handlers

29 October 2012

As a lover of simplicity, I can't say that Google Analytics (GA) is one of my favourite pieces of software. Given the complexity of what it aims to provide, though, it's impressively designed and—being also free—website owners love it.

One of the more complex scenarios it will accommodate is where your site is made up of more than one separate domain. Perhaps your blog is on a third-party domain such as wordpress.com or blogspot.com, but you want to track activity there and on your main website at yourdomain.com in a single GA profile. So if someone visits your blog and then follows a link to your main website, you want to be able to treat that as a single session in GA.

Normally this isn't possible, since the cookies GA uses to identify visitors and sessions can only be read by the domain which set them. So the blog cookies can't be read by the website since it's on a different domain, and vice versa.

But GA provides a solution for cross-domain tracking in the form of a Javascript event handler which can be attached to the links, and which will append the cookie data to the URL as parameters and execute the link when clicked.

<a href="http://yourdomain.com"
 onclick="_gaq.push(['_link', this.href]); return false;">
 link from blog to website</a>

Rather than manually code these "onclick" handlers, it will often make sense to use jQuery to detect any links pointing to the "other" domain and attach them automatically.

$( document ).ready( function(){
 $( "a[ href*='yourdomain.com' ]" ).click( function(){
  _gaq.push(['_link', this.href]);
  return false;
 });
});

As long as you've configured your main GA script to allow this type of linkage, when a visitor arrives on the website having clicked through from the blog, GA will be able to continue tracking the same session despite the change of domain.

Link Sin

A practical solution, but one with an undesirable side-effect.

Should you wish to open the link in a new browser window or tab, by holding down the Shift, Ctrl (Windows) or Command (Mac) key as you click, you will not be able to. The attached GA function "hijacks" the click event and will send you off to the website in the same window/tab regardless of any modifier keys you may be pressing.

I've posted before on the dangers of removing control by forcing links to open in new windows (using the target attribute for instance). Here the effect is reversed but is no less of a sin: the user is prevented from controlling how they want to browse.

The part of the script that halts the normal behaviour of the link is return false;. Perhaps if we remove this all will be well.

$( document ).ready( function(){
 $( "a[ href*='yourdomain.com' ]" ).click( function(){
  _gaq.push(['_link', this.href]);
  //return false;
 });
});

Holding down the Ctrl-key as I click does now open up the link in a new tab. Great... except that it's also opened the new URL in the original tab. Not what I want. Not only that, but the GA parameters have not been added to either URL. Not what the site owner wants.

What we need is a way of adding the parameters, while not interfering with the normal click event behaviour.

How to track cross domain links without taking away control

Fortunately this can be done quite easily using a different GA method to the one advertised by Google, namely getLinkerUrl().

$( document ).ready( function(){
 $( "a[ href*='yourdomain.com' ]" ).click( function(){
  var pageTracker = _gat._getTrackerByName();
  this.href = pageTracker._getLinkerUrl( this.href );
 });
});

The method simply appends the cookie data to the URL you pass in, without executing it. This means you can just replace the href with the value it returns and let the link continue behaving as normal.

Slightly shocking

Clearly cross-domain tracking isn't the norm, and I'm sure most web users are blissfully unaware of modifier keys and what they can do. Perhaps I didn't spend long enough searching, but given the ubiquity of GA, I'm nonetheless surprised at how little mention there seems to be of this as a UX problem.

There are a handful of related questions on StackOverflow, but these are generally from developers frustrated at being unable to force links into new tabs/windows (something they probably should not be doing), rather than concerned at the potential frustration of their users.

Comments

  • Formatting comments: See this list of formatting tags you can use in your comments.
  • Want to paste code? Enclose within <pre><code> tags for syntax higlighting and better formatting and if possible use script. If your code includes "self-closing" tags, such as <cfargument>, you must add an explicit closing tag, otherwise it is likely to be mangled by the Disqus parser.
Back to the top