Champagne, Science and Technology

Monday, March 13, 2006

Google Analytics Solutions (Part 2)

Following on from my earlier post: Google Analytics Woes And Solutions; with how my favourite champagne site seems to deal with the unresposiveness of the tracking part of analytics...

In the first post I covered how they deal with loading the urchin.js file when the server was unresposive. Here I cover how they manage keeping the page rendering fast when the tracking is unresponsive. Rather than the regular:

<script type="text/javascript">
_uacct = "UA-xxxxxx-x";
urchinTracker();
</script>

Which contacts Google with the tracking information, they take the execution of the tracking outside of the page rendering, so the page will display and any onload functions will run un­in­flu­enced by any delays in the tracking, as show below.

<script type="text/javascript">
_uacct = "UA-xxxxxx-x";
setTimeout("try{urchinTracker();}catch (e){}",10);
</script>

What they do is fire it off in a timeout or background thread, so the page finishes loading fast, the body's onload fires and all that kind of good stuff happens. (Obviously the UA-xxxxxx-x in the line _uacct = "UA-xxxxxx-x"; would have to be set to your unique code or you won't record anything)

What are the possible downsides with doing this?

  • You aren't using it the way Google suggests you should be using it

  • It might not work in every browser, works on IE and Firefox, but I don't have a Mac to test Safari and be sure about that.

  • If people leave the page too quickly the timeout might not have fired so they won't be tracked; on the other hand if they wait 2 mins for the page to load they are probablly going to leave anyway, not be tracked and possibly not come back...


I'll have to think on this more but this seems to work nicely...

Update
I took the plunge and have been trying this since Saturday. I am getting tracking for Internet Explorer, Firefox, Safari, Netscape and Opera; so it seems to work with most major browsers.

Reminder
If you do do this remember to keep your urchin.js file fresh with the one from Google as I doubt they'll say when its changed. You should have some leway as they will have to cope with a little lag from proxies caching the file. (see: First post:Google Analytics Woes And Solutions)

Google Analytics Woes and Solutions

Periodically the Internet seems to go slow, least it does for sites that use external advertising and Google Analytics. Last Friday this seemed to be particularly bad for site using Google Analytics as pages started taking minutes to load!

Presumably this is because the external sites serving the scripts are a little heavily loaded as they are so widely used?

However, my favourite Champagne Review site seemed to remain quick and responsive. I knew they used Analytics, what was going on? How were they unaffected?

Their solution seemed to be double pronged, one was that they use a local copy of the www.google-analytics.com/urchin.js file, so rather than:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>

They have:

<script src="/script/urchin.js" type="text/javascript"></script>

This will save one trip to google-analytics.com site to fetch the script file so would increase performance when the site is down or heavily loaded. An obvious gotcha with this is the local file would have to be regularly updated to stay in line with Google's.

Prehaps the more interesting bit is their second solution to the unresponsive tracking code, which involves another fetch to Google's analytics server, as obviously this cannot be done locally.

I'll follow up in my next post...
Google Analytics Solutions (Part 2)

Thursday, January 12, 2006

First post

In the traditions of ./ I'm doing a first post...

Well just testing it works really...