Daily Usage statistics log

Posted by drupalshrek on September 27, 2010 at 12:04pm

Based on original post at: http://drupal.org/node/899896

I am interested in developing a module which records simple daily statistics, on things such as:

the number of profiles of each role type (per day)
the number of profiles which have been active in the last 24 hours/7 days/30 days (on a given day)

The first statistic would help me to keep track of the growth in different roles in the site.
The second statistic would help me to keep track of the real growth in usage (e.g. if "basic" users have grown from 100 to 500, that is one thing, but if the number of users in the last 24-hour users is steady at 50, then the site is not really growing).

I imagine a very simple table/database log format, which is, for example:

Date
StatType (e.g. "logins", "24_hour_activity", "role_editor")
Count

This would be added to daily from a CRON job.

Example table contents:

2009-09-25 "24-hour_activity" 5    // says that 5 users logged in on this date 
2009-09-26 "24-hour_activity" 27 
2009-09-27 "24-hour_activity" 15
2009-09-25 "30-day_activity" 500    // says that 500 users logged in during last 30 days 
2009-09-26 "30-day_activity" 527 
2009-09-27 "30-day_activity" 538
2009-09-25 "role_basic_member" 217  // There were 217 people with the basic member role on this date 
2009-09-26 "role_basic_member" 221 
2009-09-27 "role_basic_member" 222 
2009-09-25 "role_admins" 3   // There were 3 people with the admin role on this date 
2009-09-26 "role_admins" 3
2009-09-27 "role_admins" 4

I guess this table could be normalised more (i.e. have text like "role_basic_member" in a different table, and just have an id in this table.

My research shows that such a thing does not yet exist. If you know differently, please tell me!

I guess eventually it would be linked into show this information in a nice display, e.g. with http://drupal.org/project/charts

If not, do you have any suggestions to help in the design of such a module? In particular any suggestions on making such a module extensible (e.g. for people to easily add their own stat definitions) or usable by other modules (e.g. that plugged with this to give extra functionality)?

And do you have any statistics which you think you would like to see or find useful in such a module?

Thanks!

Comments

I allready started to work on

Posted by derhasi on September 27, 2010 at 2:16pm

I allready started to work on a similar module, with a more generic approach on http://drupal.org/project/stats. Unfortunately it is still in development - better to say it froze for the last months. Maybe you are interested in reviewing the module's concepts?

In your original post you mentioned http://drupal.org/project/quant, it seems to go in a similar direction, but haven't had a look on it.

Feedback

Posted by drupalshrek on September 28, 2010 at 12:14pm

Hi,

Thanks for your post; it's nice to see what nearby things are.

Although I'm sure your code is very promising, I will say that since it is not at all ready to be downloaded and installed via the Drupal system, and is therefore (I suppose) still a quite raw piece of code, I prefer to not use it.

It is, of course, also, simpler to develop my code directly rather than the overhead of merging with some else's code, so for the moment I don't see that what we are doing has enough overlap to make that extra effort worthwhile.

Perhaps if your code gets a bit further along I can refactor mine to use it later.

A few other general comments:

Upload your code to drupal.org as soon as you can, even if you mark it as a "dev" version; it makes things easier for people familiar with the Drupal system. I would have prefered to have downloaded your module from Drupal and tried to install it and have a proper look. As it was, it was more of a hassle to download it from the git system, which, although no doubt very good as a system, is still different from the Drupal one which all drupal folk are used to.
Your function stats_callback_default_storage() passes a parameter:

* @param $op * the operator can either be: * - 'load' to load data from the databse * - 'insert' to write new data to the database * - 'update' to write exisiting data to the database * - 'delete' data from the database

It is almost always better not to pass such parameters which all they do is control the flow within the function, but rather create a function for each type, e.g. stats_load(), stats_insert(), etc. It may seem more work, but it increases binding within the function (i.e. makes the function more "function" like) and reduces coupling (makes it more easily changed since it has one less parameter tying it to the outside world).
I notice with happiness that one of the things which Drupal 7 is doing in the API is replace some Drupal 6 functions with multiple functions which don't pass a control parameter.

Thanks for your reply. You

Posted by derhasi on October 8, 2010 at 4:00pm

Thanks for your reply. You are right, posting a -some sort of testable- version on drupal.org would help. I'm looking forward to do this this weekend.

Did you allready start some code? Maybe I could reduce my work to some "light" features, so we could start on a similar point.

module used for new d.o.

Posted by kyle_mathews on September 28, 2010 at 4:22pm

There's a statistics module that's being written to collect stats on the new d.o. that has a drush powered backend to collect and sort through data. It looked pretty promising the last time I stumbled across it. Can't remember now what it's called... hopefully someone else can remember.

Kyle Mathews