Before I even start talking about this, let’s go to code.google.com for the official recommendation on where someone should place their Tracking Code on their webpages…
The Analytics snippet is a small piece of JavaScript code that you paste into your pages. It activates Google Analytics tracking by inserting ga.js into the page. To use this on your pages, copy the code snippet below, replacing UA-XXXXX-X with your web property ID. Paste this snippet into your website template page so that it appears before the closing </head> tag.
The Google Analytics Asynchronous Tracking Code
Ok! Thanks for reading, see you next time!
Just kidding, of course it’s not that simple.
So seriously, where should I put my Google Tracking Code?
We actually get people asking us about this a lot. It’s one of the first items in our audits that we look at. What version of the tracking code are you using, and where is it on the page. There are plenty of variations, but the most common one if it’s not completely up to date, is having non-Asynchronous (or ‘traditional’) tracking code, which is placed at the bottom of the page. So when the first item in our audit says “We recommend you update to the Asynchronous tracking code, and move it’s placement into the <head> of your document, rather than at the end of the <body>” people get worried.
Is it bad to have the Google Tracking Code at the bottom of the page? I read that you should put it there at the bottom, rather than up in the head because it makes your site faster.
Should you place the tracking code in the <body>?
The quick and dirty answer is that yes it’s safe to put the new code really anywhere on the page, and for 99% of users, you’ll want to use the Asynchronous code and put it in the head of your document. There are a few exceptions/alterations which I’ll note in a minute.
The less quick part of that answer is that it WAS bad to put the traditional Google Tracking Code in the head of your webpage in the past, so if you read some book or blog purporting to speed up your website extolling the virtues of putting the Google code at the bottom of the page, then they may have been correct once, but they aren’t anymore. The speed of the internet, and all that jazz.
Google released the Asynchronous Tracking code on December 1st, 2009. Prior to that point all we had was the traditional code, and it worked like most other basic JavaScript code. That is to say that it would go one line at a time. So when your browser loaded up a line of code, it would load that line only, and then wait till that line was fully loaded. Then, and only then, would it move to the next line, and then load that line, etc. Like a single conveyor belt. The problem with that design though, is that if you ran into a snag the entire page would hang. So if the Google Tracking Code back then was placed at the top of your webpage in the head of the document, then the speed your site loaded was partly determined by how quickly Google sent you that code. If it took Google 10 seconds to send you that code, that was 10 more seconds your visitor had to wait to view the page. That’s why it was recommended to put that code at the very bottom of the page. That way if it stalled in loading the files from Google, at least your page was loaded first.
The Asynchronous code though works differently. Rather than say a SINGLE conveyor belt, now there are multiple ones, and the rest of your page can load up regardless of how long it takes to retrieve data from Google. The tracking code loads up on its own conveyor, while the rest of your site loads on another.
And on top of that the Asynchronous code is designed to be downloaded only once from Google, and then it’s served from your cache (i.e. it’s saved on your computer and you won’t have to download it again), which makes it that much faster.
You lost me poindexter, what does that mean for me?
It means the asynchronous tracking code averages a 5% improvement in tracking data, with some sites showing 10 and even 20% improvement in their data. If you use Adwords, it closes in on 100% accuracy with the asynchronous code.
The asynchronous code is faster, and therefore you get better more accurate numbers as to how many people are actually visiting your site.
What if I have events or things happening on the page, where I need to record user actions, and the tracking code hasn’t loaded yet?
Well, that problem would also happen if you had the non-async code firing at the bottom of the page, but with async it’s much better. Even if it takes time to load the ga.js file from Google, it’s already set up the tracking variables on the page, and will store the events you perform before the actual file is loaded. Once the file loads, then all the events backlogged will be sent to Google. It’s not PERFECT, but for the most part it will capture events that happen prior to the Google tracking code has even finished loading, and send them after the code has been loaded.
So do I need to move it to the head of all my pages? I have a lot of pages, and that’ll take a lot of time.
You can put your tracking code anywhere, but it's better in the <head>
Nope. You can put it anywhere you want really, and It’ll run anywhere on the page whether it’s in the head or the body. It’s recommended you put it in the head though, so it can be as accurate as possible.
You see, the Pageview is recorded only after that code is loaded up. So the sooner you load the code, the sooner that Pageview is recorded. Let’s say you have a big blog page, and it’s a slow loading one, taking even 10 to 20 seconds to load everything up. If your Google Code doesn’t start until the end of the page, it can get held up, just like the old non-asynchronous code used to hold up OTHER lines of code. Except now it’s holding up the tracking code. If a visitor to your site hits the page, and then leaves it before the tracking code fires the Pageview, then you lose that visitor. They now become a new direct visit to whatever page of the site they landed on. This can make all sorts of data on your site incorrect.
So it’s best practices to use the Asynchronous code in the head of your page, it won’t slow down the rest of your page from loading, and by having it there it won’t GET slowed down by the rest of the webpage either, so it’ll fire sooner, and you’ll get a more accurate count of what pages your visitors visit.
So what are the exceptions? When is it BAD to run the tracking code up in the head?
I mentioned before that there ARE a few exceptions. One is if you’re setting custom variables on the page.
If you set a Custom Variable on your webpage then it will essentially sit on your page, waiting for either a pageview to be tracked, or an event to be called. If you set a custom variable on a page and don’t track a page or an event after it, that custom variable will NOT get passed to Google. Sometimes you might not be tracking any events on a page, but you’ll want to set a custom variable. Because of how code is delivered, it’s possible that custom variable might only get generated AFTER the head document. Usually a page can be coded so that these variables can be determined before the HTML is delivered and then you can have the custom variables created in the head of the document as well. Maybe it could theoretically be put in the head, but the developers didn’t build the page that way, and you’re not willing or able to have them redo everything. In those cases you can set a Custom Variable anywhere on the page, and then rather than tracking the pageview in the head of the document, you remove this line:
_gaq.push(['_trackPageview']);
from the Asynchronous code, and then insert it later in the page wherever you like, after the custom variables are set. That way the code loads up, it doesn’t interrupt the page load, and you can then track custom variables on the page itself anywhere they appear, as well as retaining the benefit of loading the tracking code early.
HOWEVER, this can also reduce accuracy, because if a user navigates away before that trackPageview is called, then you’re facing the same problems that the traditional code presented in the first place. Another option would be to use Event Tracking. An event being fired will also submit that queued custom variable, so you could fire an event tied to that custom variable. Essentially a throwaway event.
_gaq.push(['_setCustomVar',1, 'Status', 'Logged In']);
_gaq.push(['_trackEvent', 'Custom', 'PageLoad', 'Setting Logged In State',0,true]);
A couple notes on this:
First we’re setting the Custom Variable, we’re assigning it to key space 1 (of 5), and we’re calling it Status, and setting the value to Logged In. That’ll sit there until an Event or Pageview is tracked.
So we do the event. We set it to a Custom category group, we definte the action as PageLoad because a user isn’t specifically interacting with this event. Then we set the Label as to what the event is doing. We add a 0 to the value (you don’t have to add an actual value there if we’re not using it, but I’m personally uncomfortable passing nothing). We also then set the non-interaction value to true. This is also key if you use an event here. If you don’t set it as true, then the event is considered a page interaction, and it will affect your bounce rate from the landing page. Essentially rather than someone coming to your page looking at it and hitting the back button being considered a ‘bounce’ It would not be considered one because the user ‘interacted’ with the site. So we set this to true, so that isn’t considered in that respect.
But wait, I read something on Google’s own support pages that said I shouldn’t do this?
You mean this page?
Yeah, you don’t believe everything you read, do you? That’s old outdated support information.
So if we update is it going to change my data? Like am I all of a sudden going to see more pageviews or something?
It’s possible. It depends on your site, where the code was, what sort of speed and pageload times you have. By updating you should see the data you’re getting change, maybe a little, maybe a lot. But it’ll be MORE ACCURATE data. Here we tend to side with getting the data to be as accurate as possible, even if there is a bit of a break in the levels of reporting.
If I don’t update, will my site continue to track data?
Sure. It probably won’t be as accurate, but depending on your site it’s conceivable it’s not a huge data difference. The main functions are all loaded from the same place, the ga.js file. The main difference is how it loads, how fast it loads or is even cached in your browser, and therefore the accuracy of your data.
So what should I do?
If you’re NOT using the up to date Async code you should update to using that. You’ve really got to have some serious things going on to NOT update. Does it need to be in the head of the document? No, it won’t kill you to have it at the bottom of the page, but if you CAN move it to the top, then you should because it’ll be faster and more accurate. If you don’t know of a reason to keep using the non-async code at the bottom of the page, and you’re not using custom variables… Then really there is no reason to NOT update it and move it to the top of the page. You’ll have more accurate data, you’ll get newer and better tracking features, and more. Come on. Everyone’s doing it.
Where Should The Google Analytics Tracking Code Be Placed? is a post from: Google Analytics, SEO, Social Media and PPC blog
Copyright Increasing your Website’s Conversion Rate – Where Should The Google Analytics Tracking Code Be Placed?
Did you like this? Share it:
RSS Feed
Twitter
February 12th, 2012 
Modern B2B Marketing
