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.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies:

Comments

Comments are closed.

1 Posted by johann kuindji on 6 October 2008 | Permalink

Stuffed Tracker: Yes.
1.86% share since August 1 on our site.

2 Posted by Brian on 6 October 2008 | Permalink

Google Analytics: Yes.
4.04% share since 09/01

3 Posted by Aaron Bassett on 6 October 2008 | Permalink

Clicky: Yes
3.1 % share (Sep 7 - Oct 6)

4 Posted by Eric Eggert on 6 October 2008 | Permalink

Mint: Yes.
1% in the last 72 hours.

5 Posted by Blaise on 6 October 2008 | Permalink

AWStats 6.7: No

6 Posted by Krijn Hoetmer on 6 October 2008 | Permalink

Webalizer without hacks: no (obviously).

http://dean.edwards.name/weblog/2007/03/sniff/ for IE btw.

7 Posted by prisca on 6 October 2008 | Permalink

Google Analytics - yes.

my site - http://graphiceyedea.co.uk
(webdesign portfolio + blog)
5/8 - 5/10/08 -- 0.56%

animation - http://diganimation.info
(course website)
5/8 - 5/10/08 -- 0.34%

webdesign - http://webeyedea.info
(course website)
5/8 - 5/10/08 -- 0.76%

8 Posted by Harm on 6 October 2008 | Permalink

http://www.reinvigorate.net: nope
it says it's: Safari 525.13

9 Posted by Waylan on 6 October 2008 | Permalink

http://www.statcounter.com/ - yes
1 hit in last 500 (on free limited account)

10 Posted by Teapot Monkey on 6 October 2008 | Permalink

Google Analytics, yep

for the last month, a 0.98% share across 3 versions of Chrome. (mainly version 0.2.149.29)

I checked Crazy Egg stats as well (www.crazyegg.com) and it reports it as "KHTML-based other"

11 Posted by StormSilver on 6 October 2008 | Permalink

Omniture SiteCatalyst: Yes
Their "Internet Average" says 0.6% since September 1.

12 Posted by Stephen Hay on 6 October 2008 | Permalink

Google Analytics: yep.

13 Posted by Stephen on 7 October 2008 | Permalink

my homebrewed analytics: Yes
2.75% (Sept. 15 - Oct. 6)

14 Posted by Mark McDonnell on 7 October 2008 | Permalink

Woopra: No
Google Analytics: Yes

15 Posted by Bobby Jack on 7 October 2008 | Permalink

Analog 6.0: no

16 Posted by Daan Wentink on 8 October 2008 | Permalink

Google Analytics:

Site: http://www.Eet.nu
450000 visitors, 1693 used Chrome (0,37%).

17 Posted by Daniel Juhl Mogensen on 10 October 2008 | Permalink

Google Analytics: Yes

Site: http://www.gamers-globe.dk
Share: 0,97%

Site: http://www.pixel.tv
Share: 3,33%

18 Posted by Joris von Loghausen on 10 October 2008 | Permalink

Sitecatalyst: Yes
http://www.geenstijl.nl/mt/archieven/2008/09/google_chrome_de_stats.html

19 Posted by Sander Aarts on 11 October 2008 | Permalink

Last February was the last time TheCounter.com updated the start date of its monthly global stats. Since then all its global stats start at the 1st of February 2008, making the stats become less accurate every month.

http://www.thecounter.com/stats/2008/October/browser.php

20 Posted by Rochak Chauhan on 11 October 2008 | Permalink

You can also use this JavaScript library to detect any browser including chrome. Not only this, you can trim a string, detect mouse positions etc

http://rochakchauhan.com/blog/2008/10/11/rochakjs-javascript-class-of-common-functions/

21 Posted by Johan Smits on 12 October 2008 | Permalink

Extreme Tracking: Yes, there are 176 hits registrated. You can see this at:
http://extremetracking.com/open;sys?login=saxion2

22 Posted by Anton on 13 October 2008 | Permalink

Liveinternet.ru : yes, 1,4%

23 Posted by Dan J on 14 October 2008 | Permalink

We at City University also use NedStat, & it looks like they do now track Chrome.

24 Posted by Max Shirshin on 22 October 2008 | Permalink

Regarding browser detects:

Gecko can be reliably detected either by window.controllers, which is a unique XUL-related property, or by dynamically creating a DOM element and assigning a Mozilla-specific CSS property to it, and trying to read that property (I mean those that start with -moz-* prefix).

25 Posted by Ben Cachel on 22 October 2008 | Permalink

Google Analytics: Not Yet - for my quite a new site. It is possible I have not many visitors from among web designers, who probably use the Chrome browser more than general public.

26 Posted by KangaRado on 23 October 2008 | Permalink

Google Chrome hits: Yes

21st Sep. to 21st Oct.
Chrome visits: 545 - 1.22%

Google's Analytics stats; Chrome Browser Version detailed traffic for the 545x visits and the same date span

1. 0.2.149.30 - 515 - 94.50%
2. 0.2.149.29 - 14 - 2.57%
3. 0.2.149.27 - 12 - 2.20%
4. 0.3.154.0 - 3 - 0.55%
5. 0.3.154.3 - 1 - 0.18%


27 Posted by Bob Mitchell on 24 October 2008 | Permalink

Unica NetInsight - it didn't, but can now. ;-)

Anything not using JavaScript for collection, anything looking at simple weblogs is going to be doomed here. That said, logs are useful to spot non-JavaScript aware user agents.

Take the best of both if you can.