The Learning & Development industry uses the Experience API (xAPI) to collect learning and performance data. Most commonly, we use xAPI to track how people interact with eLearning. This is accomplished either by using the limited out-of-the-box reporting or taking advantage of custom code for much more nuanced tracking.
However, it’s possible to send custom xAPI statements from tools that we use every day — all without writing a single line of code. Imagine sending xAPI statements from Slack, Salesforce, Google Sheets, Google Drive, and thousands of other apps. Here are some examples of what’s possible:
When you pair data like this with the rest of the learning and performance data in your Learning Record Store (LRS), you can draw powerful conclusions about productivity, social learning, and learning effectiveness.
Collecting xAPI data from all of these tools without code is made possible by a tool called Zapier.
Zapier is the no-code glue that makes thousands of tools work together. You use Zapier to create “Zaps” that trigger actions in one tool based on an event that occurs in another tool. The best part about this is that you can share data between the tools.
We are able to send xAPI statements from these tools via the Watershed Learning Record Store (LRS) Zapier integration. This integration makes it easy for us to combine any of the thousands of other apps with Watershed LRS to generate xAPI statements.
Let’s break this down further. There are two key parts to any Zap: the trigger and the action. The trigger is the event that causes the action to fire.
For example, whenever someone sends a Slack message in a specific channel (the trigger), we can use Watershed LRS to generate an xAPI statement that includes the user’s message (the action).
It’s possible to include the contents of the Slack message because Zapier can collect data from the tool that’s triggering the action (Slack), and then you can use that data however you’d like in the tool that’s performing the action (Watershed LRS).
Therefore, we can take the user’s name, the user’s message, and the timestamp from Slack, and we can insert that data wherever we would like to in the xAPI statement that we generate with Watershed LRS.
Since you will still need to make decisions about which data to include and where to include it in the xAPI statement, it’s a good idea to learn how xAPI statements are structured and defined.
If you know where the data goes in the xAPI statement, then accomplishing this with Zapier is fairly easy and straightforward (especially if you’re using the native Watershed LRS Zapier integration).
To see an example of this technique in action, view this Sending an xAPI Statement from a Glide App Button tutorial that I wrote.
Is it possible to use this technique if you use an LRS that’s not Watershed? Yes, you can send xAPI statements with Zapier to any LRS on the market. There are two ways to accomplish this:
In conclusion, you can send custom xAPI statements from many of your favorite apps without writing a single line of code. This is made possible by Zapier, which lets you trigger xAPI statements from thousands of different tools.
To do this effectively, you will need a basic handle on how an xAPI statement is structured. This is because you need to place data from the tool in the appropriate parts of the xAPI statement.
If you have any questions about this approach, feel free to join the ID community and ask away. Sign up for my mailing list below if you want to be the first to know whenever I post a new article or tutorial.