blocks:usestats:technique:settings

This is an old revision of the document!


Site wide configuration

Bloc Use Stats (User time tracking)

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

Block display settings

Ces réglages concernent ce qui est affiché dans l'espace du bloc lorsqu'il est inséré dans un écran de Moodle.

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.

Log analyser settings

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.

Réglage du tracking multidimensionnel

L'extraction multidimensionnelle est un dispositif optionnel destiné à faciliter l'extraction et l'exploitation des traces par des outils d'analyse de données tiers. Des outils externes de reporting permettent de générer des rapports d'autant plus utiles que les données sont qualifiées et peuvent être affichées de manière intelligibles par les exploitants. A cette fin, ce dispositif permet d'ajouter aux enregistrements d'historiques des “valeurs explicites”, comme par exmple le titre du'ne catégorie, le nom d'un cours, le login de l'utilisateur, là où les traces standard de Moodle n'enregistrent que des identifiants internes (id numériques).

Attention, l'activation du tracking multidimensionnel ne doit être faite que pour répondre à une vrai nécessité d'analyse. La masse de données générées par la qualification des historiques peut être très importante et diminuer les performances générales de Moodle pour des sites à fréquentation très élevée.

7. Activation du tracking multidimensionnel : Si vous activez cette option, une tache programmée de Moodle va qualifier tous les historiques entrants depuis le dernier passage du cron. Notez que l'activiation de cette fonction sur un site ayant déjà une forte antériorité d'exploitation peut conduire à une période très longue de rattrapage. (Voir RoadMap)

8. alimentation des qualifieurs : vous pouvez définir ici jusqu'à 6 qualifieurs qui seront renseignés par vos propres requêtes. Pour chaque historique traité, chaque requête de qualifieur exprimée sera exécutée et son résultat sera stocké dans la table multidimensionnelle.

Pour des raisons d'optimisation, les qualifieurs on été prédéfinis à une certaine longueur :

  1. 20 caractères pour les 3 premiers qualifieurs
  2. 128 caractères pour les 3 derniers qualifieurs

Pour être valide, la requête écrite ne doit retourner qu'une seule valeur unique par ligne. La requête peut contenir quelques emplacements de variables contextuelles qui seront remplacées avant l'exécution :

  • <%%LOGID%%> : L'identifiant numérique de l'historique
  • <%%USERID%%> : L'identifiant d'utilisateur assigné à cet historique
  • <%%%%COURSEID%%> : L'identifiant de cours contexte de cet historique
  • <%%CMID%%> : L'éventuel identifiant de module d'activité si cet historique est dans un contexte de module.

9. Dernière date de compilation multidimensionnelle : Le processus de qualification est différentiel : il ne calcule que les lignes nouvelles depuis son dernier passage. Lors de l'accès au formulaire de configuration, ce champ vous indiquera la date du dernier historique qualifié. vous pouvez alors altérer cette date pour demander à la tâche programmée de recommencer les calculs à la date voulue.

Tracking actif de session

Cette fonctionnalité vise à fournir une alternative à la détection heuristique de fin de sessions, dont on sait qu'elle introduit nécessairement un biais d'analyse qui peut être plus ou moins corrigé par des méthodes non exactes.

Le tracking actif va obliger la page de l'utilisateur d'envoyer un signal actif à Moodle tant qu'elle n'est pas refermée. La sécurisation des sessions par tracking “actif” ne présume pas de l'activité de l'utilisateur derrière son écran. De plus la version actuelle du tracking actif ne prend pas en compte des navigations parallèles du même utilisateur dans des fenêtres différentes.

10. Période d'émission du tracking actif : Par défaut l'émission est préréglée à 10 minutes (600 secondes).

11. Règle pour la fourniture de l'émetteur : Tous les utilisateurs de Moodle ne sont pas nécessairement concernés par le tracing. Afin d'optimiser les performances de fonctionnement de la plate-forme, il est souhaitable de ne restreindre l'obligation de suivi qu'aux utilisateurs concernés. Ce réglage permet de définir une règle discriminante pour inclure ou exclure certains types d'utilisateurs du tracking :

  • Activer pour tous les utilisateurs
  • Activer pour ceux qui respectent la règle
  • Activer SAUF pour ceux qui respectent la règle

12. Méthode : La méthode pour l'application de la règle. vous pouvez établir une règle sur “capacité” (la règle est accomplie si la capacité est disponible sur le contexte système), ou sur la présence d'une valuer 'vraie' (non vide ou non nulle) d'un champ de profil.

13. Item de contrôle : La capacité, ou la désignation du champ de profil sur lequel la règle s'appuie.

Revenir à l'index du guide technique

blocks/usestats/technique/settings.1497278667.txt.gz · Last modified: 2024/04/04 15:50 (external edit)