So far in this series, we’ve explained the differences between internal and external learning record stores, how xAPI conformance affects reporting, and data extraction methods. Now, we’ll wrap things up as we mash together all the bits we’ve discussed during the past four blog posts and look at how the LRS can play a role in the larger data ecosystem.
Insist on LRS quality control.
Learning record stores (LRSs) are required to respond to clients in the way defined by the xAPI specification and validate the data sent from learning record providers. Don’t forget an LRS can store more than just statements. LRSs can handle documents or attachments about xAPI statements and state information about course progress and information about agents (i.e. learners). If you are using a non-conformant LRS, you probably lack the protections a good LRS gives you against bad data, which can cause problems both when processing the data and then displaying it in reports later.
The conformance test suite confirms these requirements when testing an LRS. This is a vital step, but doesn’t guarantee that the version of your LRS is still conformant. The LRS code may have changed, or the LRS may have been configured differently than the settings used during the test. Ask your vendor, whether your LRS is internal (i.e. built into your LMS) or is a standalone external LRS, if they:
- regularly update processes to ensure their LRS remains conformant, and
- have configured or developed their LRS to behave in a non-conformant way.
Define what you want from your LRS data and reporting.
From a data perspective, an LRS sits at the center of your learning ecosystem and brings data together from all your learning systems, applications, and content. It also can connect to operational systems to gather data about job performance—that is, if it supports that functionality. We discussed in an earlier post that reporting isn’t one-size-fits-all, so make sure you look for the features that will enable the canned or custom reporting you’re looking for.
Remember, an LRS only needs to follow the xAPI guidelines to collect, store, and extract data. Any of the extras are just icing on the cake. So when considering if your internal or external LRS has all the core functionality plus the additional features you need, keep the following features in mind:
- Tools for developers, such as debug logs and data search
- Additional data export functionality beyond core xAPI requirements (e.g. options to query via API, data downloads, or pushing learning records to other LRSs)
- Data import options, including CSV to xAPI translation
- The ability to merge data about individuals collected under different identifiers (e.g. actors) for that person
- Organizational hierarchies for comparative reporting and permissions
Recommended Reading
Many of the additional features listed above aren’t simply checking a box with yes or no. The quality, robustness, and usefulness of these features can vary significantly between LRSs—whether internal or external. Overall performance and speed, services offered, and support are other factors that vary between LRSs.
Consider the potential role an LRS plays in your future data ecosystem.
Every scenario is unique, but one of the main things you need to consider is data access. Pure xAPI data (and the standard LRS query endpoints) only allows you to look at the main parts of the statement, actors, verbs, objects, and whatever is in context/result. So when you query that data, you could get a list of the people who've failed courses, but not information such as their managers, job roles, etc.
While most internal LRSs can’t consume HRIS data, an external LRS (such as Watershed) can consume this type of data—which means you can slice and dice the data using your hierarchical data. And this is just the beginning when it comes to the other types of data you can combine with your learning data. Imagine the stories you can tell when you’ve got the complete picture.
Remember as well, the ability to report on the data in your ecosystem is only a small part a good LRS can play. A good LRS is able to not only allow you to run reports, but also share and embed those reports and that data in other systems either manually or via APIs.
Some LRSs also provide automation tools (e.g. Watershed calls these Workflows) that allow the LRS data to be used to drive things such as learner engagement, or build business rules and processes that utilize the data within it.
Use your data to color the story of your learning ecosystem.
A good LRS should make your job easier, your decisions faster, and your learning programs better. If it doesn't, you need to ask why—and I’d wager it has something to do with your data quality or data governance breaking down somewhere. If your LRS is the cause of this, then it's time to think about a new conformant LRS.
About the author
Peter Dobinson is passionate about developing connected learning ecosystems that empower organizations to deliver exceptional learning experiences. With a strong foundation in product design and management, eLearning interoperability, system integrations, user-centered design, and data analytics, he thrives in helping organizations get the most out of their L&D data. Peter's background in learning technology means he has the knowledge and expertise needed to drive the implementation of innovative solutions such as xAPI within the L&D industry. In other words, Peter helps organizations unlock the true potential of learning—one ecosystem at a time.
Subscribe to our blog