There’s a pretty strong push now for everyone to move to the new Asynchronous Google Analytics Tracking Code. It’s the only code that’s available from the interface now, and nearly all of the documentation includes examples of this as the primary code to be used.
Converting your code to the new async code might seem like it’s just a hassle, but there are benefit to using the new code. Because the code loads asynchronously, there’s no longer any danger that it will interfere with the loading of the rest of your page.
This means that the code can now be placed up in the header of your pages rather than right before the closing </body> tag. The result is that you’ll be able to track a greater percentage of your visitors than your were previously, which will improve the accuracy of your reports in Google Analytics.
Now if your setup isn’t too complex, converting won’t be too big of an issue. Your old code might look something like this:
Notice that the only modification on this code from the standard code is the line for subdomain tracking. The approach to converting something like this to the new asynchronous code is pretty standard:
Google has provided several migration examples if you need more information.
But what if your code is a bit more complicated? Perhaps you’ve added initial referrer tracking to your Google Analytics Tracking Code:
The trouble with this type of modification is that it includes a bit of logic in addition to the standard tracking method calls. Something like this certainly looks possible:
This will work just fine for this example. But your code most likely looks very different and may have even more modifications. The benefits of the asynchronous code certainly sound nice, but do you really have the time and resources to change the code, test it, and then figure out where you missed a bracket or comma?
Fortunately, there’s a fairly straightforward way to convert just about any traditional Google Analytics Tracking Code snippet to the asynchronous code:
I personally like this style a lot for several reasons. It can turn the conversion process from a 1 to 2 hour project to a 10 to 20 minute project. There are also far fewer chances to make mistakes. Rather than having to change every single line, you can follow a few simple steps:
1. Start with the following code:
2. Copy everything between “try {” and “} catch(err) {}” from your old code and put it where it says “// Put your code here.” If your code is old enough that it doesn’t have a try…catch block, just copy everything between the the last openingtag of your Google Analytics Tracking Code.
3. Replace “_getTracker” with “_createTracker”. If you have multiple tracking objects, in addition to pageTracker, like a secondTracker, then you’ll need to change the _getTracker lines for these objects a bit more. Something like this should work:
secondTracker = _gat._createTracker(“UA-XXXXXXX-Y”, “secondTracker”);
The “secondTracker” in quotes could be anything at all, but using “secondTracker” might make it easier if you have to reference this later on.
If you have additional code, such as ecommerce code, you can convert these according to the migration examples. You can also follow the following steps:
1. Start with the following code:
2. Copy your additional code, minus any script tags, and paste it where it says “// Put your code here.”
3. If the code used pageTracker as an object, then you’re done. If the code uses secondTracker instead, then you’ll need to change the “var pageTracker._getTrackerByName();” line to the following:
var secondTracker = _gat._getTrackerByName(“secondTracker”);
You can also just add this line if your additional code uses both pageTracker and secondTracker.
One thing that’s worth noting in the all of the above async examples is that no where is pageTracker or any other tracking object declared as a global variable. This means that if you have any onclick events that use pageTracker, you’ll need to update them as well.
While this might seem like another pain to go through, it’s actually very necessary to ensure that ga.js has loaded, the tracking object has been created, and all methods already applied to it have been run, in order, before the onclick event can run. The benefit is that you no longer have to use try…catch blocks, checks for object existence, and recurring setTimeout statements to ensure that everything works properly; it’s all taken care of for you in a much more robust way.
So let’s say you had an onclick event like this:
onclick=”pageTracker._trackEvent(‘Videos’, ‘Play’, ‘Marketing Video’, 10);”
You would have two options for converting this to async:
1. onclick=”_gaq.push([‘_trackEvent’, ‘Videos’, ‘Play’, ‘Marketing Video’, 10]);”
2. onclick=”_gaq.push(function () { var pageTracker = _gat._getTrackerByName(); pageTracker._trackEvent(‘Videos’, ‘Play’, ‘Marketing Video’, 10); });”
Which option should you go with? Option #1 is usually best for simple onclick events like the one above. For longer, more complex onclick events, especially if you’re setting them dynamically, option #2 makes a lot of sense since you can simply wrap all of your statements and simplify your conversion process.
As a final note, if you need to use secondTracker or some other tracking object, this can be done option #1 style like this:
onclick=”_gaq.push([‘secondTracker._trackEvent’, ‘Videos’, ‘Play’, ‘Marketing Video’, 10]);”
The name preceding _trackEvent in the must match the name you passed to _gat._getTrackerByName.
For example, suppose your converted Google Analytics Tracking Code had the following statement:
secondTracker = _gat._createTracker(“UA-XXXXXXX-Y”, “tracker2″);
The correct way to reference this in your option #1 style onclick event would be the following:
onclick=”_gaq.push([‘tracker2._trackEvent’, ‘Videos’, ‘Play’, ‘Marketing Video’, 10]);”
The reason you use tracker2 instead of secondTracker is that tracker2 is the name that the tracking object was registered under, while secondTracker is simply a local reference to the tracker2 tracking object. You can avoid this confusion by simply using the same name for both as shown earlier. Also note that we didn’t register a name for our local pageTracker objects, so these use the default tracking object, which is referenced without a name in option #1 style statements.
Feel free to leave comments if you have additional situations that steps don’t seem to address. Also, while the above steps may be enough to fully convert your code, you may still want to consider purchasing support to do this, especially if you have a more complicated setup.
