Time Tracking Inconsistencies in Docebo

Hi @jocie.nylec, I would suggest using the session lifetime. that would time out the users, so they would need to be active. However this does have some issues with tracking. Verbiage would need to go out to the users about the session time out.

generic name wrote:

Hi @jocie.nylec, I would suggest using the session lifetime. that would time out the users, so they would need to be active. However this does have some issues with tracking. Verbiage would need to go out to the users about the session time out.

 

 

agree with @generic name 

in addition, you can use the “average time to complete course” option for eLearning when reporting on user completions. The CEU’s are better used to track Continuing education credits as it is not formatted to track time. Please note that some reports show time in SECONDS (strange but true) so you’ll need to apply some formulas, etc. to track time in hours, minutes and seconds.

@generic name  - Thank you for the Session lifetime note because that page actually includes another “issue” that people have raised.  I also notice that our Session lifetime is set to 10,800 seconds so that leads me to believe we might also be able to resolve this with some changes to the course in question.  Thank you so much!

@lrnlab - on the “average time”, have you had any complaints from users about needing to accommodate for, let’s say, the fact they read slower or anything like that?  That’s what I was thinking about using but wasn’t sure if I might be walking into an “it’s not fair” conversation...

@jocie.nylec none at all...it may depend on what the courses are for. I usually try and keep the meaning of “average time to complete course” separate from tracking “CEUs”. Generally approved CEUs have been reviewed by a 3rd party that agree to the overall value of units for a course regardless of how much time it may take a single individual to complete it compared to another. This keeps the values consistent for all users. You may want to use both in your case and be more strict about the CEUs.

Hi @jocie.nylec, it’s so cool that your organization is prioritizing training in such a radical way by incorporating it into quarterly bonus objectives. I love that!

I agree with all of the feedback that has been shared here. @generic name and @lrnlab shared some really helpful tips re: time tracking. I don’t have much to add to this advice about how to most efficiently and accurately track training time in Docebo. I do, however, have a few questions for you about the decision to use training hours as a core KPI for quarterly bonuses.

1. What was the primary reason that drove using training hours as a core KPI for compensation?
2. Are you measuring any other training KPIs in addition to training hours? If so, what are they?
3. If you aren’t measuring any other KPIs, did your organization consider using alternatives to training hours?

@lrnlab brought up a good point that different individuals may learn at different speeds and may have different preferred methods of learning. My concern would be that compensating solely based on training hours (specifically for E-Learning and not ILT) might reward the wrong behavior or punish some learners (like those who learn more quickly) unfairly by requiring them to take more training than those who learn more slowly. Is this something you’ve considered? I look forward to learning more from you!

Jumping in here as we actually use the Time Tracking functionality for accreditation purposes. We would actually prefer if the session timeout window could be shorter (and set based on level of user - users vs power users) - partially to accommodate for this issue where its a more accurate reflection of how long a user is spending in the course and is ACTIVE but also to allow for the different types of users to be restricted based on the types of activities they might be completing in the system. 

We recently spent a painful amount of time, including providing files for the Docebo support team, troubleshooting why so many of our learners had accumulated hundreds of inflated training material hours. The bottom line is that it is not currently possible to rely on these time spent figures for any accuracy.

Explanation from Docebo support:

Our development team has investigated and confirmed that the user had a browser tab with the SCORM open in the background, which continued running the timer. Each time the user logged in, the session resumed and ran for up to 8 hours at a time.
 
Here’s how the SCORM player currently functions:

• When a session starts, a record is created in the database with the same start and end time.
• Every five minutes, a keep-alive function extends the session.
• The keep-alive stops renewing after 8 hours, updating the end time.
• When the user logs in again, a new session is created—including in any idle tabs—resulting in additional recorded time spent on the training material.

 While an update to this functionality is not currently on the roadmap, our team has been discussing potential improvements in this area.
 
If you'd like to submit a feature request as it's not officially on our roadmap or suggest ways to help us improve, this can be done by visiting our Community Ideas Portal. 

I challenged this, believing that the ‘Session lifetime’ setting in the Advanced options should prevent this by logging the user out of the session. It doesn’t.

From Docebo support:

Our development team provided an update regarding the "Session Lifetime" setting. They confirmed that it does not time out the session as expected because the SCORM content runs inside an iframe. As a result, the LMS cannot detect learner interactions to renew the session.
 
To address this, a "Keep Alive" mechanism was implemented within the Course Player to prevent session timeouts and ensure tracking data is not lost.

I hope ths helps save somebody the truckload of hours that it cost me.

We have this same challenge and our accreditation requires that we track time in course. So, this has been causing some serious angst. 

Curious if this enhancement on the product roadmap will solve this issue - https://portal.productboard.com/npwrnbvnfrya8zlkldjheykv/c/164-forcing-user-logout. 

So many systems show you when you’re about to be logged out. Wondering if that couldn’t be incorporated?

Ideally, we’d have separate session maximums based on being a user or power user… dream world.