Migrating to the “new” asynchronous Google Analytics tracking code should just be a matter of replacing the old code by the new one, shouldn’t it? So why are there still so many websites that use that old, worse-performing code from 2009? Because migrating is more than just replacing the basic snippet: For example, the new tracking code requires you to also update your Virtual Pageview and Event Tracking calls. To mitigate future migration migrains when Google changes its tracking code the next time, you should write your own Google Analytics functions.
Google released the “new” asynchronous tracking code in December of 2009. As the Lunametrics blog explains wonderfully, that code
- makes your page load faster
- tracks more of your traffic
- no longer poses a problem when Google’s servers are not responding right away (earlier, that would halt the loading of your page)
Those are only a few of the many benefits of that new code.
But, December of 2009, that’s over two years past now. So why haven’t we all migrated yet? Maybe other websites faced a similar challenge to the one we had.
When tons of Event Tracking and Virtual Pageview calls have to be replaced
For our company, the biggest problem when migrating wasn’t removing the old basic snippet at the bottom of the page and inserting the new basic snippet in the <head> section. That was nothing. Our problem were the hundreds of inline Event Tracking and Virtual Pageview calls. For example, whenever we wanted to track clicks on specific links as Events, we followed Google’s advice and inserted the well-known “onclick” inline method that called our good old friend Mr. PageTracker and told him to track an Event:
<a onclick="pageTracker._trackEvent('Category', 'Action',
'Label', Optional_Integer_Value);">click me</a>
Now, if you migrate to the new tracking code and leave Event Tracking calls like these the way they are, you’ll get an “Uncaught ReferenceError: pageTracker is not defined” in your JavaScript Debugging Console: Your events are no longer being tracked. (Luckily, we found that out before migrating.)
The migration migrain
What made migrating an even heavier migrain was that we had a dozen different systems and technologies (a general website CMS, a blog CMS, a large community platform, several event application and registration tools, a survey tool, a flash quiz application, a job board, a wiki, some facebook fan pages etc.). Some of them were legacy systems our IT didn’t really want to touch anymore. And even in the case where we had the possibility to just do “search and replace” in the code, that wasn’t that easy because the old
pageTracker._trackEvent('Category', 'Action', 'Label', Optional_Integer_Value);
would have to become
_gaq.push(['_trackEvent', 'Category', 'Action', 'Label', Optional_Integer_Value]);
That’s why we couldn’t just replace “pageTracker._trackEvent” by “_gaq.push”, we also had to find some way to add those square brackets at the right places in the end and slide in that fourth parameter (_trackEvent). It turned out that this was harder than I had thought (at least that’s what our IT said).
The solution: We wrote our own Google Analytics functions
So what did we do in the end? We wrote our own Google Analytics functions in the form of a JavaScript object called something like “MyWebTracker”. It is included on every page with all the other standard JavaScript files. To give you an example, here is an excerpt of the object with its Event Tracking method. This method doesn’t do much else but calling Google Analytics’ new native _gaq.push function:
var MyWebtracker =
{
event: function(category, action, label, event_value)
{
if (event_value === undefined)
{
_gaq.push(['_trackEvent', category, action, label]);
}
else
{
_gaq.push(['_trackEvent', category, action, label, event_value]);
}
}
}};
When our editors or programmers now want to use an Event Tracking Call or a Virtual Pageview, they now have to call our own method – or “function”, if you will:
MyWebtracker.event('Category', 'Action', 'Label', Optional_Integer_Value);
Since this own method doesn’t need any parameters in square brackets, and since it has the same number of parameters (maximum 4) as the old Google Analytics pageTracker function, it was a lot easier to search and replace because all we had to do was search for “pageTracker._trackEvent” and replace that by “MyWebtracker.event”.
In case you aren’t sure if you found all those old Event Tracking calls…
What you can do additionally is to write a function called pageTracker._trackEvent that does nothing more than drop off the request to your own new MyWebtracker function (which then hands it over to Google Analytics’ native function again). So in case there are some places left where you didn’t/couldn’t replace the old Event Tracking call, you can still make sure that those events are being tracked. Be aware though that your old basic tracking code snippet really has to be off the page in this case because you’re using the same name Google uses (“pageTracker”).
var pageTracker =
{
_trackEvent: function(category, action, label, value)
{
MyWebtracker.event(category, action, label, value);
}
};
Next time Google changes the tracking code, you’ll sleep just fine
So what is the benefit of this apart from easing your migration? Imagine Google Analytics changed their Event Tracking method again (and they probably will, as there will probably someday be an even better general tracking code). Imagine that this new Event Tracking method not only had a different name again (say, “GATracker._trackEvent”), imagine that it also, again, required a fourth obligatory parameter (like “true” or “false” for the newly introduced “non-interaction” event). In that case, all you would have to do is to alter the one central MyWebtracker object’s “.event” method to fit the new GA standard instead of searching and replacing through hundreds of places and systems.
This doesn’t only hold for Event Tracking
What works for Event Tracking of course also works for other often-used stuff like Virtual Pageviews, Custom Variables or cross-domain link tracking. So next time Google changes its tracking code, you’re prepared to take advantage of it quickly.
Is a short subject line better than a long one? Well…
