A learner has multiple accounts that require different login IDs. So, if you're tracking a single learner across many systems, how will your LRS know that the various login identifiers are for the same person so you can report on all of his or her learning?
Learning happens everywhere and with various accounts and identifiers. For instance, I might use one account on my LMS, my employee ID on the intranet, my email address on a social learning platform, and my personal email when to register for a learning website or MOOC.
With all these identifiers it’s difficult to know for sure if Sue Smith on the LMS is the same as email@example.com, or whether that’s actually the other Sue Smith who works in the warehouse. But wait, didn’t one of them recently get married and now goes by Susan Doe? And what about Steve Smith in engineering—maybe that’s his email address? Keeping learners, accounts, and IDs straight gets complicated quickly.
When it’s time to report on your data, you don’t want to be concerned about matching identifiers with learners. You just want to select “Sue Smith” from a list of names, check that she’s the one on Bob’s team, and then see all of Sue’s data from all of your systems. So, how can you make that happen?
xAPI, or Experience API, was designed with built-in features to help resolve this challenge. First, it recognizes the problem and dictates that all learning data be associated with a single identifier called a “persona." A persona is one aspect of a person, as represented by a single identifier. The concept of personas can be a little confusing, but help is at hand. Brian Miller explained the concept on the Tin Can blog back in 2013 and I wrote about it again in 2015.
By associating each learning record with a single persona, the Experience API keeps the data tidy. However, there’s still the problem of linking those personas together, so the Experience API allows the LRS to maintain a record of which personas are linked. This record can be accessed via xAPI using the Agent Profile resource.
xAPI doesn’t restrict the LRS when it comes to determining associations between personas, and it’s up to LRS vendors to effectively implement this feature. This is commonly done by integration with a system of record, such as an HR system. (The details of Watershed’s approach are outlined in the following section.)
Version 1.0.3 of the xAPI specification includes a diagram that explains the concept of personas and people. Below is a copy of that diagram.
What about Watershed?
You won’t see separate personas when interacting with Watershed reports. Instead, you’ll simply see a list of people with their learning data, regardless of a particular persona identifier used to record that data. You can filter reports by selected individuals, and you can organize reports by person to compare and rank individual learners.
These options are possible because Watershed maintains a list of personas associated with each person (see the diagram above). This data can be collected via an API integration with a system of record, such as HRIS, uploading a CSV file of identifiers matching each person, or a combination of the two. A list of personas associated with each person can then be viewed when exploring groups and people on the Your Organization page.
So that’s all there is to it. Use whatever persona identifier is most appropriate when collecting the data and use Watershed’s API or CSV upload to connect personas under a single person. When it comes to reports, you’ll see all the data about the person together, regardless of which identifier was used to collect that data. Awesome!
About the author
Subscribe to our blog