SCORM Analytics Beyond Completion: What You Can and Can’t Track

"How many people completed it?" is the question SCORM answers best — and for a lot of teams it is the only question they ever ask. But the SCORM data model exposes more than a single pass/fail flag, and knowing what is and is not available changes what you can promise stakeholders. Here is an honest map of SCORM analytics: what you genuinely get, what you do not, and where xAPI takes over.

What SCORM tracks: the cmi data model

Everything SCORM reports flows through a defined set of data elements, the cmi model. A course reads and writes these, and the LMS stores them. The core elements every SCORM course can use:

• Completion / lesson status — did the learner finish, and (in 1.2) did they pass or fail. This is the headline number.
• Score — a raw score, and the min/max range it sits in. The bread-and-butter of quiz reporting.
• Total time — how long the learner spent in the SCO across sessions.
• Location / bookmark — where the learner was, so they can resume.
• Suspend data — a single string the course uses to remember its internal state between sessions.
• Interactions — a structured record of individual question responses, if the course chooses to report them.

The underused gold mine: interactions

The most overlooked part of SCORM analytics is interactions. When enabled, a course can report each question individually: the question identifier, the type (multiple choice, true/false, fill-in, matching), the learner’s response, the correct response, whether they got it right, and sometimes how long they took. Aggregate that across learners and you can see which questions everyone misses — a signal that the content is unclear or the question is bad — rather than just an overall pass rate.

The limits are real, though. SCORM 1.2 interaction reporting is thinner than 2004’s, some LMSes store interaction data but expose it poorly in their reports, and whether you get any of this at all depends on the course author having turned it on at publish time. If it was not enabled, the data simply was not sent and cannot be reconstructed after the fact.

Where SCORM 2004 reports more than 1.2

• Separate completion and success — 2004 splits "did they finish it" from "did they pass it" into two fields, where 1.2 collapses both into one status.
• Richer interactions — 2004’s interaction model captures more detail and is more consistently specified.
• Much larger suspend data — roughly 64,000 characters versus 1.2’s 4,096, so complex courses can store more state without losing it.
• Objectives — 2004 has a more developed model for tracking progress against multiple learning objectives within a SCO.

That said, more capability does not mean more support. Plenty of LMSes implement the richer 2004 reporting partially, so test what your specific platform actually surfaces before you build a dashboard on it.

A word on suspend_data: it is state, not analytics

People sometimes hope to mine suspend_data for insight. Resist that. Suspend data is an opaque blob the course uses to restore itself — an internal serialization format, not a documented analytics feed. Its structure is private to the authoring tool, it is not meant to be human-readable, and it can change between versions. Treat it as the course’s private memory, not as data you report on.

What SCORM cannot tell you

• Anything outside the SCO session — what the learner did before, after, or in another system.
• Fine-grained engagement by default — which slides they lingered on, what they rewatched, where they dropped off, unless the author explicitly built that into interactions.
• Anything off the LMS — a mobile app, a simulation, a classroom session, a video watched elsewhere. SCORM lives inside the browser, inside the LMS.
• Learning that happens on the job, after the course is done.

Where xAPI picks up the slack

When the question is "what did this person learn and do across all our systems," SCORM runs out of room and xAPI begins. xAPI records learning as statements — actor, verb, object — sent to a Learning Record Store from anywhere: apps, simulations, classroom check-ins, on-the-job tools. It is built for exactly the cross-system, beyond-the-browser tracking SCORM was never designed for. The trade-off is that xAPI gives you freedom without the built-in LMS governance SCORM has, which is the gap cmi5 was created to fill.

Practical takeaways

1. For "did they complete it and pass," SCORM is more than enough — and 1.2 is usually sufficient.
2. If you want per-question insight, confirm the course was published with interaction reporting enabled; you cannot add it after the fact without the source.
3. If question-level analytics matter to you, lean toward SCORM 2004 and verify your LMS actually surfaces interactions.
4. Never report on suspend_data — it is state, not analytics.
5. If you need to track learning beyond the LMS browser session, that is an xAPI conversation, not a SCORM one.

SCORM can tell you far more than "complete / incomplete" — but only what the course author chose to report. The analytics ceiling is set at publish time.

Knowing what your package actually reports

ScormEdit reads your published package and tells you what it is set up to track — which SCORM version it targets, whether it reports interactions, and where it sits relative to the suspend-data limit — all in the browser, from the .zip, with no source file. You find out what analytics you really have before you promise a stakeholder a dashboard the course can never feed.