One of the largest benefits made possible by the Experience API (xAPI) is the ability to track interactions that involve multiple users. Prior to the introduction of xAPI, the user-centric SCORM model could only log data against the user who had launched the course. This meant that the SCORM data model didn’t expand far beyond completion status, score, and tracking of interactions within the launched module.
The decentralised nature of the xAPI provides much more flexibility in the types of interactions an activity provider may want to track, even extending so far as being able to cover interactions between an arbitrary number of users or groups of users. One innovation in the xAPI specification best suited for this task is the SubStatement and it’s one that appears to be very under-utilised within the community thus far.
Fred rated himself a score of 7 in Communication Skills– A Typical xAPI Statement
The above statement represents a user named Fred completing a self-assessment in a given competency. The flexibility of the Experience API means this kind of statement is easily expanded to introduce a second user.
Susie rated Fred a score of 9 in Communication Skills– An xAPI SubStatement
We’re now able to turn a simple self-assessment into a 180 assessment by tracking Susie rating Fred in the same competency. This is then just as easily expanded into a 360 assessment by providing the same assessment to Fred’s peers and tracking each of them as the assessors.
SubStatements are so powerful because after a series of these are collected, the richness of the data opens up some interesting reporting possibilities. There’s the immediate and obvious report of comparing the learner’s self-assessment with their manager and highlighting areas of difference – a decades-old business practice of determining areas for professional development.
However, when we track this on a larger scale with many users, we’re also suddenly able to perform some exploratory data analysis to determine interesting insights such as which managers score higher or lower than others.
Let’s add an extra spin on this concept of tracking an interaction between multiple users. Thus far, we’ve highlighted how it’s possible to track a user completing a learning activity in respect to another learner, but the xAPI is abstract enough that we can track interactions that occur outside the learning activity as well.
A common example statement for the Experience API takes the following form:
Justin was registered into Snowboarding Essentials on May 22nd
As a bare-bones example, this kind of tracking statement works just fine, but we believe it can be enhanced considerably by turning it into a SubStatement. Looking at this example, we might wonder the following:
- Who registered Justin into Snowboarding Essentials. Did he register himself?
- When is Justin planning to undertake Snowboarding Essentials?
- Why was Justin registered into Snowboarding Essentials?
To use the Experience API to its full potential, as much entropy as possible should be built into the statement. By using the flexibility of SubStatements, we can pack some extra information into the data:
Stephen registered Justin into Snowboarding Essentials for June 1st on May 22nd.
This kind of statement now opens up a diverse range of additional reporting possibilities:
- From an audit perspective, we can determine which users are registering others and when that registration took place (did Stephen give Justin enough notice to attend the training?).
- We’re able to forecast upcoming training and the number of users who will be undertaking that training for resourcing purposes.
- By including Stephen’s user profile information, we can determine how many registrations are being assigned by managers, specific job roles, etc.
- We can start to correlate with additional tracking data to draw causal and behavioural links, i.e. did Stephen just complete Snowboarding Essentials himself and then register Justin as a result?
By utilising some of the more sophisticated aspects of the xAPI specification, it allows us to draw insights that otherwise wouldn’t have been possible.
This was a very brief introduction into SubStatements, in a follow-up article we will undertake a technical deep-dive into how to write these SubStatements and what pitfalls to avoid.