eLearning has become a popular and convenient modern-day training tool. There is an urgent need to seek effective ways to collect data about learner performance and utilize it to enhance eLearning experiences for both educators and learners. This data will not only improve eLearning experiences, but also serve as a good reference point for organizations when making critical decisions.

Enter, a Learning Record Store. In this blog, we’ll go over its’ basic definition, its’ history, pros and cons of an LRS, and how it differentiates from a Learning Management System (LMS). We’ll also cover more applicable knowledge, such as how to choose the right LRS for your organization, what pricing looks like, and how Knowledge Anywhere is incorporating more LRS features into our LMS.

What is a Learning Record Store (LRS)?

A LRS (Learning Record System) is a storage system that functions as a depository for learning records collected from connected systems where eLearning is conducted. An LRS is the focal point of your eLearning ecosystem and brings together data from your learning systems and applications. It is responsible for receiving, storing, and providing access to all eLearning records.

An LRS is an integral element in the process flow for utilizing the Experience API (xAPI) standard by ADL (Advanced Distributed Learning). The Experience API is also popularly referred to as project Tin Can, or Tin Can API, and is an Open-source eLearning stipulation developed after SCORM and AICC. The LRS is uniquely designed to help systems store and retrieve xAPI statements and other forms of xAPI metadata from other systems.

Lately, it’s become a trendy topic in the eLearning sphere. Just make sure you know if a system really has or needs an LRS before buying into it, as many confuse the function of an LRS with an LMS.


The LRS was first adopted in the eLearning sector in 2011 seeking to transform eLearning specifications. Before 2011, SCORM was the eLearning software specification for interoperability since 2001.

However, the specification could not keep up with the technological advancements and needed an update. What followed was extensive research and developments that led to Experience API and the LRS concept.

An Overview of the LRS: Pros

In plain English, xAPI-enabled learning activities generate data in the form of “statements” or eLearning records in the format of “Actor verb Object” or “I did this.” The statements are then sent via HTTPS or HTTP to an LRS. The primary function of the LRS is to receive, store and retrieve data generated from Experience API statements. An LRS can be incorporated within a traditional Learning Management System (LMS) or can stand-alone. LRSs can transmit learner data to other systems, including other LRS servers, mobile devices, sensor-enabled devices, and LMSs. Systems that send statements to an LRS are referred to as Activity Providers or learning record providers. Examples of Activity providers include (but not limited to):

  • Mobile apps
  • VR/AR simulators
  • LMSs
  • Videos
  • Games
  • Articles, webpages, or entire websites
  • An eLearning course
LRSs offer you unique abilities to create detailed eLearning analytics. This is because you can capture any data on any learning experience regardless of where and in what format it takes place. Traditional eLearning specifications, such as SCORM, can only store single data points, such as a completed study or the final score of a test. The LRS, on the other hand, records a statement structure that gives you multiple data points to report against. You can pull reports on multiple combinations of “Actor,” “verb,” and “object.” By gathering data about all learning experiences, you can accurately evaluate the impact of your organization’s training resources to determine which tools and methods are most effective. However, an LRS strictly designed to the xAPI specification may not feature a built-in reporting capability. Therefore, you may have to provide a way of accessing the LRS data and create a system for data reporting.


Take note not to confuse the Learning Management System and the Learning Record Store. The features of an LRS make it sound like it does the same things as an LMS. Your LRS will likely replace and exceed the reporting and analytics capability of your LMS. However, there are still many other functions of the LMS that are not featured in an LRS. As such, LRS is not a replacement for your LMS and vice versa. 

Functions of an LRS: The major difference between the two is that an LRS is designed to receive, track, and store xAPI statements. 

Functions of an LMS: On the flip side, LMS manages all your company’s learning needs, tracking, and reporting statements through its native reporting features. You can also forward data from an LMS to your LRS server if you need to.
  • Manage course content
  • Manage users
  • Schedule events
  • Send reports
  • Use Certifications
  • Deliver course content

Choosing the Right LRS for Your Organization

Choosing an LRS to track the effectiveness of your learning programs (and learners’ performance) is a critical step. You need to consider some key factors to help you choose and implement the right LRS system. Here are a few factors you should consider to help you choose a suitable LRS system for your organization. 

Functionality: Whereas most LRS systems have the same basic functionality (storing and retrieving xAPI statements), they are customized for interfacing with various external systems and often have built-in reporting, analytics, and visualization functions that may vary in features. If you choose a system not optimized for your organization, you may end up wasting your company’s money and time for learners and administrators. 

Durability: Another important factor when choosing an LRS system is durability. This is the question of whether the system will keep up with the market so it remains available and consistent with periodic upgrades and maintenances. This is critical so as to account for evolutionary changes in the IT environment in which LRS operates. You should also consider whether the system will easily incorporate revisions to the xAPI in the future. 

Scalability: As with learning platforms, LRSs should be chosen with consideration for scalability and extensibility and how they will fit your organization’s overall architecture. To determine an LRS system’s extensibility, consider focusing on systems’ modularity and how you can customize the LRS services to meet the learners’ changing needs. When thinking about scalability, evaluate your organization’s growth patterns and projections to determine whether or not an LRS meets the potential volume demands (due to growth) for your organization. 

Business System Integration: According to Brandon-Hall’s 2011 survey, enterprise integration is the most critical requirement for businesses seeking to migrate to a new LMS. But this applies to LRSs as well, more so in terms of the ability of the xAPI to correlate learning behavior data (captured in an LRS) with work performance data (captured in non-learning systems). Other essential factors to consider include:
  • LRS conformance testing
  • Security and reliability
  • Level of expertise required, among others.

LRS Cost and Pricing Models

Different LRS vendors have different pricing models depending on a wide range of factors, and it may be difficult to compare prices between vendors. Have a look at these basic categories of pricing models to help you make an informed decision.
  • Seat-based model: This model uses the number of learners/employees in your organization or the maximum possible number of users who will ever write statements to the LRS. Usually, there are tiers - for instance, up to 10,000 users, up to 20,000 users. However, this model may run into problems with extranet users (other users besides the employees).
  • Analyst based model:This model is a slight variation of the seat-based model. The difference is that it uses the number of people who need to analyze or maintain the system’s data rather than the number of learners who may send statements to it. This system is priced according to the number of users in each tier. Each tier often at least includes system administrators and owners and is differentiated by permissions/privileges.
  • Usage-based pricing models: This pricing model is based on the number of xAPI statements sent to the LRS per month. It is particularly useful when you anticipate LRS usage surges due to seasonal cycles, new product releases, and such. In case your company minimally uses an LRS system except in specific short periods, it is more economical to pay per use for the time used than paying for a tier of seats.
  • Capability-based: In this model, the pricing is based on system capability rather than usage or seats. For example, this model’s base-level product can be a simple/pure LRS without any analytics. The mid-level tier can integrate reports and external business intelligence. The highest tier can entail features like sign-on and interactive, real-time analytics. The capability pricing model can also be used together with any of the pricing models mentioned above.

How Knowledge Anywhere Can Help

At Knowledge Anywhere, it is our job to help you achieve your training goals faster. Ours is an innovative alternative to the traditional Learning Management System. It’s a superior training platform that allows you to seamlessly manage, organize and assign your online or in-person training all under one roof. While we do not have a full LRS, Knowledge Anywhere has made conscious steps to integrate LRS capabilities into our LMS platform. With this in mind, we’ve been working on supporting the storage of data in an LRS, which will in-turn open up other integration and analytics opportunities. For any information about eLearning, whether it be about a Learning Record Store, Learning Management System, SCORM Conversion tool, Learning Content Distribution System, Custom Course Development, or Virtual Reality Training, contact us today!

Sign up to receive industry tips, trends, & insights