I really like Google Analytics - the interface is easy to use, the information easy to interpret and it's free. You can do great tricks with filters to slice the data in different ways. I do wish that less of the reports used sample data and it'd be nice if you could label points in your data to cross-reference with your SEO activities. But the one thing that really bugs me about Google Analytics is that the JavaScript you tag your site with is broken.
OK - it's not completely broken but it is brittle. Brittle enough that the standard version doesn't work at all when I access sites at work. On every page I visit on Twitter (which uses Google Analytics) I see something like this:
See that long dashed line at the bottom of the page that looks like a very long JavaScript comment? Let's have a look at the source code:
What is missing here is the JavaScript include reference to google-analytics.com/ga.js. It has been replaced with the long JavaScript comment. This is how it should look:
The long comment also causes a JavaScript error. Here is one from Distilled's site (who also used Google Analytics):
This error is saying that the browser is not able to find an object called _gat and so it is not able to execute the _getTracker() method on it. In effect this means that my visit to this site is not being tracked.
Interestingly enough, if you get the very latest Google Analytics JavaScript it includes a
try { } catch (Exception e) {}
block around the whole section that does the _getTracker() bit. This will suppress the JavaScript warning but is a bit like burying your head in the sand.
So what is happening here? The _gat object is set up in the ga.js file that should have been loaded, but the line that loads this file has been commented out. Why has that line been commented out? Well, I don't know exactly, but I'm pretty sure it is some form of filtering going on by the firewall in the network at my work. I imagine the same filtering is happening on other networks with the same firewall.
If you are still following me (I know this is quite techie - I will show you a solution to the problem soon), you might be asking, "Why would a firewall block this piece of JavaScript?" My hypothesis here is that the firewall is taking issue with the combination of document.write and unescape to dynamically include the ga.js JavaScript file. This is probably because it matches the signature of JavaScript attacks such as cross-site scripting.
So why does the JavaScript do a dynamic include using document.write instead of just using a simple <script> tag? Let's have another look at the top of that JavaScript:
This script is basically looking to see if the page is being served from a HTTP or a HTTPS page and then loading the ga.js JavaScript file from either the HTTP domain (https://www.) or HTTPS domain (https://sss.) for google-analytics.com. The reason for this is to stop those warnings from your browser you get on HTTPS sites that part of the page is not secure. Loading the JavaScript from a secure host will stop this warning.
So what is the solution? Well, if your site only uses HTTP then you don't need that bit of JavaScript to work out where to get the ga.js file. All you really need is the following (substitute your Google Analytics account number as appropriate):
If you use a mixture of HTTP and HTTPs, I suggest you do the calculation of which domain to load the JavaScript from server-side. Here is an example in PHP:
I am not guaranteeing this JavaScript, but it certainly works for me - the JavaScript include is no longer replaced by a comment and there are no more JavaScript errors in the browser.
Now, whilst I'm at it, this JavaScript still doesn't fill me with confidence. The problem I still have with it is that, due to the asynchronous way browsers load external resources (JavaScript files, CSS files, images), there is still a chance for there to be a JavaScript error on the _getTracker line. This would happen if that line were executed before ga.js was downloaded from google-analytics.com. With the try/catch block around it you would never know it happened (silent failures are one of the worst things to happen in code).
Most JavaScript for other analytics providers do things the other way around--they set up the variables required to identify the account and the other information about the page in JavaScript before they include the external JavaScript file. Here is an example for Quantcast:
This script sets up the analytic options in a nicely scoped JavaScript associative array (_qoptions). It then loads the external JavaScript file (quant.js), which does the equivalent of _getTracker().trackPageview(). Omniture HBX does a similar thing.
Hopefully this technical look into the issues with Google Analytics has been interesting and helpful. Google - if you're listening - try taking some hints from what I'm saying, remove your head from the (try/catch) sand and fix it once and for all.
Stephen T
I knew you were sharp but this is really top drawer stuff. Nice work.
You're my new hero
Thanks - glad you followed it ok. Was worried I went a bit uber-techie!
I have forwarded this to our developer to explain in t'yorkshire language lad.
Excellent post though Stephen, I'm one of the many fools who's seen these errors and had no idea what they were.
Yeh, I found it pretty quickly and luckily found a solution to it. There seems to be a number of other people suggesting solutions in Google Groups but they all seem very hacky to me. My solution is pretty simple, although I still feel the best approach would be for Google to change the way the JavaScript is loaded so it is more like the Quantcast example I gave.
I think this was a very informative blog.
I however don't think this problem is some thing Google really needs to address since it more of a problem with the end user's computer/network. No matter what coding changes they might make, some custom settings some where will potentially break code.
I also enjoyed options you supply for webmasters to fix this issue, but there should really be one standard plug and play piece of code from Google. Any time code needs to be modified by a webmaster there is the possibility of errors, which wouldn't occur if the standard code was used.
The people that should be working to rectify this problem is the people who are running your network at work and adding an exception for the Google analytics code. This of course is assuming it is them causing the issue, after all obviously Google isn't trying to execute malicious code (well that I am aware of lol).
Firewalls are great but sadly a lot of people do not set them up correctly or set them up more strict then they need to be.
I am more of a developer then an SEO, but the one thing I learned a long time ago is some people are going to do things that make your website not display correctly to them. Only thing you can do is build things to logical standards and if they work in a normal environment you are on the right track.
I agree, there should be a standard supported version that Google supports. I think that the recent addition of the try/catch block in the JavaScript may be an indication that Google knows there is a problem where their code could go wrong. I'm just giving my thoughts on what may be happening and some ideas on how to reduce the risk of the code failing.
Great post Stephen, I don't fully follow the technical ins and outs but I DO understand the implication which is less accurate tracking. I'd like to see Google look at this solution or at least discuss why they don't use it. Too often we take analytics as exact data when in fact it's always inaccurate, all we can do is improve that accuracy and anything we can do to improve the accuracy should be done.
Thanks Tom. I also assume you liked my cunning link drop for Distilled!
Bien Sur - thanks Stephen :-)
Though, having said that, who else could you have linked to? Isn't Distilled the only site in the world that uses google analytics?
Erm I know a site that uses Google Analytics (hint it helps people find when TV shows are next on TV, online and on DVD) but didn't want a conflict of interest. Did you spot my other cunning Twitter profile link drop?
You and your Twitter double flattery!
Good point Tom as well, it's well known that GA ecommerce tracking is... speculative at best but everyone does assume that the rest is gospel.
Thanks for the promotion to the main blog guys! You rock!
Thanks for the great blog post, Stephen - you rock!
Problems: The solution, add a javascript comment inside both the ad's script tags and the analytics script tag.
/* Google Ads */
and
/* Analytics */
- source: https://willcode4beer.com/tips.jsp?set=analyticsError
My brain hurts.
The combination of the sheep avatar and "my brain hurts" gives an instant thumbs up!
I've been hacking away at Analytics code for a while now, adding features and customisations, and this is the most useful post in a long time on the subject.
Cool would love to hear about some of your hacking!
You lost me completely at "So why does the JavaScript do a dynamic include using document.write instead of just using a simple <script> tag?", but I'm definitely going to ping this over to someone who'll mmm and aah and understand. I may have missed this somewhere, but will the "brittle" version of the script still track pageviews? Thanks for highlighting this!
E
Sorry to loose you there! The brittle version of the script will still track pageviews for the majority of users. The only ones it won't be able to track are those who have the same JavaScript filtering that we have at our work. So I can probably go all over many people's site and they won't be able to track me in Google Analytics.
Lovely, thanks very much :)
Like Erikau I'm a little lost, as I don't know the first thing about coding; however I fully plan to pass this on to someone who will.
Thanks Stephen I think this is an excellent post :)
The bug is doing something much worse on your blog - take a look at what I see on one of your articles when viewing it in Firefox (it's find in IE). Nasty! Where did all your content go?
Seems that the WP plugin Google Analyticator is adding the Google Tags to the header of your page (the recommendation is to put them at the bottom). By doing this it has unwittingly commented out the rest of the page. Ooops.
I guess it might be doing that to track actions on the page - you have to have the js at the top if you want click tracking on outbound links etc. Makes this issue even more unfortunate!
@Stephen T - Uh oh - really not good! Unfortunately I can't replicate the error... Any ideas as to what I should do?
Try another analytics plugin, e.g. this one from Joost - that might suppress some of the problems by putting the script at the bottom of the page (I haven't tried it though). At least then your page layout would not be screwed up but you still wouldn't be tracking visitors who experience the brittleness of the JavaScript.
Would be great is one of the Wordpress analytics plugins used the PHP code that I suggested above as it would certainly help.
Brilliant - will give it a go - thank you for spotting the problem and letting me know :)
Wow, That is a whole lot of code!
Thanks, trying to increase the code to word ratio on SEOmoz (some more on my Yahoo Search Monkey post and Google 404 Pages post).
Your code is broken lol ;)
The link is: Yahoo Search Monkey
Thanks for that. I think the link was right when this post was on YOUmoz so maybe something odd happened when promoting to the main blog. Here is the right link to the Google 404 Pages post.
It seems that the blog software for SEOmoz is broken (it seems to convert absolute links into relative links if the URL is on SEOmoz).
Great post. You'd think that with all the js gurus that Google has they'd have thought about this. It probably doesn't come up very often I guess. I've personally never seen the problem although I'm only behind a firewall at my job.
One comment about the last part of your post. I believe that while script tags' source can be downloaded in any order, they are always EXECUTED in order, so I don't think your last concern is really a problem.
Happy to stand corrected here. It would mean that my solution should reduce the risks of things going wrong. I have found, however, that many of the other analytics JavaScripts out there do set up variables before including the external file.
Killer stuff! I'll be checking all my sites and fixing the code where necessary.
Could you explain me how to include Google Analytics tracking code in my Twitter account home page? I logged in in my account but I don't see any template editing tool to add javascript on my page.
Thank you in advance
demonfly
The Google Analytics tracking code I showed is that added by Twitter so they can get analytics on their users. You can't add your own tracking code as far as I know (as is common with most UG services JavaScript is blocked).
interesting observations. I never had any problem with any of my websites so far!
Google analytics is highly useful but you have pointed out a major pitfall as well.But how to sort it out.
https://affiliate-mrktng-tips.blogspot.com
Great post, although the emphasis of the discussion at the start of the article was a little unclear. Raises some interesting issues though. Thanks
Andrea: It's not so important that is breaks when you surf a site, but that visitors to YOUR site who are on secure networks and suffer these symptons may not be tracked properly.
True. My point was that when I have surfed our two sites from a secure network, I haven't yet experienced this. I'm wondering if the Analytics plugin that I'm using has already addressed this issue. I'm hoping that is the case.
Mind bolwing info on analytics
I personally found this interesting from many stand points. I have felt that there was something wrong or missing from our GA script, but being that I am not well versed on javascript, I haven't been able to prove what it was.
I noticed that our pages viewed fine in IE but in FireFox, Opera and Safari we always got characters from the document.write function displaying at the bottom. I found something that suggested we add "<![CDATA[" (minus the quotes) to the beginning of the scripts, after the script type declaration and a closing "]]>" at the end. While I found that it did suppress the visual anomoly it also broke other javascripts used to validate forms. Removing the before mentioned fix got things back to normal on form validation.
I am quite disappointed that there is not a standard out there, with all of the genius' available, to standardize this important piece of google heritage, lol.
I notice errors when our pages load, thanks for keying me on what might be the culprit.
"it's a shame that the IT guys really aren't all that into the internet "stuff""--- Bear in mind that one must pick his path, there is much to know in every field. You don't expect the trash man to fix your septic tank, do you? Refuse is refuse, right? Well computer related fields aren't all the same. End users make the assumption that IT guys should know networking, web design, PBX phone systems, word processing software (install, troubleshooting, and instruction), and be electricians on the side, because it is just that easy to them. It's just like these job posts where they want 5-10 years of real world experience, a portfolio, and want you to know html/xhtml/css, javascript, perl, asp, php, word press, craigslist, photoshop, illustrator, several content managment softwares, google and yahoo cpc, and then offer $10/hr.
We ran into this problem five months ago. Apparently google-analyitics.com has a naughty word in it...you know google-analyitics.com (ANAL). That causes most corporate firewalls to block the address. Your solution is an interesting fix, but the real question is how much traffic are you missing as a result of corporate firewalls blocking access to the google-analytics.com site. We contacted our firewall vendor (Symantec) and had them fix the problem for us, but the problem will exist for others.
He he - classic filth filtering implementation gone wrong. I feel sorry for anyone who live in Scunthorpe who come across the same type of filtering.
It's too bad Googlebot is missing all of this.
While I definitely feel that Google Analytics could provide more detailed information and tracking in some areas, I have been fortunate not to have any breaks in functionality as you have described here. If I do run across this in the future, I'll have a better idea of what is occuring and how to address it. Thanks for the informative post!
This is fascinating stuff! Thanks for going into such detail. Just last week a we were trying to figure out why our Analytics results were significantly lower than our log-generated stats (even after accounting for hits from bots). Majority of our visitors would've been coming from schools across the UK and Middle East, so firewall antics are a very likely culprit!
Instead of burying our heads in the sand with the try/catch method, how about using window.onload()? Or if necessary a custom onload function that makes sure the call doesn't cancel out any other attached functions to onload?
I mean as long as we're ignoring Google's recommended embed method, we might as well make it work...
Great post, complex enough to make me think over my morning coffee, but with enough info that I'm sure I could implement it if I want to.
I'm also glad to hear that I'm not the only one working for a company with a firewall designed to break the internet, it's a shame that the IT guys really aren't all that into the internet "stuff"
I wonder why Google isn't just leaving the protocol part off. Then it should use the given one, from the loaded page, so either https or http. That way they couldn't use their different host name (ssl), but there's no real need for that anyway.
Yes this is an interesting point. If I understand you correctly you are suggesting that they would change the include to be something like
<script src="//www.google-analytics.com/ga.js"></script>
I'm not sure whether this would work. The Quantcast script does a similar thing but still has a different subdomain and still qualifies the protocol for HTTP.
Yes, thats correct.
There's no technical reason to not use the identical hostname for https and http. Not sure why they use this rather complicated way...
In regard to labeling data points - I really wish this were a feature too. Installing the FF extension GA Notes is a decent way to leave notes back and forth between people.
aye but stickin in posties within GA that could be viewed across selected profiles (tick box users with access or all) would be awesome - and not that tricky....
Seems interesting, great article with intaresting insights. :)
Whilst i'm not a coder (and there are many of us who arent) its interesting that you flagged up these errors.
How is your firewall configure/what type is it? - many companies have corporate firewalls - might be interesting (and disastorous) if ALL of IBM for eg. werent tracked.
Also as will mentioned - if you want to do event tracking you have to put the GA tag at the top so that it registers before the events you want to track (and seeing as GA event tracking is a big deal to them i guess they'll want to fix it soon!)
I've got several bug bears with GA - whilst its great that you can hack it - you shouldnt really need to, and if they insisted then why not make it more like mozilla with easily added plugins?
Filtering internal IP's/Computers? nightmare..
I'm on a fairly comprehensive firewall (working for a big ISP) but dont see any of those errors.
Double thumbs up Steve
Actually to follow on. One of the KEY USP's of GA is that its user friendly and easy to use, easy to install.
Now if they want to increase their market (and they'll be under pressure from IndexTools/Yahoo plus big firms like omniture) is to increase the off the shelf value of GA,
So -
Thus we wouldnt play around with "did that work or not" worries, IT shouldnt be fixing GA's problems (priorities anyone?!), nor should developers and neither should SEO/Analytics people.
Excellent job. Very impresive article. I have saved it in my folder
Gr8 find Stephen! I'm sure that Google is looking at this now if not earlier.
Following you on twitter
Thank you! I've had seen others calculate which to use server-side before, but never knew if there was a reason behind. This definately clarifies that.
Also, just in case it may be of use to anybody:
If you use some of the apps to test if your GA code is installed correctly (like, the FireFox extension and I think Site Scan), they've always said for me that there's an installation error when there really isn't. I figure they specifically look for Google's code, as opposed to seeing if the ga.js is loading.
No big deal (since you'll see your data come in, given time), but I know it can be worrisome if you question whether everything's working or not. :)
Not being a technical wiz I had been interested to see why analytics was firing all the errors and recording stats incorrectly at times because of it. Thanks for the code help, it is greatly appreciated.
No problem. Glad to share technical help - I know many SEOs who don't have a technical background so it's good to help where I can.
It is really disgusting that google script lead to an malfuntion
Thanks for the lame linkbaiting, sensationalist headline. Google Analytics is broken? No, I'd say your firewall is broken. Seriously, I expect better than this from seomoz.
The title of the post is not that Google Analytics itself is broken but that the JavaScript is. I simply wanted to share my experiences and hoped others would find my tips useful. Also I hope I showed that there are ways in which Google Analytics could improve the robustness of their code to reduce other risks related to browser download timings (which is nothing to do with Firewalls). Anyways, sorry this post didn't appeal to you.
I actually thought you were flagging the js being completely messed up as when I checked on my analytics today a couple of sites were flagged and had to have the new version of the tracker code installed. Be ever vigilent!
The information was useful to a small group of people and it's great that someone is helping out the less fortunate. But it was sensationalist bordering on FUD.
I think the title was totally misleading and I wouldn't have read the article had I known it was a PHP work-around for a firewall issue.
I thought it was a great post, and I found the title to be appropriate - I was looking for problems with GA that I needed to be aware of, and I found them.
Thanks for your work Stephen, appreciated!
Constructive criticism supported by some actual facts tends to go down better than just insulting authors.
Seriously, I expect better than this from bitchy commentators.
Seriously, I expect better than this from seomoz.
This isnt an SEOmoz post, but Youmoz.
To be honest, I expected better than such a rude comment to some serious amount of work put into the post - The issue IS with JS on the google analytics - whether it affects firewalls or browsers is moot - the fact is tracking isnt happening.
And Stephen painstakingly went through steps on how to maybe look at a solution.
Agreed - and the JS is "broken" if it produces errors, which in stevens case it is.
"Thanks for the lame linkbaiting, sensationalist headline."
Thanks for the lame, linkbaiting, sensationalist comment.
Next time you might want to try actually reading the article rather than just the headline, unless everything but the headlines are blocked by your firewall. Which would make it broken.