SCORM Tracking Briefly Explained

Published: August 20, 2013
At ABR, clients often ask us to design and develop e-learning courses that will track and/or store their users’ progress and completion. A learning management system (LMS) that supports SCORM 1.2 allows a developer using programming tools such as Lectora, Articulate, Flash, or HTML/JavaScript to do just that.

The information is sent to and retrieved from the LMS using specific functions and parameters. In programs like Lectora and Articulate, these calls are hidden from the developer and are built into the published files. For other development tools like Flash and HTML/JS, the developer must write his/her own routines to call these functions and parse the information to and from the LMS, or use any of the number of libraries available that have the SCORM functions already developed and ready for use.

In this article, I’ll describe the tracking variables that every LMS must support in order to be compliant with SCORM 1.2. These, not coincidentally, are the typical items that we track in courses designed for LMSs.

Typically the SCORM variable called cmi.core.lesson_location is used to store a string of up to 255 characters that a developer can use to recall and return users to the last page that they were on when they left the course. Most of the time we use a naming system like “screen01-01” or “page01-03.” Each dash would represent another subsection to the previous number.

As you can see, since you have 255 characters available and most of the time the actual location takes far fewer, developers sometimes utilize this extra space to store information about menu states, interactions completed, or other items used in the course.

There is another variable discussed later that some developers use to store the bookmarking location instead of using this variable. However, the cmi.core.lesson_location variable was designed for bookmarking a user’s location within a course.

Course Status
SCORM 1.2, like AICC, has only a single variable to inform the LMS and course of the user’s current status within the course. The variable is called cmi.core.lesson_status. Unlike the cmi.core.lesson_location variable used to store a user’s location, cmi.core.lesson_status can only have specific values: incomplete, completed, passed, failed, or unknown.

The first time a user launches a course, the developer must update the value of the cmi.core.lesson_status from “unknown” to “incomplete.” After that, it will be up to the course owner and the developer to determine how they show completion. They can either set the value to “passed” or “completed,” but not both. This is a limitation of SCORM 1.2 and was addressed in SCORM 2004 (aka SCORM 1.3 or 1.4). In SCORM 2004, the values of completion and success were separated so that you could show that a user “completed” all of the content but “failed” the final assessment. In SCORM 1.2, however, you have to choose between the two. Most LMS administrators will give the developer specific instructions on what values to use when completing a course. Standard value pairs include:


The first two combinations allow the course to remain in a user’s enrollments in the LMS until he or she has successfully completed or passed the course. Failing the assessment would just keep his or her current status in the course as “incomplete.” The last combination will move the course into the user’s transcript and require him or her to re-register for the course to be able to take it again. This will vary between LMSs—check with your administrator for information about your particular LMS.

In SCORM 1.2, the cmi.core.score.raw variable stores a user’s assessment score.

The score value is usually a value between 0 and 100 that would represent the user’s percent score for the assessment, but you can use any number for the score.

Setting a score can be a bit tricky since it will activate some automatic responses on the LMS side and could possibly overwrite your cmi.core.lesson_status variable from the course. You should take care and work with your LMS administrator to determine how your LMS will handle the scores and setting status changes.

cmi.core.session_time and cmi.core.total_time
Each course must also track the amount of time a user spends within the course. The developer then submits this time using the variable cmi.core.session_time. The LMS takes this value and adds it to the previous times the user has accessed the course and calculates the total time. A developer can obtain this total time by accessing the variable cmi.core.total_time. This can be used for limiting the amount of time a user can spend within a particular course.

Additional Variables
Suspend Data
The catch-all variable, suspend data, is a large string that can store up to 4000 characters. This information is usually only for the developer of the course and the information in it normally only makes sense for the course that put it there. This is where a developer can store a state of the entire course so that it can be reset when a user returns. Like the cmi.core.lesson_location variable, there are some restrictions on using certain characters and you do have a limit, though 4000 characters is a lot.

A common method to store information is to use a combination of key/value pairs separated by a delimiting character. For example:

menu=0,0,0,1,1,1,0|notes=nothing to type yet|path=intermediate

Or sometimes with a lot of data, you might find it useful to use XML converted to a string. This allows for rapid re-parsing of the information when the user returns because you can easily retrieve the entire string, convert it back into XML, and then use XML data routines to retrieve course-specific information.

This variable allows a developer to store pretty much anything for a course and almost any information the client requests to have stored. The big limitation with this variable is that it is normally not accessible on the LMS side for reporting purposes, since most systems assume it to be course specific.

This list of required tracking variables will allow you to track most data within your course. There are also a handful of optional variables, such as those that track assessment question interactions individually, but support for these varies across different LMSs.

If you’re new to SCORM 1.2 as a developer or you’re curious for more details, here are some additional resources to explore: