Share on LinkedIn Share
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…
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.
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.
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: