Views

From Shadowfax

Monitoring website statistics appears to be something of a black art. This is not helped by the fact that none of the free stats packages are really any good. There are plenty of sites out there which list the top ten web stats packages - what they don't tell you is that none of these packages really helps you very much.

Stats packages come in two main flavours. Log-based stats and JavaScript based stats.

Contents 1 Log-based stats 2 Javascript-based stats 3 Grow your own reporting 4 So what to do? 5 The danger of reporting

Log-based stats

Largely speaking the log based stats packages are uninspiring. They collate your logs and present you with raw single dimension stats. If you want to know absolute numbers of hits per month then this is the best place to go. The problem is what does that really mean? The main problem with information is that every report that someone generates to answer a question poses ten more and sadly none of the free log viewers gives you anything like the toolbox you need to answer them. It's a shame really - because log-based stats have access to all the information, so they should be able to offer drill-downs and multi-dimensional reports on everything that is logged.

Most of the free log-based stats packages I have tried are ugly and fundamentally unsatisfying. Smarter Stats allow free use of their paid product for a single domain. This is at least better looking than the run of the mill free products, but again it largely concentrates on single dimesion reporting.

Despit the limitations of the software solutions log-based stats packages have a number of major thing going for them. They are accurate, they allow you to track robots, they allow you to track non-html content and they help you to spot errors.

Javascript-based stats

By contrast with their more pedestrian cousins, the free javascript-based stats packages tend to look quite good. Some of them (for example Google Analytics) even offer the beginnings of multi-dimensional reporting. However, javascript-based stats also have a number of obvious and not-so obvious weaknesses. The obvious weakness is that they only track javascript. This means that they don't track robots (a double-edged sword - sometimes this can be advantageous) or non-html content. It also means that they can fail. If the Javascript has a browser specific bug or just fails to load you miss out on that page-load being logged. More worrying - most JavaScript stats packages export your log data to a third party.

These days we're so used to Google stealing all our data we don't really see that as a problem. But it is a problem for a couple of reasons. Firstly that delightfully simple javascript call can cause page-load slowdowns if the logging servers are running slow or there is in internet problem between you and them. Recently I tried out one of the new kids on the block only to find that a simple JS call to their servers increased my page-load times tenfold. Their technical support denied the problem, but my experience was backed up by Google Webmaster Tools handy graphs showing the effect on its crawl download speed. I turned that javascript off and all returned to normal.

Secondly, free service providers don't really want to keep all of your reporting data for all time - so they tend to be selective about what they store and for how long. For this reason the multi-dimensional reporting is strictly limited.

So for all their initial glitz, JS packages fall short of the mark too.

Grow your own reporting

It is also possible to do your own reporting. If you have access to your log files you can download them to a safe location and import them into another tool of your choice. They do get very big though so this can be quite hard to do.

If you are happy programming then it is relatively easy to knock up your own Perl scripts to filter out the bits you'd like to explore and to run bespoke reports on the logs. You need to have a basic understanding of the logs layout - but once you start delving into them it does become more obvious. The biggest issue is staying on top of them. There is no standard for the way that certain fields are encoded (and even if there were it would be open to abuse). For example the user agent field should allow you to split out robots from real visitors - but each different client fills in its details in slightly different ways.

As a programmer, you can also insert bits of code to write your own logging information to file or to a database. Combine this with Goggle's excellent charting API and you have the beginnings of your own reporting package. I hope in the next month or so to write a bit more detail about how to do this.

Bespoke reporting can be very useful to answer questions which none of the software wants to - but given the overhead of maintaining it it is best limited to those areas which the packages do not provide.

So what to do?

At present the best solution seems to be to mix and match. Google Analytics for all its weaknesses is a good piece of software. It is the best of a bad bunch at least. It is useful for reporting on traffic trends and referrals. Log stats packages can then be used to fill in some of the gaps, and if you have the skills homegrown reports can be used to answer one-off questions or tidy up an remaining gaps.

I'm not sure if I'm just overly demanding, of it is because I've played with commercial business intelligence software, but it seems to me that there is a long way to go still before free web statistics packages offer anything like the full set of tools to really understand what is going on with your website.

With a number of open-source offerings emerging at present hopefully the picture will improve with time.

The danger of reporting

Google watching is addictive. I recently wrote myself a little Adobe Air application so I could track in real-time the hits coming into my website. I can't say that it has particularly enlightened me but it has provided significant stress - particularly on slow days when no-one seems to be hitting my site. Perhaps I should just go back to the old-fashioned way!