Client-Side Web Stats

February 2, 2004 3:47 PM

Does anyone have experience with client-side (cookie and JavaScript) web stat programs? Because they don't need to analyze massive log files, they seem to be the way to go... but I have yet to find an open source and/or cheap or free version. If you have experience using either a hosted solution or anything else that is client side, please post.
posted by cell divide to computers & internet (8 comments total)

I'm not sure this is exactly what you're after, but I built a client-side javascript log analysis utility a few years ago for personal use. It still used log files though...

Basically, you paste the log file into the browser utility and it churns on it for a bit and outputs scannable reports for browser stats, referrers, and IP hits, along with customizable scope for viewing which files they hit and their duration of stay.

It worked pretty well, but once I moved to a host that had Webalizer, it pretty much got blown out of the water. Still, I'll e-mail you a copy if it sounds like what you're after.

It seems like the only way cookies might come into the picture is if you only cared about recording your own browsing history. Even then, it would only realistically work on an intranet, or your own site since cookies and javascript can't access page information cross domain.
posted by Jeff Howard at 8:38 PM on February 2, 2004

Because they don't need to analyze massive log files, they seem to be the way to go...

If you've got a comprehensive and authoritative record of site usage, why would anything that doesn't analyze it seem like the way to go?

I would think that Webalizer et al. can give you much more accurate and thorough results than can javascript/cookie systems.
posted by oissubke at 5:58 AM on February 3, 2004

I've written cookie based traffic analysis tools. Highly recommended. Also a serious resource hog. Doing an extra database write for every page doesn't scale well. And having the page wait for you to parse several strings with RegEx is asking for trouble on a busy site.

Still, you get right to the meat of the issue in real time. And grabbing just the info you want makes it easier to customize. And if you run several sites you'll be able to track cross traffic easily.

My stats thingy is still in beta, but if you email me I'll be happy to send you the php code and the database schema.
posted by y6y6y6 at 7:35 AM on February 3, 2004

Oissubke, the problem is that if you are running a massive site, those log files get very unwieldy. Furthermore they are often inaccurate because of various ISP (AOL especially) IP things. With user-tracking you have a much better idea of who actually visits the site, especially when you need to track repeat visitors.

y6, I would like to look at what you came up with, although it sounds like the parsing problem might be an issue, as the last thing I want to do is slow down the page.
posted by cell divide at 11:47 AM on February 3, 2004

I'll zip it up and send it tonight. Might motivate me to actually finish it.

And keep in mind the parsing I'm talking about isn't going to be an issue unless you over at least 500K hits a month. I do it as a function call, so it's easy to turn on and off.
posted by y6y6y6 at 1:02 PM on February 3, 2004

A quick Google-ing turned up PHPOpenTracker, but I have no idea if it is any good.
You could also look at adapting freeware ad-serving solutions to the task.
posted by sad_otter at 1:12 PM on February 3, 2004

Now I'm confused. How are PHP and databases client-side technologies? Even if the function is embedded into individual pages, isn't it still running and recording on the server?
posted by jeffhoward at 2:37 PM on February 3, 2004

Yes. But the addition of some cookies and Javascript (both client-side) lets you grab some great data that you can't get from the log files.

Also......... I haven't mailed out the stats package yet. I started cleaning it up and got on a roll. I'll mail it out and link it on my website this weekend.
posted by y6y6y6 at 7:23 AM on February 6, 2004