Moodle ActiveProLearn Documentation

The Use Stats block can be added anywhere in Moodle, provided you have the standard ability to add the block (> M2.4).

Turn Moodle in edit mode, and use the 'Add block' menu. Then choose the block “Use Stats (User time tracking)”

The Use Stats block, in standard mode, will only show you your own statistics.

In administrator mode, you can view the statistics of other users.

From version 2016020600 upwards, a greater flexibility is achieved using additional settings:

Some information on the block settings in central administration

All info in the technical doc

Since block_use_stats | fromwhen

Compilation period Possible values: 5, 15, 30, 60, 90, 180, 365 Warning if value entered in free entry field not listed, this will take into account 5 days, ie the default value.

Filter times below (formerly session)

block_use_stats | filterdisplayunder Value in second of the time below which the time is taken into account but not displayed in the usestat block: If a session lasts less than one minute (60 seconds), it is considered as not significant, and it does not appear not in the block.

Reference time to display

block_use_stats | displayactivitytimeonly The block displays either the time spent in activities or the time spent in the History Analyzer Settings class.

Threshold

Credit time assigned by default to the work session in case of accidental termination of session. (Or without going through the menu “Disconnect”)

Example: Set to 60 min: If a learner has a period of inactivity in a session longer than 60 min, ie 1h, it is considered disconnected.

Overtime credit on the last ping

ping block_use_stats | lastpingcredit Additional credit time in minutes in case of no formal logout trace 15mn is the default

1. Compilation default period: Use Stats will calculate time results for each display. In order NOT to load too heavily moodle whith this block, the compilation period defaults to 90 days. You may set it lower for heavy duty moodle sites with a lot of activity, and let some users push it up during a working session if desired. Note that all times refered to in display are calculated within the compilation period. This setting tells how many days back from the current date the compilation will seek.

2. Hide duration lower to: below this amount of time (in secs), the corresponding courses will not be shown in the display. This may help to focus on most important items. A little warning signal reminds you that everything is not displayed, so do not try to sum all times and get the total match !.

3. Display extra time: If enabled, time spent in site, in general screesn, or any other screen outside the scope of any course will be summed to the displayed time, otherwise the displayed time calculates only durations that can be directly be bound to the courses context (or subcontexts).

4. Official time: there is a lot of variability in the way schools and institutions will agree the time measurement, so you may choose here which time will be the official reference for the display:

1. Full course time: Will sum all time spent in course global screens and all subcontexts.
2. Activities: This choice will only count time that is spent in real activity modules of Moodle. This implies the course design must take care of no diverting out of calculation scope some actions of the users.

5. Session break detection threshold: This time tells from which gap size the log analyser will decide the user is very likely to have deconnected from the current working session. the default is 10 minutes (600 seconds). This threshold may have strong impact on the time calculation by adding time bonus to the user track when he disconnects. It is significantly related to the course content publication strategy. If your content is cut into small pieces needing the user browse often to reload material, then it can be reduced, and the “implicit disconnection bias” will be reduced either. If conversely, you post big documents or asking for long non interactive working sequences, you may raise the value, but also will you raise the interpretation error of the implicit disconnections.

6. Time bonus for disconnection: When an implicit disconnection is detected, the log analyser cannot know how much time the student might have worked on the last opened page. cutting the session on the last log abruptly giving no working time gap could be harsh for some students, f.e. if some resources such as video do not track anything. This parameter lets give an extra standard credit time in such events. Experience shows that this credit time granted to students should not be too generous, or the calculated time might present important and unrealistic overestimations of the real student's work. In general, the workable range for this value is around 10 minutes.

the cubing feature of the use_stars block is a provisional feature for those who want use data mining and ETL queries on a Moodle. External reporting suites are efficient if the source of the data can be sufficiently qualified. More over, reports are clearer when the data is qualified using readable labels and values, rather than internal ids or cryptic codes. qualifying the data at query time can lead to a huge processor and memory duty and dramatically lowers moodle performances.

Thus this feature will prepare the qualification of the logs of Moodle on the fly, making this process continous and low overhead. Logs information can be enriched with up to 6 cubing dimensions where you can feed a course or category name, user name or any significant information for reports. this will complete the standard log table that only stores internal numeric identifiers.

Warning! activating the cubing feature must be done to comply with a REAL NEED of data analysis. the amount of data stored into the complementary log table of use stats can grow a lot and should be anticipated in server storage size.

7. Enabling data cubing: When enabling this feature, a Moodle programmed task will track and follow any new log entries to add qualifier to each record. Be carefull if you enable this feature on an old site that already has a ton of old logs, as the task will try to requalify the entire log base. (See RoadMap)

8. Qualifier definition: Up to 6 qualifiers can be added to the standard log record. Each will be fed with a custimized query you can define. A getch query will be played for each record and each qualifier to feed the additional log table (mdl_block_use_stats_log).

for storage optimization reasons, qualifiers have beed restricted to a defined length:

1. 20 chars length for the 3 former
2. 128 chars length for the latter

A valid cubing query MUST be written so it gives back a single value. some usefull placeholders will be replaced before query execution:

• <%%LOGID%%> : The corresponding log record id
• <%%USERID%%> : the id of the log record owner userid
• <%%%%COURSEID%%> : the course identifier as context of this log
• <%%CMID%%> : The course module id if the log is an activity logging record.

9. Last cubing date reached: the qualification process is differential: It will only aggregate new records from the last processing date. You may know through this field the last occurrence of a qualification runtime, and may change it to run back the qualification from a given date.

This feature has been removed.

Back to the technical guide index