Google Analytics tips & tricks
Roughly a 4 minute read by Admin
With the recent official release of Universal Analytics, we at Engage have decided to do a little housekeeping on our Google Analytics accounts. Here are some tips we've discovered on the way!
Accounts, profiles and views
There's been a lot of debate in the past about how to set up analytics for each site: do you go with an account per site/client; one global account with each profile a separate client; or a mixture?
We've gone for one account per client, and each of their sites is a profile under that account. Here's why:
- We'll never hit the 50 profiles per account limit
- It keeps everything neat and organised. You'll never have to think "Where did I put that profile?!"
- You can assign permissions straight from the account level, instead of having to rely on profile/view specific permissions
- There's less crossover: filters will only be available for that client (which can be both good and bad), and the client's Google Analytics users will only be seen in their own account
Each of the client's domains gets its own profile, and within the profile we have at least two views: Global, and Global - Restricted.
- Global is completley unfiltered, which we use to test our implementation, and any custom tracking.
- Global - Restricted filters out the client's and our IP addresses, and is the default view we use when giving out any for of stats.
The only time we really diverge from this system, is when we host multiple 'sites' from the same domain. This usually happens with Facebook apps, or microsites, where the 'site' is served from a different subdirectory.
In these cases, we set up two new views: Site and Site - Restricted. Notice the pattern? The only difference with these views, is we've added a new URL filter to only show traffic to that 'site'. We'll add as many as needed for each 'site' the domain hosts.
Namespace your accounts
You'll more than likely come to a time when you need to implement Google Analytics for two or more accounts on your site. Simple! You just need to namespace your trackers:
ga('create', 'UA-XXXXX-Z', {
'name' : 'engageTracker'
});
ga('create', 'UA-YYYYY-Z', {
'name' : 'clientTracker'
});
Don't forget to use the new names when tracking!
ga('engageTracker.send', 'pageview');
ga('clientTracker.send', 'pageview');
Tracking when developing locally
When you're developing locally (and you all are, right?), you might find your tracking data is never received, and you won't be able to test your Google Analytics implementation.
Getting it to work is very easy: simply set your cookieDomain to 'none'.
ga('create', 'UA-YYYYY-Z', {
'name' : 'engageTracker',
'cookieDomain' : 'none'
});
You can event take this one step further, and make it host aware:
ga('create', 'UA-YYYYY-Z', {
'name' : 'engageTracker',
'cookieDomain' : ((window.location.hostname.match(/localhost/i)) ? 'none' : 'sitename.co.uk')
});
Just replace 'localhost' with whatever your local url is, and you're good to go!
Tracking synchronously with hitCallback
There have been a few times where we've needed to track an event just before a JavaScript page redirect. Something like this:
var someFunction = function(){
ga('send', 'event', 'Category', 'Action', 'Label');
window.location.href = '/new/page';
}
Of course, this rarely works, as before the even has had chance to be tracked, we've redirect the page and cancelled the asynchronous call. The only way to get around this was to wrap the redirect in a setTimeout call. Not the most elegant of solutions, and still unreliable.
With Universal Analytics, Google have given us hitCallback, which is exactly as it sounds: a callback. Now, our tracking code can look like this:
var someFunction = function(){
ga('send', 'event', {
'eventCategory' : 'Category',
'eventAction' : 'Action',
'eventLabel' : 'Label',
'hitCallback' : function() {
window.location.href = '/new/page';
}
});
}
The page won't be redirected until the event has been tracked. Perfect!
Wrap up
So there we have it, a few simple and easy to implement tricks for Google Analytics.
Of course, we could go into it a lot further; we haven't touched on abstracting the onclick events, for instance, or using virtual pageviews and events to get more accurate bounce rates. However, keep your eyes peeled, as we may do a follow up post!
Can you improve on any of the points above, or know any tips/tricks we've missed? Let us know in the comments section below!