I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

Browser detects and testing stat farms

During my Ajax Experience session I talked about browser detects and how almost nobody knows how to do them right. I’d like to repeat the main outline of my solution here.

I’d also like to ask you to participate in a little research project by spending two minutes of your time on checking whether your stat package or farm reports any Google Chrome hit. It should, by now. If it doesn’t, it’s likely broken or badly maintained.

This little test will allow us to distinguish between good and bad stat packages/farms.

Please participate. It takes about two minutes. Thanks.

The problem with navigator.userAgent

In order to write a good browser detect, you should use navigator.userAgent only as a last resort. The problem with this property is that browsers (especially the minor ones) habitually lie about their identity in order to bypass browser detects written by clueless web developers.

Take the following string. Can you identify the browser?

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en)

If you guessed IE6, you’re wrong. It’s Opera 9.26 masquerading as IE6. (It could easily be Safari, too.)

In other words, a purely navigator.userAgent-based browser detect will identify many minor browsers as IE. How many? Nobody knows, because all browser detects out there are broken.

Anyway, that’s the reason I propose a three-tiered approach:

1. First, try using something that’s explicitly meant for identifying a browser. As far as I know there’s only two such things out there: IE’s conditional comments and Opera’s window.opera. (If you know of more, please leave a comment.)
2. If that doesn’t help, take a look at navigator.vendor. Not all browsers support it, but the browsers that do all speak the truth — for now. As far as I know Safari, Chrome and Konqueror support this property, while in Firefox the property exists but is empty (in other words: useless).
   There’s a danger here, though: as soon as Firefox and IE start to support navigator.vendor, too, some all-too-bright web developer will hit on the luminous idea to use this property for denying certain browsers access to his site. Then, all minor browsers will be forced to start lying about their identity once more and will give navigator.vendor the value Microsoft. The property will become useless overnight.
   But until that happens, use it as much as you can.
3. Use navigator.userAgent only when the two previous methods fail. If you’re forced to do this, the basic trick is to detect minor browsers first. For instance, take this browser string:

   Mozilla/4.0 (compatible; MSIE 6.0;
   	Windows NT 5.1; en) Opera 9.26
   

   By now you can probably guess that this is Opera 9.26 (this time identifying itself as IE instead of masquerading). However, if you start your navigator.userAgent-based browser detect by detecting IE you’ll interpret this string incorrectly.
   So start by checking for substrings that belong to minor browsers, and resolve IE and Firefox only if you’re relatively sure that the browser is not a minor one.

My browser detect script more or less implements this three-tiered approach (though it doesn’t use conditional comments yet because frankly I thought of that only a few days ago).

Testing stat packages and farms

All this begs the question: how reliable are the commercial stat packages and farms out there? I wouldn’t be in the least surprised if they are totally unreliable because they wrote their browser detects ages ago and never updated them because they don’t follow the browser market and/or don’t know what they’re doing at all.

Fortunately, right now (and I mean right now) we’re in a unique position to test them and see how badly (or well) they perform by checking one simple criterion.

A properly maintained stat package or farm will report some Google Chrome hits by now.

Sure, Google Chrome has a tiny market share (I heard somebody say 0.77% at the conference, but have no way of checking this number, so feel free to disbelieve it).

But if you’ve got a site even marginally related to web development you can be sure that somebody out there looked at it in Chrome, even if only to leave a snarky comment about something not working properly.

In other words, I believe that most sites out there have received at least one hit by Chrome by now. If that hit is not reported, your stat package or farm is just not paying attention to anything.

I’m kind of expecting Google Analytics, at least, to properly report Google Chrome, but I’d love to be reassured in that respect.

So I’d like to ask you all to do the following:

1. Go to your stats and take a look at the browsers that have visited your site in the past month.
2. Check if you’ve received any hit from Google Chrome.
3. Please leave a comment with the name of the package or farm and a Yes/No for a Google Chrome hit.

Nedstat, possibly the oldest stat farm in the world and the one that I use, fails miserably. So does thecounter.com, which I use for getting huge aggregate numbers.

Thanks for cooperating in this research project.

Comments

Comments are closed.