A couple of days ago I was lamenting the state of webstats, although I was a little vague as to my purpose. Specifically I was wanting to find out about the screen resolutions and user-agents viewing a couple of sites.
To get screen resolutions you really need to inject javascript into your pages, which is icky. Still its a small price to pay, and chances are most people won't notice.
Of course there are drawbacks:
- Javascript dependency.
If the visitors don't use/enable javascript you see nothing.
- You cannot capture everything.
e.g. HTTP status code isn't available.
To solve this problem completely you therefore need to have access to both your apache logs and your javascript-captured information. Probably.
As a proof of concept I've injected the following javascript into most pages of three sites. This code:
- Finds the screen resolution.
- Finds the HTTP referer.
- Finds the current page's title.
- Then submits that to a server-side collection script, via a one-by-one pixel IMG
The script that receives the data writes out the data to a small per-domain SQLite database, which I can then use to generate prettyness. However I suck at being pretty, in most ways, so I've only got functional:
All of this is dynamic and most of the data is anchored to "today", as thats proof of concept enough. Were piwik not written in vile PHP I'd use that - I don't see anything similar out there which is Perl..
The big decision is now "Keep it dynamic" vs. "Output static pages". (vs. call off the experiment now I know that I'm safe to assume "big resolutions").
(Naming software is hard. Recent stuff I've done has had an skx prefix primarily for google-juice. e.g. Randomly I notice that if you search for my personal site on Google's UK engine I come top. Cool.)
ObSubject: The Bourne Identity
Tags: javascript, random, skxstats, webstats 2 comments
By storing screen resolution instead of window size, aren't you being fooled by users who don't operate their browser maximized?