How to track quiz results in SCORM

Can you track quiz results in SCORM?

Yes. To track quiz results in SCORM past the final score, the content writes one entry per question to the cmi.interactions array: an id, the question type, the learner's answer, the correct pattern, and the result. SCORM 1.2 makes that array optional and write-only, so plenty of platforms accept the writes and never show them again.

What SCORM reports by default is a summary. The LMS receives a score, a completion status, and — in SCORM 2004 — a separate pass/fail. None of that says which questions the learner got wrong, what they answered, or how long they spent. That detail exists only if the content chose to write it, and only survives if the platform chose to keep it. Those are two separate decisions and neither is the standard's.

The interactions data model

Both SCORM versions define the same shape: an array of interactions, indexed from zero, written one element at a time. The content appends an interaction by writing to the next free index — the current value of cmi.interactions._count — and filling in whichever elements it has. A single scored question looks like this at the runtime:

SetValue("cmi.interactions.0.id", "q1-signage")                  = "true"
SetValue("cmi.interactions.0.type", "choice")                    = "true"
SetValue("cmi.interactions.0.student_response", "b")             = "true"
SetValue("cmi.interactions.0.correct_responses.0.pattern", "c")  = "true"
SetValue("cmi.interactions.0.result", "wrong")                   = "true"
SetValue("cmi.interactions.0.weighting", "1")                    = "true"
Commit("")                                                       = "true"

The element names are not identical across versions, and the mismatches are a common source of rejected writes when a course built for one version is repackaged for the other.

Note the last two rows especially. A 1.2 course that writes incorrect instead of wrong, or an ISO duration into latency, is writing an invalid value for that version, and a strict LMS will reject it while a lenient one stores nonsense.

Why do SCORM 1.2 interactions vanish?

Two properties of the 1.2 data model explain almost every case.

They are optional for the LMS. SCORM 1.2 splits the data model into elements an LMS must support and elements it may support; interactions are in the second group. A platform that never implemented them answers the write with a not-implemented error (code 401) and carries on. Nothing visible breaks. The learner finishes, the score arrives, and the per-question data was discarded at the moment it was written.

They are write-only for the content. Even where the LMS does store them, the course cannot read them back: a GetValue on any interaction element returns an empty string and sets a write-only error. So the content has no way to confirm its own data landed, and it cannot use interactions to rebuild a partially finished quiz on resume — that state has to live in cmi.suspend_data, inside the 4,096-character cap that SCORM 1.2 imposes.

There is a third failure that is not the standard's fault at all: storing is not the same as surfacing. Several platforms persist interactions in the attempt record perfectly well and simply have no built-in report that shows them, so the data is reachable only through a raw export or a database query. A write that returns true tells you nothing about whether a human will ever see the answer.

SCORM 2004 interactions and their limits

SCORM 2004 fixes both structural problems. Interactions become read/write, so the content can count what it has written and verify it. A description element carries the question text, which means an export is readable without a separate key mapping q1-signage back to an actual question. The type and result vocabularies are tightened, and timings use ISO 8601 rather than the 1.2 time formats.

Three limits remain, and they catch people out:

• Interactions never contribute to the score. cmi.score.scaled is whatever the content writes, full stop. No LMS derives a grade by counting correct interactions. If the gradebook figure is wrong, the score write is the thing to inspect, not the interaction list — the mechanics are in why a SCORM score does not reach the LMS.
• The array has a ceiling. SCORM 2004 sets a smallest permitted maximum of 250 interactions per attempt. An LMS is free to store more, but it is not obliged to, so a large item bank recorded question by question can run past what the platform guarantees to keep.
• Correct-response patterns are type-specific and strict. The pattern grammar for a matching question is not the grammar for fill-in or numeric. Getting it wrong produces a data-type error on that one write while the rest of the interaction stores fine, leaving an entry with a learner response and no answer key.

If per-question reporting is the reason you are weighing versions at all, that consideration on its own points at 2004 — the wider trade-off is in which SCORM version to use.

When you need xAPI instead

Interactions are a fixed-shape array attached to one attempt, in one course, in one LMS. The model runs out when you need something outside that box: every attempt at every question rather than the last one, activity that is not a question at all (a video rewatched, a branch taken, a step performed in a simulator), or data that outlives the course's life in that platform.

xAPI drops the constraint by dropping the LMS. Content sends statements — an actor, a verb, an object, and a result carrying score, success and the learner's response — to a learning record store, which is a queryable database rather than a gradebook row. One statement per question, retained independently of any course. The anatomy of those statements is covered in how an xAPI statement is structured.

The obvious objection is that xAPI has no package, so an LMS cannot import or launch it. That is what cmi5 is for: cmi5 is a launchable package the LMS understands, and the content inside it sends xAPI statements to an LRS. The LMS gets its launch and completion; the LRS gets the per-question detail. It is the usual answer when compliance reporting must stay in the LMS but the quiz analysis has to live somewhere the LMS cannot reach.

Verifying what the LMS kept

A successful write is not evidence of a stored answer, and a stored answer is not evidence of a report. Check all three levels, in order, once per destination platform:

1. Did the write succeed? Call GetLastError immediately after each interaction SetValue on the target platform and read the runtime log. A not-implemented error on the very first one means every interaction in the course is going nowhere, and you have your answer in ten seconds.
2. Did the array grow? On SCORM 2004, read cmi.interactions._count back after the quiz and compare it with the number of questions written. On 1.2 you cannot — which is precisely why 1.2 always needs the third check.
3. Can a human see it? Complete an attempt as a test learner, then go into the LMS and look: the attempt detail, the question-level or interactions report if the platform has one, and the raw export. If the response is not there, it does not exist for reporting purposes no matter how clean the log was.

Record the result against the platform, not the course. "Does this LMS keep interactions, and can anyone read them" is a stable fact about a destination that decides, before anyone builds content, whether a quiz needs SCORM 2004, cmi5, or an xAPI side-channel. Discovering it after the first compliance report is due is the expensive way round.

Where SCORM Central fits

SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.