Learner Records & Reporting

Registrations and Attempts

A registration is a learner against a package. An attempt is one run at it.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

The registration

Holds the current position: status, completion status, success status, raw and scaled scores with their minimum and maximum, progress measure, attempt number, total time, where the learner got to, their suspend data, and the entry and exit modes.

It is the answer to "how is this person doing" — one row, current.

The attempts

Each attempt records its own number, status, completion and success, scores and session time, with a start and end. So a learner who failed twice and passed on the third go has three attempt rows and a registration showing a pass.

Why both exist

Because the questions are different. "Are they compliant" is the registration. "How hard did they find it" is the attempts, and a course where most people pass on the third attempt is a course with a problem.

Lesson location and suspend data

Where the learner got to and the content’s own bookmark. These are what make resuming work, and they are the first things to look at when somebody says a course keeps restarting.

Empty suspend data on a package that should resume means the content is not saving its position.

Attempt count is a quality signal

Look at the distribution, not the average. Most people passing first time with a few taking two attempts is healthy. Most people taking three is a badly written assessment, ambiguous questions, or content that does not teach what is tested.

When a learner disputes a result

Go to the attempt, not the registration. It shows what happened on that specific run — the score, the time, when it started and ended — which usually resolves the question immediately.

If the dispute is about a specific question, the interaction records go further still.

Zero-time completions are worth checking

An attempt completed in seconds is either a package that reports completion on launch, or somebody who found a way past the content. Either is worth knowing about, and both look identical in a completion report.

Records belong to the learner

They are personal data about somebody’s performance. Who can see them should be deliberate — a manager seeing their team is reasonable, everybody seeing everybody is not.

Worked example

A training team reviews the attempt distribution for each course quarterly. One assessment showed most learners passing on the third attempt; reviewing the interactions found two questions testing material the module never covered.

Recommendations

• Registration for status, attempts for difficulty.
• Read the attempt distribution, not the average.
• Check zero-time completions.
• Restrict who can see learner records.

Scores, Status and Time

The recorded values look self-explanatory and several are not.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

Completion is not success

The distinction that causes the most confusion. Completion means the learner reached the end. Success means they passed.

A learner can complete and fail. Reporting on completion alone counts those people as done, which is how an organisation believes it is compliant when a proportion of its staff failed the assessment.

SCORM 1.2 conflates the two; SCORM 2004, xAPI and cmi5 keep them separate. That is the main practical reason to prefer the newer standards.

Raw score against scaled score

• Raw is the number the content reported, meaningful only alongside its minimum and maximum.
• Scaled is normalised, and is what you should compare across courses.

A raw score of 8 is excellent out of 10 and poor out of 100. Reports that show raw scores without the maximum are reports that mislead.

Progress measure

How far through the learner is, where the content reports it. Not every package does, and one that does not will show no progress until it suddenly shows complete.

Time is unreliable

Session time and total time record how long the content was open, which is not how long somebody spent learning. A module left open over lunch records two hours.

Use time to spot anomalies — the zero-second completion, the eight-hour session — rather than as a measure of effort.

Entry and exit modes

Whether the learner started fresh or resumed, and how they left. Useful when diagnosing a package that behaves oddly, and largely uninteresting otherwise.

Credit and launch mode

Whether an attempt counts. Content launched in a preview or browse mode should not produce a compliance record, and these fields are how you tell.

Check them if a result appears that nobody expected — somebody previewing content can generate one.

Report on the right thing

For compliance: success status, within validity. Not completion, not score, not time. Every other measure has a plausible reading that overstates your position.

Worked example

An organisation reported completion for two years and believed it was fully compliant. Moving the report to success status showed roughly one in eleven learners had completed the assessment and failed it, and had never been asked to retake it.

Recommendations

• Report success, not completion, for compliance.
• Use scaled scores for comparison.
• Treat time as an anomaly detector, not a measure.
• Check credit and launch mode on unexpected results.

Question-Level Detail

Where the content reports it, every question a learner answered is recorded individually.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

What an interaction holds

• The question’s identifier and description.
• Its type — multiple choice, true/false, matching, and so on.
• The learner’s response and the correct response.
• The result — right or wrong.
• Its weighting, and the time taken to answer.
• Which objectives it relates to.

This is the most useful data in the module

And almost nobody looks at it. A completion report tells you people did the training. Interaction data tells you what they did not understand — which is the only thing that lets you improve either the training or the underlying practice.

Find the question everybody gets wrong

The first thing to look at. A question with a very low correct rate is one of three things:

• The question is badly worded or the marked answer is wrong.
• The content does not teach it.
• Your organisation genuinely does not know it.

All three are worth acting on and they need different responses. Read the question before deciding which.

Latency finds guessing

Answers given in a second or two are guesses. A learner whose entire assessment has one-second latencies did not read the questions, and a pass on that basis is worth nothing.

This is the clearest evidence available that a completion is not real.

Wrong answers cluster

Look at which wrong answer people picked, not just that they were wrong. Everybody choosing the same wrong option usually means a genuine misconception you can address directly, rather than a question people found hard.

Objectives connect questions to topics

Interactions can name the objectives they relate to, so questions roll up into topics. That is what turns "question 7 is hard" into "nobody understands data retention".

Not every package reports it

Interaction reporting depends entirely on the content. If this data matters to you, specify it when buying content and check it on a test attempt — after the fact, there is nothing to recover.

It is sensitive

Question-level results are a detailed record of an individual’s performance. Use it in aggregate to improve training; be careful about who can see it per person.

Worked example

A review of interaction data found one question answered correctly by under a fifth of learners, with almost all wrong answers being the same option. The content covered the topic in a single sentence; it was rewritten, and the correct rate rose to over four fifths.

Recommendations

• Find the lowest-scoring question in every assessment.
• Look at which wrong answer people chose.
• Use latency to identify guessing.
• Specify interaction reporting when buying content.

Objectives and Progress

Below the attempt sit two more levels of detail: objectives, and progress through the parts of a package.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

Objectives

Where content declares them, each objective is recorded with its own identifier, description, scores, success status, completion status and progress. So a course covering five topics can report per topic rather than as one number.

Why that matters

A learner scoring seventy per cent might have understood everything except one topic completely — which is a different situation from being weak across the board, and needs a different response.

Across a population, objective-level results say which topic your organisation is weakest on. That is a training plan.

SCO progress

A SCORM package can contain several parts, and progress through each is recorded — status, scores, time, lesson location and suspend data per part.

This is where you see that learners complete the first three sections and stop at the fourth.

Find where people stop

The most valuable use of it. A part where a large proportion of learners abandon has a problem — it is too long, it does not work on their device, or it fails.

The completion report shows people not finishing; this shows you where.

Both depend on the content

Objectives are recorded only if the package declares them, and SCO progress only if the package has multiple parts. Simple packages produce neither, and that is not a fault.

If topic-level reporting matters, ask for content built with objectives — it is a specification decision, not something you can add later.

Use aggregates, not individuals

Objective-level data about one person is of limited use and quite intrusive. Across a cohort it is genuinely valuable, and much less sensitive.

Match objectives to how you think

Content objectives are named by whoever built the package. If your own framework uses different topics, map them once so the reporting speaks in your language rather than the supplier’s.

Check them on a test attempt

Complete a course yourself and look at whether objectives and part-level progress appeared. That is the only way to know what a package actually reports, and it takes one attempt.

Worked example

Objective results across a cohort showed one topic scoring far below the others in an otherwise well-performing course. Part-level progress showed the same section was where most learners paused for several days. The section was split into two shorter parts and both figures improved.

Recommendations

• Report objectives across a cohort, not per person.
• Use part-level progress to find where people stop.
• Specify objectives when commissioning content.
• Confirm on a test attempt what actually gets recorded.

Acting on Results

Training data is only worth collecting if something changes because of it.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

Architect Panel → Automation:

• Workflow Builder — reminders and escalation
• Journeys — a reminder sequence

Three questions

1. Who has not done it — and is about to miss the deadline.
2. Which content is not working — where people fail, stop or take many attempts.
3. What does the organisation not know — from objective and question-level results.

Most organisations answer only the first, and it is the least interesting.

Chase before the deadline

A reminder a week before is worth several after. Build it as a rule or a journey rather than a monthly manual chase, and make the message say what to do rather than that they are late.

Escalate to a manager, once

People respond to their own manager far more than to a training system. One escalation after a clear reminder is effective; repeated automatic escalation trains managers to filter the messages.

Fix the content when the data says to

A course where many people fail, take several attempts, or abandon at the same point has a content problem. Chasing learners harder does not fix that, and it is what most organisations do instead.

Report success within validity

The honest compliance measure is: how many people currently hold a valid, successful completion. Not how many have ever completed, not how many were assigned.

Anything else overstates the position, and it will be the number quoted back to you after an incident.

Show the trend

A single figure invites argument about the number. A trend over months shows whether it is improving, which is the thing you can actually influence.

Close the loop with learners

If a question was badly written, say so when you fix it. Learners who report problems and see nothing change stop reporting them, and you lose the cheapest source of content feedback you have.

Do not use it for performance management

Unless you have said so clearly in advance. Training records used as evidence in a disciplinary process, having been collected as training records, is both unfair and likely to be challenged.

Worked example

A training team reminds at seven days, escalates to the line manager once at the deadline, and reviews content quarterly against fail rates and abandonment points. Its board report shows valid successful completions as a trend, which rose from just over half to nearly all across a year.

Recommendations

• Remind before the deadline, escalate once after.
• Fix content the data flags rather than chasing harder.
• Report valid successful completions as a trend.
• Be explicit if records will ever be used in a performance context.

What Results Prove

E-learning records are good evidence of some things and poor evidence of others. Being clear about which protects you.

Where to find it

Architect Panel → eLearning:

• Courses & Assignments — the course console — courses, units, assignments
• Learner Records — a learner’s registration against a package
• Course Attempts — each attempt at a package
• Course Sessions — individual launches
• Learning Objectives — objective-level results

What the record genuinely shows

• That an account launched the content on a date.
• How long the content was open.
• What the content reported: completion, success, score.
• Where the learner reached, and how many attempts they took.
• Where reported, which questions they answered and how.

That is a solid audit trail of delivery.

What it does not show

• Who was at the keyboard. An account completed it; a person may have.
• That they understood. A pass mark is evidence of a pass mark.
• That they will behave differently. The gap between knowing and doing is the entire subject of workplace training.
• That the content was any good. The record proves delivery, not quality.

Say this out loud

Particularly to whoever relies on the numbers. An executive who believes a completion report means the workforce is competent will be surprised by an incident, and will ask why nobody said so.

It is a much easier conversation before the incident.

Strengthen it where it matters

For training that genuinely matters:

• Assess meaningfully — a real pass mark, a bank of questions, a limit on attempts.
• Check the time taken — a completion in three minutes is not one.
• Observe practice for anything physical or procedural.
• Refresh, because knowledge decays.
• Look at outcomes — incidents, errors, near misses — not just completions.

Regulators are not satisfied by completion

They ask what the training covered, how competence was assessed, and what you did about people who failed. Have answers to all three, and keep the content itself as well as the records.

Keep the evidence of the content

The package as delivered, the version, the assessment. "They completed the course" is much weaker without being able to say what the course was.

Beware the compliance ceiling

Once a report reaches a high figure, attention moves elsewhere — and the figure stays high whether or not the training works. A rising completion rate and a flat incident rate is a signal, not a success.

Worked example

An organisation presents training figures alongside incident data rather than alone, states plainly in its board pack what the records do and do not evidence, and supplements e-learning with observed practice for its safety-critical roles. Its regulator asked for the assessment, not the completion report.

Recommendations

• State the limits to whoever relies on the numbers.
• Keep the content, not only the records.
• Observe practice for anything that matters physically.
• Pair completions with outcomes in reporting.