Education & Workforce
Student Success Analytics API
Most students who withdraw show it in their activity weeks beforehand. The useful question is not who will fail — it is who should get a phone call on Monday.
- Learning platforms
- Universities and colleges
- Training providers
- Apprenticeship providers
- Education software vendors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Withdrawal is rarely sudden. Submission timing slips, logins move later and get shorter, the discussion forum goes quiet, a student stops opening the material before the session rather than after. By the time a grade records the problem, the window in which a tutor could have helped has usually closed. The signal exists and it is early; what is missing is anything that routes it to the person who could act.
Institutions do collect the data. It sits in a VLE, an assessment system, an attendance register and a student record, usually in four places that do not talk to each other, and gets looked at in retrospect when a cohort's completion rate is already a number in a report. Joining those sources and running them weekly is unglamorous work that changes what is possible.
What the output is used for determines whether the whole thing is worth building. A risk indicator that directs tutoring, outreach and hardship support towards struggling students is straightforwardly good. The same indicator used to stream students into lower-expectation pathways, to rank them visibly against peers, to influence admissions, or to justify withdrawing support from someone labelled unlikely to finish, becomes a mechanism for narrowing opportunity — and it will narrow it hardest for the students who already had the least. That distinction is a design constraint, not a disclaimer.
Who buys this
Learning platforms, Universities and colleges, Training providers, Apprenticeship providers, Education software vendors
What the API returns
What comes back
- Completion risk indicator per student with the contributing signals listed
- Engagement pattern summary — session timing, depth, regularity and recent change
- Progress against the expected trajectory for that module and cohort
- Specific, actionable flags such as missed formative work or a dropped submission streak
- Suggested support action per flag, mapped to the interventions the institution actually offers
- Cohort-level analysis of which modules and transitions generate the most difficulty
- Intervention outcome tracking so support can be evaluated rather than assumed
- Low-confidence flags where there is too little activity data to say anything
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/students/{id}/risk | Completion risk indicator with contributing signals |
| GET | /v1/students/{id}/engagement | Engagement pattern summary and recent change |
| GET | /v1/cohorts/{id}/at-risk | Prioritised support queue for a tutor or adviser |
| GET | /v1/modules/{id}/friction | Where a module loses students, by week and activity |
| POST | /v1/interventions | Record a support action and its outcome |
| GET | /v1/interventions/effectiveness | Measured effect of intervention types by cohort |
Request and response
illustrativeRequest
{
"cohort_id": "bsc-comp-y1-2026",
"as_of": "2026-10-21",
"order_by": "support_priority",
"limit": 25,
"include": ["signals", "suggested_actions"]
}Response
{
"cohort_id": "bsc-comp-y1-2026",
"as_of": "2026-10-21",
"queue": [
{
"student_ref": "stu_20411",
"priority": "high",
"confidence": "medium",
"signals": [
{ "signal": "submission_streak_broken", "detail": "2 formative tasks missed" },
{ "signal": "login_depth_down", "detail": "median session 4m, was 19m" },
{ "signal": "pre_session_access_stopped", "detail": "last 3 weeks" }
],
"suggested_actions": [
{ "action": "tutor_check_in_call", "offered_by": "personal_tutor" },
{ "action": "study_skills_referral", "offered_by": "learning_development" }
],
"not_used_for": ["streaming", "admissions", "public_ranking",
"withdrawal_of_support"]
},
{
"student_ref": "stu_20518",
"priority": "low_confidence",
"confidence": "low",
"signals": [],
"note": "Insufficient activity data — 11 days enrolled."
}
],
"cohort_summary": { "flagged": 25, "size": 318, "baseline_completion": 0.84 }
}Where the data comes from
| Your VLE or LMS activity logs | Access, submission and interaction events, which carry most of the early signal |
| Assessment records | Formative and summative results and submission timing, held under your own data protection notice |
| Attendance or participation data | Where collected, and interpreted carefully — absence has many causes and should never be read as disengagement on its own |
| Student record system | Enrolment, module registration and progression history, used for trajectory rather than for profiling background |
| Support service records | What was offered and taken up, with agreement, so intervention effectiveness can actually be measured |
| Curriculum structure | Module sequencing and assessment calendars, because a quiet week before reading week is not the same as a quiet week before a deadline |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Engagement features built from change rather than level — a student who was always a light user is not the same as one whose activity halved last fortnight
- Trajectory modelling relative to the module and cohort, since expected activity differs enormously between a lab-based module and a reading-based one
- Signal-level output: every indicator decomposes into named, inspectable signals, because a tutor acting on an opaque score will either ignore it or misuse it
- Deliberate exclusion of demographic and socio-economic attributes from the risk features, with proxy testing on the remainder — a model that learns postcode is a disadvantage amplifier wearing a dashboard
- Calibration checked separately across student groups, so the indicator is not systematically worse for part-time, mature, commuting or widening-participation students
- Minimum data thresholds with explicit low-confidence output early in a module, instead of flagging students on eleven days of activity
- Intervention outcome tracking with comparison groups where ethically possible, so support types can be evaluated rather than defended
- Monitoring for feedback effects — if flagged students systematically receive different teaching, the historical relationship the model learned no longer holds
What it changes for the business
Earlier contact
A weekly support queue reaches students while there is still time in the module to change the outcome.
Support that lands
Signal-level flags let a tutor open with something specific rather than a general wellbeing enquiry.
Curriculum evidence
Module friction analysis shows where a cohort loses people, which is a teaching design finding rather than a student problem.
Measured interventions
Outcome tracking tells an institution which support actually works instead of which is best liked.
How it fits into your product
How it embeds
- REST endpoints feeding tutor and adviser dashboards, with the support queue as the primary surface
- Weekly batch runs aligned to the teaching calendar, which matches how pastoral support actually operates
- Deployment inside your own infrastructure, which is the usual requirement for student data and often a condition of ethics approval
- Role-scoped access so a tutor sees their own students, with no institution-wide student ranking view built at all
- Webhooks into your case management or CRM so a flag becomes a task rather than a chart
- Configurable intervention catalogue mapped to the support your institution genuinely offers
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Could this be used to stream students or limit their options?
It should not be, and we design against it. There is no league table view, no exportable student ranking and no predicted-grade field, because those are the shapes that get repurposed into streaming. The output is a prioritised support queue scoped to the tutor responsible. If the intended use is deciding who gets access to a pathway, who to admit, or where to stop investing support, this is the wrong tool and we would say so during discovery rather than build it and add wording to the contract.
Do students know, and can they see it?
They should, and we would build for that. Learning analytics affecting a student needs a lawful basis and transparency under data protection law, and most institutional ethics frameworks now expect a student-facing view. Signal-level output makes that possible — 'you have missed two formative tasks and your study sessions have got shorter' is something a student can see and respond to, which an opaque risk percentage is not.
How accurate is the risk indicator?
Useful for prioritising a queue, not accurate enough to treat as a prediction about an individual. Many flagged students complete perfectly well, which is partly the point — the cost of a false positive is a phone call, and we tune the threshold accordingly. We report calibration separately by student group, because an indicator that works well overall and badly for part-time students is not working.
What about students with very little activity data?
They are returned as low confidence with no flags rather than as low risk. Early in a module, during an interruption of study, or for a student doing most of the work offline, there simply is not enough signal. Silently treating absence of data as absence of risk is how these systems miss the people they were built for.
Can we use it to decide who keeps a bursary or a place?
No. We would not build toward that, and we would decline the integration. Using a probabilistic indicator to withdraw support from the students most likely to need it inverts the entire purpose, and it would fall hardest on exactly the groups widening-participation work exists to help.
Related blueprints
Skills Assessment API
Standardised skill tests, scoring and gap analysis delivered as an API your HR or learning platform embeds under its own brand.
Credential Verification API
Verification of education and professional qualifications through authorised issuers and registers, returned as a single call with a documented evidence trail.
Job Market Intelligence API
Structured labour-market signal — salary ranges, skill demand and hiring trends — as a data layer inside your HR, recruitment or education product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.