Questions? We've got you covered
Often, the first decision you’ll need to make is whether you want to host your own LRS, or use an online service.
An online service will be quicker to set-up, probably cheaper short-term (unless your labourer cost is zero) and, will be tried and tested. However, you will need to be comfortable with data storage/ownership responsibilities and, you’ll need to be comfortable with the medium-long term costs of continually paying for a service.
It’s really easy to imagine that little bits of JSON containing xAPI statements won’t add up to much data. And, in the singular, you’d be right.
Most xAPI statements are around 2KB in storage size (though, we have seen statements 10x this size!), meaning you’ll be able to store around 500,000 statements per GB; equivalent to 1,000 learners generating 500 xAPI statements per month.
But, if you are making a million xAPI statements a day, this is going to add up to GBs of data in a matter of moments.
Whilst cloud-based storage is generally very cheap, the technology required to run an LRS at scale does not run well on very basic equipment. (For example, the SaaS version of Learning Locker® actually runs on 12 virtual machines at a minimum).
There is a trade-off between the quantity of data you collect and the level of detail you require in your xAPI statements. Storing more than you absolutely need can be wasteful.
Don’t forget archiving…
Because xAPI is an immutable specification (you can’t edit or delete stored statements) your data set is just going to grow. To keep costs down and keep servers running efficiently, you’ll need to develop a process for archiving old data. If you don’t, the LRS is going to get pretty big in years 2, 3, 4… For reference, Learning Locker® SaaS LRS is priced on a ‘per GB of stored data’, so you pay $115 for each GB up to 10GB, then the price per GB decreases. This model allows you to start with a hosted LRS and a modest budget whilst you see how much you use. Then you can always switch to an on-premise deployment if cost is becoming a factor.
Data security remains a hot topic and your Learning Record Store is no exception to the trend. You should consider how your xAPI data is secured whilst in-transit to the LRS and, how it is secured at-rest in the database.
There is literally no excuse to not use SSL whilst sending xAPI data to the LRS and, most cloud providers (including Learning Locker®) will offer you encryption-at-rest.
When implementing xAPI, you should become hyper-aware of your organization’s data protection privacy policies and the geographic differences that might occur.
For example, does your organization require data to be stored in a particular geographic location? Or, perhaps more likely, are there particular areas of the world you are required to avoid storing your data-at-rest?
The LRS quickly becomes a key part of your infrastructure. If you are storing all organizational learning data on it, then you really can’t afford for it to go down, or worse, to lose data.
The killer question for redundancy and backup is always how much data can I afford to lose?
Of course, the preferred answer is ‘none’ but, that tends to be unrealistic in the face of cost/benefit analysis.
In the worse-case scenario, how much data could I afford to lope and hope to recover normal operating practice?
For many circumstances, putting in some fall-over mechanism and also doing off-site daily backups is enough. But, in high-risk or testing environments, even that might not be.
How can I do backups more than once a day? How can I achieve this without breaking the bank?
If you’re on self-hosting, backups more than once a day is achievable. If you’re on cloud-hosting you can ask us to do backups more than once a day. To reduce costs, we would recommended deleting old backups that are no longer needed.
The Enterprise Edition of Learning Locker® features exclusive tools for rich insight and substantial technical support. These features are as follows:
Advanced Business Rules (Journeys)
A key feature of the Enterprise Edition is the ability to extend WebHooks into Journeys.
This allows you to specify multiple criteria that learners must meet in order to trigger an outcome. You can visualize a learner’s progress through a journey right back in the Learning Locker® GUI and to get grips with measuring more complex performance indicators, such as ‘time to competence’.
Managed Hosting & Support
Our Enterprise Edition is available both on-premise and fully managed.
Whilst we default to AWS as a de-facto service provider, we can use Google, Azure and Rackspace on-demand. We can use data centers located throughout the world dependant on your geographical need and, we have all of the Enterprise security certifications you would expect of an Enterprise software partner; ISO27001, ISO9001 and SOCI/II through out hosting providers.
When hosting with us, we offer a 99.5% uptime guarantee, 24×7 hardware support and office hours technical support over the phone and via our online helpdesk.
Our Customer Success team is our free consultancy service to help you make the most of Learning Locker®. You can call on our team to ask any questions about xAPI, LRSs or overall system architecture principles.
Transformation Pipelines: We build custom transformation pipelines for your data.
These take data from non-xAPI sources (either in API or CSV format) and transform activity data to the xAPI specification for storage in your Learning Locker®. We’ve worked with data from Yammer, Slack, SalesForce, Skillsoft, Degreed and more to take data into Learning Locker® from the services you already use, with no work to do.
Content Launcher: Securely launch your xAPI content.
We’ve built a service that uses the ADL launcher specification to pass authenticated user details to an eLearning content package and track activity back to the LRS. This service acts as a proxy, obscuring the actual location of the LRS and limiting client-side access to xAPI authentication details. A must have for anyone launching xAPI content on the client-side.
Business Intelligence Integration: Provides you with direct database access to BI tools.
We use BI connectors to take data directly from our hosted Learning Locker® instances to popular BI tools like Tableau, Power BI and more. Data connections work in real-time with no need for bulk loading or batch jobs.
A Learning Record Store, such as Learning Locker®, is a database that stores and retrieves data produced in the xAPI format.
In an ecosystem where training portals, mobiles, LMSs and other technologies are all submitting “statements” on a moment-by-moment basis, the LRS is a key piece of infrastructure that requires high availability and high reliability?
It feels like you must be tracking everything but somehow key data points get lost along the way and you find yourself with all sorts of expensive compliance issues.
Potentially even worse, the data you do have might not be timely or accurate. With no real standard way of collecting data in your organization, it’s up to your vendors to have done a good job in standardizing and storing data.
You’ve got no other way to get data from one system to another. Adding in another system just gives rise to more headaches with the first two problems. And migrating to a new LMS? – Forget about it!
You won’t need an LRS until you’ve got at least one system producing xAPI statements. But, as soon as you start producing xAPI statements, you’ll need an LRS to store them. LRSs are designed to be interoperable. You can run more than one at once and share data or, readily transfer data out from one to another, assuming that the data in the LRS is valid.
There are a number of fundamental differences between an LMS and an LRS that mean you won’t be getting rid of your LMS anytime soon:
Your LMS will also probably deal with launching eLearning content packages. This is not part of the xAPI specification and doesn’t form part of any standard LRS.
It’s important to note that the term LRS is quite specific:Where Learning Management System ((LMS) can be used to refer to a range of vastly different products, LRS refers to a distinct piece of software that adheres strictly to the xAPI specification for an LRS. There is essentially a recipe card for building an LRS; if it omits part of the spec or tweaks it in some non-standard way, it’s not an LRS.
Cross Platform Interconnectivity
This is a key part of what allows the LRS to produce such rich, useful insight into learning experiences. By collecting data across websites, apps LMSs and even from offline activities, the LRS paints a holistic picture of learning by accepting data from various touchpoints at which learning occurs.
Rich Learning Insights
Because the LRS can be integrated with so many touchpoints using xAPI, it is able to produce highly detailed learning analytics and insights by aggregating data from various sources. Beyond the benefit to the individual learner, institutions can use this rich data to make informed, strategic improvements from everything to sales training to future learning design.
In any context, a deep understanding of the competencies and weaknesses of your learners (provided by xAPI) comes with the ability to personalize and optimize their learning experience. This allows you to provide learners with the help that they need, when they need it, in addition to rewarding successful learning achievements in real time.
The Experience API (or xAPI for short), is a specification document created by a consortium of learning experts led by the Advanced Distributed Learning Initiative (ADL).
Whilst the document was being formed its prototype name was ‘project Tin Can’, but these days it is known by its official name, xAPI.
In an xAPI world, we talk about 3 key components: Activity Providers (APs), Learning Record Stores (LRSs) and, Activity Consumers (ACs).
Activity Providers (APs) create data in the xAPI format and submit it to the LRS. APs are systems and applications on which learning activities/events take place. Learning content, portals, apps and more can all behave as ‘Activity Providers’. In an xAPI ecosystem we expect many APs to be submitting data to the LRS at the same time.
Learning Record Stores (LRSs) are databases that verify that the input matches the xAPI specification, storing all valid data for retrieval by Activity Consumers, or by administrative users who wish to access the ‘raw’ xAPI data for analysis.
Activity Consumers (ACs) are similar systems to Activity Providers (an AP could in fact be an AC as well), in that they are typically systems and applications that modify the user experience based on xAPI data. This might be an LMS that ‘checks off’ a completed learning activity, because that activity appears in the LRS. Or it could be something more complex; a leaderboard, a badge issuing system or learning content.
At the heart of xAPI are Activity Statements. These are human-readable snippets of data that track an event. They are made up of three essential components:
Actor (e.g. Ben) Verb (e.g. read) Object (e.g. about xAPI)
Simple, eh? Well, there is a bit more to it than that…
Each Activity Statement can store a very wide-range of meta-data (that’s data about data) to explain the context in which an activity occurred. So, we can also be tracking the platform Ben was using, the time of day, the length of time he took, how many pages he read, whether he liked it or not and even, what device he was using.
All of that, and more, is possible using standard xAPI language.
You are probably already using a specification like SCORM to track some learning data. The Experience API has a number of advantages over the traditional SCORM method of tracking and recording learner activity, most notably the ability to record any type of learning activity whenever and wherever it takes place.
As well as providing extended tracking options, the xAPI also provides a number of other benefits, including: