When it comes to tracking eLearning experiences, most learning terms rely on data from a Learning Management System (LMS).
The LMS can tell you how many people completed the eLearning experience, the score that they achieved, and more. However, the LMS can only give you that data when you host your eLearning on the LMS.
You may not have an LMS, or you may want to host your eLearning experience on a regular website or your company’s intranet so that it's easier to access.
With the techniques in this article, you can track completions, question responses, and so much more — all without an LMS. This enables you to collect data from projects created with Articulate Storyline, Adobe Captivate, and any other authoring tools that have HTML output.
Let’s get started!
The first data-collection technique is also the simplest: an embedded form.
With this technique, you first create a form with third-party software that’s designed for creating forms. Then, you embed the form on a slide in your project.
For example, if you’re trying to determine who has accessed the eLearning, you could create a form that asks the user for their name and email address. You would then embed this form on one of the first slides of the course.
The good part about this method is that it is easy to implement and relatively cheap (or even completely free). The downside is that your form will not be able to communicate with your course.
Since the form is created with a different tool, your eLearning course will not be able to “listen” to the form inputs. So, if your user does not enter their name or email, then there is no way that you could stop them from proceeding.
They would be able to select that next button and move on, completely untracked.
So, while there is no guarantee that people would actually submit the requested information (and there is no way to enforce it), this is still a low-effort, lightweight way to collect simple information from your audience.
The other downside is that the form may not match the look-and-feel of your eLearning course. Since the customization options are more limited with form-building tools, it will often be obvious that the form was created with a different tool.
This is not a huge deal, but for projects where branding and look-and-feel are important, you may want to go with an option that is more consistent and user-friendly.
If you want to proceed with this approach, then the first thing to do would be to select an appropriate form-building tool. Google Forms is a great free option, and Typeform is one of the most popular paid options.
After creating the form, you need to embed it in your course. You can get the embed code from the form’s share options.
To do this in Google Forms, you’d select the “Send” button, then go to the tab with two brackets (< >). This is where you’ll find the HTML code that you need to embed in your course.
Once you’ve copied the code, go to your authoring tool of choice and locate the option to embed a web object. It will present you with a dialogue box for code, and that’s where you would paste this embed code.
And voila! Upon publishing, the form displays in your eLearning course. When a user submits data, it goes to the tool that you used to create the form.
You can use Google Analytics to track the raw number of people that access your eLearning course. This is a good, relatively easy way to see the raw number of “hits” that your eLearning project receives.
Google Analytics is completely free and relatively easy to set up. It also includes built-in data visualizations and reporting capabilities.
However, the default, out-of-the-box reporting is limited. You can see how many people load the course, where they’re accessing it from, and which devices they’re using, but you will not get a very clear idea of what they’re doing in the course.
For example, whether someone leaves the course on the course’s title screen or on the last slide of the course, it would still count as a single hit.
Overall, the biggest downside with this approach is that you cannot tie activities to specific users. The data is always faceless and aggregated. You may see that 1,000 people completed your course, but you will not know their names or email addresses.
If you need person-level data, then this approach will not be sufficient for your needs.
If you want to take the tracking to the next level with custom events, then you can check out Google’s documentation on events.
With a bit more technical know-how, you can collect data from your eLearning project in a Google Sheet. Essentially, the sheet serves as a mini database for your project.
For example, you can request the user’s name and email address with text entry boxes in an Articulate Storyline course, then you can send that data to the Google Sheet. You can also include question responses and any other data from an eLearning course.
The biggest selling point with Google Sheets is that it’s completely free to use, the data is accessible in a simple spreadsheet, and you can collect any data you’d like.
This means that you can lock progression until the user enters the requested information; once it’s entered appropriately, you can send that data to a Google Sheet.
The other downside is that this approach is not very secure. Since the Google Sheet API key would be stored in the course files, a tech-savvy developer would be able to query the Google Sheet and read the data within.
You can send data to Google Sheets with the Google Sheets API. The best place to get started with this is the official documentation.
Once you have the data stored in the appropriate variables, you must execute a POST request that sends the data to the Google Sheet.
xAPI is a technical specification for the learning industry, and it is the most comprehensive way to collect data from eLearning without an LMS.
This approach lets you collect data about every aspect of your eLearning experience, and it stores that data in a Learning Record Store (LRS). An LRS is a database tool that’s designed to hold xAPI data.
xAPI was designed for people to collect data from learning experiences, so it was tailor-made for this use-case. It is completely flexible, which means that you can collect data such as:
In addition to this flexibility, the specification gives you a proper format to store the data. This makes it easy for people who know xAPI to quickly make sense of the data, and it makes it easy for LRSs to visualize that data for you.
xAPI is also more secure because most LRSs let you turn off “read” permissions. This means that people will be able to send data to your LRS, but even tech-savvy developers will not be able to pull that sensitive data back from the LRS.
In addition to this, if you have a large number of users, then you will likely have to pay for an LRS that can handle all of the xAPI data your course would generate.
Whether or not the added cost is worth it will depend on your project budget and needs. If you were already thinking about diving in to xAPI, then this approach is a great way to use data-collection best practices from the beginning.
I’m also working on a newer, updated guide that is not Storyline-specific. Feel free to subscribe to my mailing list if you would like to receive an update when this guide is ready.
As you can see, there are multiple options for collecting data from learning experiences without an LMS. These options range in cost, complexity, and capability.
As a recap, the main options are:
If you need a hand implementing any of these data collection methods or deciding which option is best for you, then join the ID community to ask thousands of instructional designers to share their experience to help you find a solution.