Jump to:
| Project: | Web Links |
| Version: | 6.x-2.1 |
| Component: | Contrib: Blocks |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
I propose that click history be aged so that a popularity ranking takes into account that a link that used to be popular no longer is.
A simple way to do this is to have a configuration option specifying the period over which clicks are counted to assess popularity. E.g.: most popular in the past day, week (past 7 days, really), month (past 30 days, really), year (past 365 days), or lifetime (what we have now).
A more complex way would be to enable the admin to specify a weighting curve by assigning a % weight to past day, past week, past month, past year, and lifetime. Popularity is then not just total number of clicks but the following: day_clicks * day_weight + week_clicks * week_weight / 7 + month_clicks * month_weight / 30 + year_clicks * year_weight / 365 + lifetime_clicks * lifetime_weight / (days since first click). I suppose for completeness one could add a past quarter option and (if optimistic) past decade and past century.
JB
Comments
#1
Well, that would be a good way to weight them, but we don't have that information. The only thing we have is the last date it was clicked on. We don't keep information on previous clicks and I don't see enough value in keeping all that data (which would require another table).
Robert: any thoughts?
#2
There must also at least be a counter for total clicks, right? Or, is there another way to assess "popularity" than click count?
#3
Yes, we do keep total clicks (for the revision) and last click date, but not what you need in your example algorithm. I don't know what might be available in the access_log if it is enabled and of sufficiently long duration, but that's a lot of data to process.
#4
I think you have to run a cron job daily and store/insert the number of clicks made that day in a database table with three columns: link, # clicks, day. You then get the number of clicks for the past week/month/whatever by pulling the data from the database.
#5
We have little desire to create any more tables or add to the Cron processing for this.
I will leave this up to Robert as to whether or not he wants this.
#6
No further updates on how this might be accomplished. We do revisit "won't fix" on occasion to see if we change our mind.
#7
#8
Hmm, check out http://drupal.org/project/radioactivity