This guide includes everything you need to know about the Experience API (xAPI) and Learning Record Stores (LRS) in 2020. Read on to learn more.
xAPI refers to the Experience API, which was initially known as the Tin Can API or "Project Tin Can." It is a technical specification for the Learning and Development (L&D) industry.
The xAPI specification defines how to structure, send, and retrieve learning and performance data. When tools adhere to the xAPI specification, it makes it possible for all of them to communicate with one another. Also, since the data is in the same format, it makes it easier for people to analyze and compare data from different sources.
The main benefit of xAPI is that it allows you to track learning wherever it occurs. It empowers you to bring data from many different learning tools and systems into a single tool for analysis.
This means that tracking is no longer limited to what occurs on a Learning Management System (LMS). You can track learning that occurs in an eLearning course, on a website, in a mobile app, in a flight simulator, in a face-to-face session, or anywhere else.
On top of this, xAPI is very flexible. For example, you can use xAPI data to determine things like:
If the activity is occurring on a system that, at some point, has access to the internet, then you can likely track any aspect of that activity with xAPI.
Finally, xAPI data is interoperable. Just as you can upload a SCORM package to any LMS, you can send xAPI data to and from any Learning Record Store (LRS). We’ll take a closer look at LRSs in a later section.
This means that, when using xAPI, you are not locked to any specific software. You can bring your data with you to new tools, platforms, and vendors. It also means that xAPI-enabled tools know how to deal with data they receive from other xAPI-enabled tools.
In essence, xAPI gives you one language and set of rules that you can use to track and report on all of the human learning and performance experiences that occur.
xAPI data exists in the form of human- and machine-readable xAPI statements. Therefore, xAPI statements are the building blocks of xAPI. Each statement is composed of three core components: an actor, verb, and object. For example:
The actor, verb, and object components are required to send an xAPI statement, but you can add much more detail as needed. For example, more detailed xAPI statements can tell you the following information:
We’ll cover xAPI statements in more depth in the xAPI Objects section later in this article. For now, it’s important to know that xAPI data is sent and received in the form of xAPI statements. These statements can hold specific, flexible data about any human experience.
xAPI deals with sending, retrieving, and analyzing data, but it’s up to the practitioner to use the data in meaningful ways. Let’s consider some of the different ways that you can use xAPI:
As you can see, xAPI is often used to track and analyze human learning and performance. xAPI data can help designers create adaptive learning experiences and make data-driven improvements to their learning offerings.
xAPI activity providers (or learning record providers) are anything that can generate and send xAPI statements. For example, you may have an eLearning course that generates statements, an app that’s used during face-to-face sessions that generates statements, and an LMS that generates xAPI statements. The eLearning course, app, and LMS would all be considered activity providers in the context of xAPI.
In technical terms, xAPI “works” by communicating data from an activity provider to an LRS via HTTP requests. To break this down further:
Activity providers can also pull xAPI data from the LRS. This allows the learning experience to adapt and change based on the user’s previous learning and performance experiences. In that case, xAPI works like this:
In short, xAPI works by sending data to and retrieving data from an LRS. Let’s take a closer look at what an LRS is.
So, all of this talk about xAPI and LRSs, but what is an LRS? An LRS is a database that holds your xAPI statements. Since you need an LRS to hold your xAPI data, you cannot use xAPI without an LRS. They go hand-in-hand.
In addition to holding your xAPI data, LRSs often include analytics capabilities. They allow you to create dashboards, generate reports, and work with your data to gain insights.
You can use multiple LRSs to hold data from your different systems, but it’s a good idea to have one LRS that serves as the “point-of-truth” for all of your learning and performance data. By bringing all of this data into one LRS, you can look at relationships and create more meaningful, informative dashboards.
When done effectively, this will give you insights into the effectiveness of your learning programs. It will also help you identify where to focus your efforts to improve effectiveness.
The Learning Record Store (LRS) is not to be confused with the Learning Management System (LMS). As discussed, LRSs hold your learning and performance data — they receive the xAPI statements from your xAPI activity providers.
LMSs, on the other hand, handle many more tasks. They allow you to gate content behind user accounts, give different levels access to different users, and use basic reporting capabilities.
While some LMSs have built-in LRSs, most do not. If you already have an LMS, you can use an LRS from another vendor — this is a very common workflow. Likewise, if you have an LMS that does have an LRS included, then you should be able to send xAPI statements from any activity providers to your built-in LRS.
There are dozens of LRSs on the market, and while all of them can store your xAPI statements, they come with different feature lists and price points. Since you need an LRS to use xAPI, choosing the right LRS plays a big role in successful xAPI adoption. You can view the full list of LRSs on the xAPI Adopter Registry, but I will cover some of those that I am familiar with here.
Important note: If the LRS is not included in the adopter registry, then it may not be xAPI-conformant. xAPI-conformant LRSs must pass a test suite that includes over 1300 tests, and this ensures that the xAPI statements are interoperable across systems. I do not recommend using an LRS that has not passed this test!
Learning Locker proclaims that they are the "most installed Learning Record Store" in the world. They have an open-source install that you can either host on a server of your own or install with one click on AWS. This configuration will run you at least $30 a month on an AWS server, but it gives you a fully functioning LRS.
They also have Enterprise offerings where they take care of all the hosting and backups. This gives you access to their xAPI-enabled tools, one of note being a GDPR-compliance tool. With servers based in Europe, this is a great option for companies in the EU who need to comply with GDPR rules and regulations.
Veracity LRS is an excellent LRS for people looking to get started with xAPI without breaking the bank. They have a great free tier plan, and unlocking additional storage or record stores is much more affordable than it is with other companies.
Their feature set is also impressive, giving you full control over the dashboards and charts that you create (even on their free tier).
Watershed LRS is another popular option. Watershed is an offshoot of Rustici Software, the company that developed the xAPI and SCORM specifications, so you know that the people behind this LRS know their stuff.
That being said, you’ll be paying accordingly if you want to unlock any of their analytics and advanced reporting capabilities. They do have a “free forever” tier, but this tier only allows you to store your data...not analyze it or create visualizations to gain insights.
The other great thing about Watershed LRS is that they integrate with Zapier, which in effect allows you to integrate your LRS with thousands of other tools. This allows you to move data to and from the other tools easily using Zapier integrations. (We’ll take a closer look at Zapier in the xAPI Tools section.)
GrassBlade LRS is another popular choice due to its price point and great integrations. GrassBlade integrates with Zapier too, but you need to request an invite from their support.
The most popular GrassBlade LRS configuration is with Wordpress and the LearnDash plug-in. This lets people upload xAPI and SCORM packages to Wordpress and generate valuable learning data just as they would on a full-fledged LMS.
With this being said, GrassBlade LRS is capable of handling xAPI statements from any activity provider.
The great thing about xAPI is that interoperability is at the forefront of the specification. Because of this, you can send xAPI data from one LRS to another with ease.
Many LRSs have this functionality built-in: you can automatically forward statements in LRS A to LRS B, even if LRS B is from a completely different company. This functionality makes it easy to use different LRSs for their different strengths (as well as switch LRSs completely if you ever choose to do so).
Furthermore, even if your LRS does not have analytics tools (or you’re using a free version and cannot access them), that does not mean that you cannot analyze your data. You always have the option to download your xAPI statements as spreadsheets and analyze them in a tool like Microsoft Excel or Google Sheets.
Now that you have a general idea of what xAPI is and how it works, let’s take a look at how xAPI got started.
To appreciate how xAPI came to the scene, it’s important to understand how it compares to SCORM. In 2020, SCORM is still the most popular eLearning interoperability standard. However, it has severe shortcomings.
SCORM deals with how eLearning packages are hosted on an LMS, as well as how the eLearning package and LMS communicate with one another. As the industry has recognized for some time now, most learning occurs outside the LMS — it occurs on the open web, in mobile apps, in learning games, on discussion boards, and more.
Also, even though SCORM is intended to track eLearning on an LMS, it does not give you much information. It can only track basic completion and quiz score data. (See this slide-level analytics article to learn more about the detailed eLearning activity that you can track with xAPI.)
In other words, SCORM allows eLearning courses to be deployed on multiple LMSs, but it doesn’t let you obtain specific, nuanced data from a wide array of learning and performance experiences. This is where xAPI comes in.
Due to SCORM’s inability to track these common types of learning experiences, the industry began asking for something more.
After seeing the shortcomings of SCORM and recognizing the need for something more, the Advanced Distributed Learning (ADL) Initiative began asking the community for input on where to go next. The ADL is the same program that gave rise to SCORM, and this interest in replacing it became serious in 2010.
Soon after, the ADL awarded Rustici Software a contract to ideate the next-generation data specification for the industry.
Together, the ADL, Rustici Software, and the rest of the L&D industry worked on Project Tin Can, which is what xAPI was called before it reached its launch-ready version 1.0. The xAPI we know and love today launched officially in 2013.
Since its release in 2013, xAPI adoption has slowly increased. Adoption usually occurs when teams and organizations find that their learning data is not meeting their information needs. When this is the case, xAPI is often the go-to solution.
Let’s consider the numbers. The most recent data is from a 2019 Learning Guild Report: The State of xAPI Adoption. This report shows that:
As we can see, the majority of participants have yet to use xAPI. However, based on these statistics and the constant buzz about xAPI in the industry, it seems that we are reaching a tipping point.
As more people learn about and begin using xAPI, the profession will likely enter a more data-driven, results-oriented era.
Even though xAPI brings countless benefits in terms of tracking and reporting, there are still barriers that hold organizations back from adopting it.
Based on the survey data, it’s clear that one of the largest barriers to xAPI adoption is that people don’t know about xAPI. As more people post their xAPI case studies and share xAPI resources, we would expect this awareness to rise.
Of the people who know that it exists, it seems that many people do not know exactly how to get started with xAPI at their organizations. This article is intended to help with this — by learning about these core xAPI concepts, you should be in a much better position to move forward with implementation.
Since you can’t use xAPI without an LRS, choosing and purchasing an LRS can be an overwhelming step in and of itself. When organizations see large LRS price tags, they sometimes shy away from the whole endeavor.
However, as discussed, many LRSs have generous free plans (and some LRSs have relatively cheap paid plans).
There’s no doubt that implementing xAPI successfully today requires a technical skill set. You need someone who knows how to write code to collect the xAPI data that you need, and you need someone who can draw insights and actionable conclusions from the data.
Fortunately, there are a host of free online resources to help with this. Also, IT departments are often involved with large xAPI initiatives, and consultants like myself are available to help out with the initial and ongoing technical implementation.
Ironically, one of the barriers holding back xAPI adoption is one of its features: it’s “too” flexible. Since there is no clear road map about exactly how to implement xAPI and which statements to send when, it’s up to the organization to define how they will use it meaningfully.
For people who are unfamiliar with the ins and outs of the spec (or without a big-picture view of the data that they would like to collect), this can be overwhelming.
This is where xAPI profiles come in!
xAPI Profiles define how xAPI should be used within a specific organization or industry. Profiles, previously known as recipes, include guidelines about how xAPI will be implemented in an organization or industry’s unique context.
Technically speaking, profiles contain concepts, statement templates, and patterns — this tells people how to define their activities, which activities are related, and a whole lot more. You can learn more about xAPI profiles in this article by Yet Analytics.
This additional structure that profiles provide not only increases interoperability (making it easier to analyze data from different tools or organizations), but it also provides a clear set of rules for how to implement xAPI for a given use case.
Organizations may create their own xAPI profiles if they are doing a large-scale rollout. In addition to this, they can draw on public xAPI profiles. The public xAPI profiles include, but are not limited to:
So, for example, if you are implementing xAPI at your organization, you may use the video profile to send statements from videos, the open badge profile to send statements relevant to badging, and an organization-specific profile for everything else.
WIth all of this being said, you do not have to use a profile to use xAPI. You can begin conducting xAPI experiments at your organization without an xAPI profile, but you should carefully consider the statements that you will use to track human learning and performance.
Perhaps the most notable and “game-changing” xAPI profile is cmi5. As we mentioned earlier, part of the reason for the relatively slow uptake of xAPI is due to its flexibility. Also, when people do get started with xAPI, it is usually in the context of eLearning. Cmi5 is perfect for this use case.
Cmi5 stands for “computer managed instruction,” and it defines how LMSs should communicate with xAPI eLearning content. Whereas xAPI as a whole is too broad and flexible to replace SCORM, cmi5 as an xAPI profile is exactly what’s replacing SCORM. It’s also often referred to as “xAPI with rules.”
Cmi5 outlines how ten specific xAPI verbs should be used to define human activity on the LMS and in eLearning modules. Furthermore, it defines how the LMS and eLearning must communicate with one another, and this leads to some amazing new possibilities.
Due to these benefits and the straightforward use case for xAPI, the US Department of Defense is in the process of adopting cmi5. When this transition from SCORM to cmi5 by the DoD is official, we expect that industry adoption will increase rapidly (especially since this is exactly what happened with SCORM). You can read more about cmi5 adoption here.
There are currently a few cmi5-enabled LMSs, such as Talent LMS, RISC Inc. LMS, and Brainier LMS. When more LMSs are cmi5-compliant, having an LRS will be the norm. This will make the barrier to working with other xAPI data much lower.
Each xAPI statement is a JSON object, but the statement object is made up of smaller, more specific JSON objects (such as "actor," "verb," and "object" objects).
Since JSON is the “language” of xAPI and this section could get quite technical, I am going to refrain from including any code. The links at the bottom of each section bring you to deep dive articles that include many code samples (if you're interested).
So, earlier, we mentioned that xAPI statements can hold information about an actor, verb, and object, but they can also hold much more information. Let’s take a closer look.
The “actor” object tells you who is performing the action in the xAPI statement. This object includes the actor’s name, as well as either an email address or account to identify them. It’s also important to note that the actor can be a single agent or a group.
The “verb” object tells you which action the actor is performing. It includes the verb’s name, as well as a unique identifier (usually in the form of a URL) to differentiate the verb from any other verbs. This ensures that the meaning of the verb is the same every time that it’s used.
It’s best practice to pull the verb from an existing registry or xAPI profile. The verb’s unique identifier should also resolve to a public URL so that people can visit it to learn more about how the verb is used.
The “object” object tells you which object the actor is performing the action on. The object can be an activity, another actor, or even another statement.
The most common type of object is an activity. This is where you provide information about the activity’s type, unique identifier, name, and description.
The “result” object holds important information when it comes to quizzes and assessments. It can hold information about whether the person completed the activity successfully, what their current score is, what the minimum and maximum scores are, and what their responses are to each question.
The “result” object can also hold duration information, which is one of my personal favorites. You can use the duration property to see how long someone spends on a given question, slide, resource, video, and more.
The “context” object situates the statement within the greater context of the experience as a whole. It can include information about a parent activity, a group of related activities, or even the xAPI profile that it’s adhering to.
Beyond information about activities, it can include context such as who the instructor was for the experience, which team the actor is a part of, and more.
You can add “extension” objects to several different parts of an xAPI statement. These objects let you add whichever data you’d like, and the reason for this is to ensure that xAPI can work for use cases beyond those foreseen by its creators.
This demonstrates just how flexible xAPI is: if your data doesn’t fit within one of the existing objects or properties, then you can define your own.
When your xAPI statement is received by the LRS, it will include some additional information with it, such as the time when the statement was generated, the time when the statement was stored, and authority information about the activity provider that generated the statement.
To learn more about xAPI statements and see code examples, check out my How to Write an xAPI Statement from Scratch tutorial or the xAPI Statements 101 post on xapi.com.
There are many tools on the market, both free and paid, that will make it easier for you to send and work with xAPI data. In this section, we’ll explore some of the most popular xAPI-enabled eLearning authoring programs, LMSs, and supporting tools.
Most people and organizations get started with xAPI by sending statements from their eLearning courses. This is the natural starting place because most eLearning tools can publish xAPI output with the click of a button. However, the degree of control that you have over which xAPI statements are generated varies wildly by tool. You can view this detailed authoring tool xAPI breakdown from 2018, but we’ll explore a few of the most common options here.
You can publish an Articulate Storyline course as “Tin Can” output and host it on any xAPI-enabled LRS. Once this is done, user activity in the course will generate a hefty stream of pre-determined statements.
For example, the Storyline course will send xAPI statements to the LRS every time a user:
It’s important to note that you do not have any control over this data stream...which statements get sent are determined by the Articulate developers. Since a statement gets generated every time someone views a slide, the volume of statements produced by the default output can quickly bloat your LRS storage.
On top of this, you have no control over the verbs that are used by the xAPI statements. If you are generating statements from many different tools, for example, then you will have a hard time keeping track of which verbs refer to which activities.
You can learn how to send custom xAPI statements from Articulate Storyline with this guide.
You can also publish Articulate Rise courses as xAPI packages, but the statements you receive are very limited. Essentially, the xAPI output provides you the same start and completion data that the SCORM output provides.
To get more valuable xAPI data from Articulate Rise, you need to use custom code.
Adobe Captivate has similar out-of-the-box xAPI reporting to Articulate Storyline. However, Captivate does give you some control over the statements that you want generated: you get to choose whether you want to track each slide view and question response.
While turning this off may save you some storage space in your LRS, you still have little control over which statements are generated, and the data is not much more valuable than what you can already get with SCORM.
dominKnow One has the best out-of-the-box xAPI reporting capabilities by far. They have a statement builder that allows you to trigger an xAPI statement from any action, and this is currently the gold standard for what’s possible in an authoring tool without code.
However, the statement builder has one critical shortcoming: your verb choices are limited to a curated verb list. This is okay if you’re just dipping your toes in xAPI, but for serious use cases that require you to adhere to industry and organization-specific profiles, you may need to use different verbs.
While Unity is a popular tool to use with xAPI, it does not support xAPI out of the box. It is up to the developers to add custom code that generates xAPI statements when users perform the actions that you would like to track.
Adding custom code in this scenario allows you to collect xAPI statements from games, VR simulations, AR experiences, and more.
LMSs are another consideration when it comes to xAPI. If you want to host xAPI packages generated by an eLearning authoring tool, then you’re going to need an LMS that’s capable of hosting them.
However, if you are relying on an xAPI package generated from an authoring tool, then you should be good to go with most modern LMSs. These LMSs include:
Finally, there are a great selection of supporting tools that make it easier to send xAPI statements. Let’s take a look at several of them.
Zapier lets you send data from one tool to another, automatically. It integrates natively with thousands of tools, including a couple of LRSs (discussed in the Choosing an LRS section). Using Zapier, you can send xAPI data to and from any tool that has a Zapier integration.
For example, every time a salesperson takes an action in Salesforce, you can fire off an xAPI statement. Likewise, you can use a Landbot.io chatbot that looks at someone’s previous xAPI data so that it knows which learning experience to direct them to next.
Even if your LRS doesn’t have a Zapier integration, you can send xAPI statements using the Zapier Code Action. The only downside of using an LRS without a Zapier integration is that you will not be able to retrieve statements from the LRS and bring that data into other tools via Zapier (like in the chatbot example above).
The xAPI Lab is an xAPI statement generator. It lets you input each element of the xAPI statement via a convenient text input, and then it generates a full xAPI statement that you can send to an LRS.
This is a great tool to use as you learn about the different parts of an xAPI statement and what data they can hold.
The xAPI Bookmarklet lets you send xAPI statements from the webpages that you view. It adds an icon to your browser that, when clicked, sends a statement to the LRS of your choice; the statement will include details about the webpage you visited, the time it was accessed, and more.
xAPI data from videos can provide deep insight about user engagement and content effectiveness. To make getting this data easier, ADL created a YouTube to xAPI tool that makes it possible to automatically send xAPI statements from YouTube videos via YouTube’s iframe API.
If you would like to learn more about xAPI, then there are some great resources at your disposal. Let’s consider a few of them.
If you’re interested in the technical implementation of xAPI, then you’ll love my Full Guide to xAPI and Storyline. This is where I dive deep into writing your first statement, adding more detail to your statement, and sending statements from Articulate Storyline courses.
Check it out if you want to start sending custom xAPI statements on your own.
TorranceLearning hosts two 12-week xAPI learning cohorts per year. During the cohort, you attend weekly webinars from xAPI experts and participate in hands-on xAPI projects with other attendees.
Xapi.com has a wealth of information on xAPI. The site includes technical deep dives, beginner articles, case studies, and more. They also include xAPI-enabled prototypes and tools.
If there’s something to know about xAPI, you can probably find it on the xapi.com website.
Anthony Altieri has a great xAPI course on LinkedIn Learning. Similar to my Full Guide to xAPI and Storyline, this course gets technical. It’s intended for people who are going to implement xAPI by writing code themselves.
The Australian xAPI User Group is a community of L&D practitioners that contributes to the adoption of xAPI. They share information and help with xAPI implementation, so it's a great community to get involved with if you're interested in xAPI (especially if you're in Australia).
The xAPI specification brings L&D into the data-rich world that other professions have been immersed in for some years now. xAPI data enables organizations to use a data-driven approach to their learning design, and it can help them focus their efforts on the tasks that produce the largest impact.
If you need a hand implementing xAPI at your organization for the first time or resolving a tough technical xAPI and eLearning task, then please contact me for a free consultation.