JavaScript vs. PHP
I think Drupal is well positioned to be a very useful analysis tool as it serves pages and tracks those serves directly. In effect, Drupal can log everything that an Apache log can hold.
Additionally, I would like to see Drupal capture information about users that cannot be determined from the HTTP request information. Some examples include user connection speed, screen resolution, plugins, etc. I believe this will have to be done in JavaScript.
I am starting this thread to collect ideas on what can be found in and tracked in PHP and what should be tracked via JavaScript.
To begin with, please see this patch to Xstatistics: http://drupal.org/node/70941
That patch includes a JavaScript file that collects the following data and reports it via Drupal's AJAX handlers: java, os, screen res ,lang, director, flash, pdf , quicktime ,realplayer , wma, and connection speed.
Are any of these items better handled by PHP?
What else can we add to this list?
What is the best way to display this data, once it's been captured?
There is a new stats package
There is a new stats package out that actually tracks user mouse position, and then can use this data to recreate user paths through an individual page!
I think some great options for display would include charting, mapping, and exporting to excel spreadsheet.
What is the name of the stats package?
Please post.
To seek, to strive, to find, and not to yield
< a href="http://www.youtube.com/watch?v=COg-orloxlY">Support the Drupal installer, Install profiles, and module install forms
<a href="http://ia310107.us.archive.org/1/items/organicgroups_og2list/dru
I knew someone would ask.
I knew someone would ask beccause I had lost the link. Finally found it - http://clicktale.com/
It's a hosted subscription package, and I believe it is quite expensive. I guess it is trying to be a bit like eyetracking, except slightly less useful as it uses mouse position rather than eye position. It probably wouldnt give you a great idea what the user was doing when they werent using the mouse, but it would be great for following click trails etc.
There are a few more
There are a few more products (referred to as Click Density or Heat Maps) that are doing this as well. I remembered seeing an open source version and just found it again here:
http://sourceforge.net/projects/clickmaps
and more info on it here:
http://blog.corunet.com/english/the-definitive-heatmap
Chris
ALIAN DESIGN
That's cool stuff
Thanks for posting.
Those are going to be hard on the average $5/month hosting account.
I work for a managed Drupal hosting company. I wonder if we can trick up our servers like that.
I think for most people, a managed version is going to be all they can handle...
After scanning the blog article, I wonder why all the clicks can't be stored in one object and then be sent in a single object?
I just posted a similar question to the jQuery mailing list. I wonder what they'll have to say....
-M
JS Statistics Storage?
Maybe overall statistics should be stored and made available in a XML format that may be periodically retrieved from other sites.
I don't know if that's possible, but Firefox extensions become more and more important. Are they readable by JavaScript?
Daniel F. Kudwien
unleashed mind
Javascript vs PHP for stats
You can get a lot of information from PHP alone, and that should be encouraged. Although it increases the server load, it helps to keep the page size down. The smaller the page size the lower the single page view rate. And we all want people to stay for more than one page.
That being said, Javascript can be used to get information such as
Time Zone
Users default home page
Browsers Height/Width
Color Depth
Monitor Resolution
Plugins
Java/JavaScript enabled and versions
Connection speed
mouse movement/click tracking
You can use PHP to get almost everything else
Page views
Referrers
Visitors
Visits
File Downloads
Browser type and version
Operating systems
Geo IP Segmentation(with 3rd party utility)
This may not sound like much but when you start combining it you can get all sorts of pathing and commerce information. Although 13% of your users have 800x600 screen res, 80% of them live in Florida, browse with IE 5 running on windows 95, and therefor probably don't want to read your blog about Asymmetric Routing on Multi-Homed Servers.
Matching stats
I think you're very much correct on this point: PHP for everything it can, JS for anything else.
One nice thing about drupal is that it serves cached pages from a PHP instance. That means we can track PHP based stats on cached loads, not just fresh pages.
The one problem I see with splitting the collection between php and JS is the ability to correlate the two. If person A loads a page and then sends back some info via AJAX and Person B loads a page and sends back the JS data. How do we connect person a's PHP data with his JS data? What if person B got a cached page? We can inject any tokens are anything, so how do we correlate her JS data?
This are not deal breakers, but they are interesting questions to attempt to solve....
-M
Matching stats with tracking tokens
Normally visitors are assigned a unique id that is used to pull all the data together. If we generate a UID with php, and place that id in the JS tracking request. Ideally we would use a cookie and/or login to keep track of visitors, the UID would keep track of the visit, and allow linking of all the data collected during that visit.
session_id
I think the best bet would be the session ID. Every logged in user must have a session key. I'm willing to believe most anonymous users allow cookies, and therefore would have a session key as well. Data could be tabulated once per session, minimizing the number of redundant data points.
If XMLHttpGets passes along the session information, then it would be trivial to correlate the AJAX data with a PHP session ID.
-Mark
mf
I'm not convinced that non-PHP applications such as Plone, dotNetNuke, and Radiant will be impacted so much by the rise of Wordpress, Joomla, and Drupal. If you have the need to run an open source CMS on ASP.Net you are going to get behind the mojoPortal or dotNetNuke projects regardless of what is going on in the world of PHP-based CMS.