Talk:Logging stage2
Please dump your thoughts here about additional things Moodle could be logging In a future new log system.
See also: Forum on analytics and reporting
From Clive Holtham City University following Moodle Research Conference Session 5 on Learning Analytics
We need to capture every link clicked in Moodle. A click from a URL simply embedded in a page does not create an entry in Moodle Logs (for us anyway). So we have to create a hidden section with the URL's in their own right, which is captured by the logs, then point to that URL from the place where the original embedding was situated. It would be useful to have a table which reconciles the differing number of hits shown through different Moodle log reports.
Again for us anyway, activity in OUwiki is not showing up in the Moodle logs; OU told us today that the activity should show up.
It was interesting to hear about the privacy legislation in Germany and Switzerland which limit what personal detail can be shown out of Moodle. Even as in the UK where we can legally use the detail, I have reservations about displaying (for example) the time of day a click was made. So there needs to be a series of filters which will deliberately limit data which can be retrieved by an average user, whether for legal or other reasons.
When I create the most detailed actvity spreadsheet, there is very little filtering possible. I would, for example,, like to include only students in the main spreadsheet (exclude faculty and administrators).
On a separate issue, I have been concerned about the grown of use of Google Analytics, not least for data protection reasons, which in part derives from the very limited features and unattractive interface of Moodle logs/reports. GA cannot replace Moodle logs/reports; it can of course provide additional data than currently available. I would like an upgraded Moodle logs/reports to replace the need to use GA. Certainly the emphasis needs to shift to presenting the Moodle reports with a look and feel much more like Google Analytics.
One key point that came through at the conference is that the needs of individual teachers, management broadly defined, and students are all quite different. I would be anxious to see that whatever happens, the priority order for improvement should be Teachers Students Management The need for teachers and students does not relate to Big Data. It actually relates to Small Data- how can we gain insights from the fewest pieces of data. The very term Learning Analytics is associated with the Big Data movement, which is primarily related to managerial rather than teacher concerns.
From Alice Kaerast at Webanywhere:
I would very much like a nice control panel controlling what is logged. This is particularly important for sites with heavy traffic where I probably don't care about most activity, and systems like Google Analytics or Kissmetrics are better for this amount of traffic. I'd also like the ability to control where logs are saved, for very heavy traffic sites I might prefer to have logs streamed to somewhere other than my main database. Syslog would be great, a second external database would be nice, a message queueing system might be useful, a third-party cloud based logging system could be good - why not create an api to control where logs are sent?
From Mark van Hoek at University of Victoria:
The current logs are at once way too much info, yet not enough useful info. What I'd like: Log every click, every pageview, every submission, every delete, every redirect, for every user (including admins). Context info should include: course, module, url, request type, Moodle's response, response level (error, info, warning, fatal). Add powerful filtering on top: by user, by group, by course, by time period, by action (add, update, delete, click, submit, etc). Enhance ability to filter and follow a single users actions. Add an analytics UI layer for higher-level queries, with a UI to build new reports. Something like PiWik may be leveraged here.
Don't rely on module authors to write logging code -- centralize the logging (e.g. via a central controller class + output handler). Add better ability to delete log records and archive them out of the DB and into a file. The export be optionally excel or should comply to some standard that sysadmins can parse (e.g. log4java, syslog, ...), and that there are standard log readers/handlers for.
Relational integrity + ACID (consistency) is not so important for logging, and reading is less time-sensitive than writing -- this opens options to prevent logging from being a performance issue (e.g. NoSQL, write to a file, async logging, logging queues, whatever).
+1 for Alice's request for controlling what is logged.
