In part one of this series, we described a way of using SCORM modules on a regular website without losing the valuable data that is generated from an LMS. In this post: Part 2 of 6 will review a comparison of the data available from a typical SCORM module housed in an LMS compared to a simple website emitter.

A SCORM-compliant eLearning module can provide a range of useful data to help track learner progress and performance.

Common data points from a SCORM module housed in an LMS include:

  • Completion status (e.g. completed, incomplete)
  • Pass/fail status
  • Score (often both raw and scaled)
  • Time spent in the module
  • Progress through the course
  • Attempts (number of times the module has been launched)
  • Responses to quiz questions (in some cases, including correct/incorrect answers)

This data is typically reported back to a Learning Management System (LMS), allowing administrators to monitor engagement, identify trends, and support learners as needed.

OK, so how does our low-cost alternative stack up? Remarkably well. You can capture everything you’d expect from a SCORM module plus anything else you feel like adding. We typically support all of the events and verbs used by a learning record system, which gives you a huge amount of data if you want to know about almost every aspect of the learner’s journey.

If you use a simple data-emitter and an http: backend, just like an LMS, you can get more basic information and as much custom data as you want:

Data points from a website housed SCORM module with an emitter include:

  • Logon data (you need this is you user is no longer logging into an LMS)
    • Email
    • Name
    • Location, etc.
  • Completion status (e.g. completed, incomplete)
  • Pass/fail status
  • Score (often both raw and scaled)
  • Time spent in the module
  • Progress through the course
  • Attempts (number of times the module has been launched)
  • Responses to quiz questions (in some cases, including correct/incorrect answers)

And so on – in fact here’s the current information we can capture:

Events Verbs or Action
  • logon
  • logoff
  • viewed lesson
  • started lesson
  • completed lesson
  • opened resource
  • downloaded resource
  • read article
  • watched video
  • played simulation
  • attempted assessment
  • passed assessment
  • failed assessment
  • retook assessment
  • posted comment
  • submitted assignment
  • graded assignment
  • received feedback
  • asked question
  • answered question
  • bookmarked content
  • liked content
  • shared content
  • earned badge
  • achieved goal
  • reset password
  • updated profile
  • logged in
  • logged out
  • started
  • completed
  • attempted
  • passed
  • failed
  • interacted
  • viewed
  • opened
  • read
  • watched
  • submitted
  • commented
  • joined
  • left
  • asked
  • answered
  • bookmarked
  • liked
  • shared
  • downloaded
  • uploaded
  • achieved
  • earned
  • graded
  • received

Not a bad list huh? And think about having the opportunity to make easy to access, on demand training, that still provides a significant amount of valuable data about the user’s learning experience.

Ok you’re thinking – “What’s the catch –  how hard is it to do this?”

In the next part of the series, we will take a look at the basics of implementation, the considerations and any challenges you might face in choosing to use an API instead of an LMS.

Did you miss Part 1? You can find it here – “Why You Might Not Need an LMS After All”

Before You Go, A Quick Feedback Loop

I’ll practice what I preach:

  • Was this post useful to you?
  • Did the stories help clarify the message?
  • What parts felt unclear or too abstract?

Reply with your thoughts — or better yet, tell me one small change you made after looking at your own assessment data. Because when we listen, we learn. And when we learn, we create eLearning that actually changes behavior, not just knowledge.