Learning analytics for video: the four things an LMS cannot tell you

An LMS dashboard gives an L&D lead a fair picture of most of a course, drawing on login frequency, session metrics, course progress, device, assessment results, surveys, participation and completion rates. For a quiz or an assignment that works: the learner produced an artefact, and the artefact is the evidence.

Video breaks the pattern. A platform files it under resource usage, which records whether the learner opened the file, so someone who drags the scrubber to the end fires the same completion event as someone who watched it all, and the gradebook can't separate them.

Video learning analytics has to answer four questions your LMS can't: whether it was watched, where attention went inside it, whether the signal is honest, and which learner a human should review. Each one below has a concrete fix.

TL;DR

Standard LMS analytics records video as opened or not opened, then marks completion from a position report the player sends, so a dragged scrubber and a full watch produce the same end state.

The bigger gap is that nobody checks whether the recorded signal is real. The four methodologies the field names, descriptive through prescriptive, are all steps up in statistical sophistication, and none asks whether the record underneath is true. Grading on watch coverage, the unique seconds a learner played, with server-side verification on every callback, closes both.

One: was the video watched?

The Society for Learning Analytics Research frames learning analytics around gathering and interpreting data about learners so that teaching and learning improve (SoLAR, 2026). The definition doesn't say which data. Your platform decides that, and for video the answer is usually one field.

Video sits inside resource usage, and resource usage is a binary: opened, or not opened. Platforms that model navigation with xAPI statements do better on sequence, because they can say a video was launched and later that it ended, but neither model records the seconds in between. An LMS completion is a click event wearing a timer, and nothing in that chain confirms the middle was ever played.

Coverage is the alternative. The server keeps the unique seconds a learner actually played, merges overlapping ranges and removes duplicates, so rewatching a minute counts once and seeking forward adds nothing. Coverage only ever grows, so no reload or replay resets it to a friendlier number.

We grade this way in our Moodle activity plugin. The player posts watch progress every ten seconds and on tab close, our server merges each callback into the coverage record, and we default the completion threshold to 90 percent of the video's unique seconds. Switching one activity over is a percentage box on its completion settings rather than a code change. That makes the first useful comparison cheap: run a lecture you already have on coverage, then read its completion rate against what your LMS reported last term. The walkthrough sits in how to track and grade video completion.

Two: which engagement metrics matter?

Completion answers one question with one bit, and a course team usually wants the other thing entirely: the second where learners leave. That needs the shape of the watching, not its total: which segment gets replayed three times, which minute loses a third of the cohort. It also matters whether the loss is spread out or concentrated, because a concentrated loss points at the content there rather than at the length.

The scale of the effect isn't in dispute. Across 6.9 million watching sessions in four edX courses, median engagement time was at most six minutes whatever the video's length (Guo, Kim and Rubin, ACM Learning at Scale, 2014). Students often made it less than halfway through anything over nine minutes. An LMS report can say forty learners finished and twelve did not, but not that eleven of the twelve stopped inside the same thirty seconds.

We built the Watch report for that gap, so it gives unique viewers, average watched percentage, completion rate, the biggest drop-off point, an engagement curve, and a per-student table carrying a Flags column. It is read-only and reads data we already hold, so switching it on adds no tracking.

Three: is the signal honest?

SoLAR names four methodologies for learning analytics: descriptive, diagnostic, predictive and prescriptive. That is a flat list of techniques rather than a ladder an organisation climbs, but arranging it as a ladder is how the field talks, so we will arrange it and own the argument rather than dress it as a citation. Descriptive aggregates what happened, diagnostic asks why, predictive forecasts, prescriptive recommends an action.

Now read our rungs and notice what they measure. Every one is a step up in statistical sophistication, and not one asks whether the underlying record is true. A prescriptive model built on a tampered timeline is a confident recommendation about fiction.

The gap matters because the tampering is easy and leaves no trace in the LMS. A scrubber drag costs nothing, a looped tab reports watch time while nobody watches, and a replayed callback writes the same success twice. Browser-fired analytics carry the same weakness outside an LMS, which video analytics in WordPress works through in detail.

Verification is a server-side job, and when we specified ours it came out as a short list of arithmetic rather than a model. Each watch-progress callback runs all six checks, every time:

1. Watched time cannot exceed the video's duration.
2. Watched time cannot exceed wall-clock time since the session started, with a ten-second tolerance.
3. Reported coverage cannot be lower than what the server already holds.
4. A single callback's gain cannot exceed the elapsed time, with a ten-second tolerance.
5. The learner's view capability is re-verified on every callback.
6. With seeking disabled on the activity, the server rejects any forward seek.

None of those checks needs a model or a tuned threshold, because each compares a number against a clock and against the record already on disk, which also makes them something to test rather than take on trust. Our install verification steps finish by switching to a student role and playing past the threshold, and dragging the scrubber there instead is a one-minute way to watch a check fire and read the reason it records.

Four: who needs a human?

A failed check could lock the learner out. We decided it shouldn't, and the reason is worth stating plainly, because automatic enforcement on this signal punishes the wrong people.

A laptop that slept mid-lesson, a phone whose clock drifted, a hotel network that dropped four callbacks and delivered them in a burst: each produces arithmetic that looks like cheating. Locking a learner out the first time a check fails turns a network fault into an accusation they can't argue with.

So a failed check increments a per-attempt fraud counter and records a typed reason instead. Nothing stops at the first failure. All six run on every callback, the counter climbs by however many failed at once, and only the first reason is kept. That is why a genuinely broken session racks up a count far faster than the number of callbacks would suggest.

The count surfaces in the Flags column of the Watch report, beside the reason the last failure recorded. Anyone holding mod/fastpix:viewallattempts can read it and open the attempt, and correction happens through mod/fastpix:graderoverride. We narrow the review queue from a whole cohort to a handful of attempts, and a person who knows the learner makes the call.

Everything in that flow is personal data about an identified learner: watch progress, seek counts, the fraud counter, completion state and session timestamps. We register as a Moodle Privacy API provider and declare each of those columns, so a subject access request exports them and a deletion request removes them through Moodle's standard screens.

What video learning analytics must prove

Most accepted definitions of learning analytics came out of the education sector and the vocabulary followed. So an L&D lead in a regulated company inherits terms built for degree programmes, then has to answer a question no degree programme asks: can you prove this person watched the safety briefing. The five questions below separate a dashboard that draws a nice curve from one that survives audit.

Anything failing the first two rows produces numbers you can chart and cannot defend, fine for a marketing video and a real problem for a certification record.

Switch video learning analytics to coverage

If a completion number has ever had to hold up in front of an auditor, the fix belongs at the completion layer, not the dashboard layer. Our Moodle activity plugin grades on coverage, verifies every callback on the server, and hands anomalies to a teacher rather than an automatic lock.

Standing it up is a site administrator's job and takes ten minutes: local_fastpix holds the credentials, mod_fastpix adds the activity, and the account those connect to is free for the first ten videos, no card. If the completion number is yours to defend but the Moodle site is not yours to touch, we would put the five questions above to whoever administers it.