In addition to introducing Watershed’s latest L&D report features, we’re equally excited to announce new features that not only support Watershed’s performance and scalability, but also provide extra data security options. This post explores some of the more-technical, under-the-hood features that we’ve developed during the last year.
Recommended Reading
Add an extra layer of data protection with statement queuing.
This feature adds an extra layer of protection to ensure your xAPI data is always received by our learning record store (LRS), even during periods of extremely high volumes of requests.
Why does it matter?
In rare instances, some clients may occasionally go over our rate limits and send Watershed more than 3,000 requests (to a single activity provider) a minute (a rate of one every 0.02 seconds). This can happen, for example, when hundreds of learners all launch a new eLearning course at exactly the same time.
However, this new feature means that even if you do send us high volumes of requests (i.e. more than 3,000 requests per minute), you won’t lose any xAPI data—but it might be delayed for a few minutes.
Hint: Remember to follow the best practices outlined in our xAPI Implementation Guide.
What’s changed?
Now, in the event of extremely high volumes of xAPI statement requests, the LRS will queue the data instead of rejecting it.
Note that normal data volumes are generally nowhere near 3,000 requests per minute. So it’s unlikely that most clients will ever need this feature.
Note, that this queuing only affects requests sent to the xAPI statement endpoints, any other requests sent to Watershed that go over the rate limit will not be queued and will be rejected with a standard “429 Too Many Requests” response.
How do I do it?
You don’t have to do anything to turn this feature on, it will kick in automatically if it’s needed. Read more.
Use distinct count measures in your L&D reports.
You can now configure Watershed distinct count measures to be 100% precise instead of close estimates.
Why does it matter?
In most practical cases, using an almost-accurate number in reporting is the norm. However, in rare circumstances, using an exact count is needed—even when it requires a longer load time.
For instance, consider course completions. Let’s say you plan to review all courses with more than 10,000 completions as examples of popular courses.
A report shows that 11,345 people have completed a particular course. If the actual figure is 11,347, those two missing completions are unlikely to impact your next steps. It’s still a popular course with many completions. (Any lists you produce of people who have not completed the course will still include all the people, only counts are affected.)
How many of the 1,500 squares in the following picture are blue? You can count them all, but it’s faster to count a sample of 100 then multiply by 15. (The answer is 180).
ALTERNATE: How many of the 6,000 squares in the following picture are blue? You can count them all, but it’s much faster to count a sample of 100 then multiply by 60. (The answer is 720).
But when you need to know the exact number, you now have a configuration setting. Your report will just take longer to load, because Watershed is counting the whole dataset instead of taking a sample. (Load times will vary depending on the number of statements.)
What’s changed?
Previously, you could only count every item in data sets of up to 10,000 items. But now, you can configure distinct count measures to count every item instead of making estimations when the data set is larger than the configured precision threshold (the default precision threshold is 1,000 items).
How do I do it?
This feature requires advanced configuration to set up. Visit our knowledge base to learn more about this process.
Evaluate up to 300,000 learners in a single Program report.
You can now use one Program report to keep track of populations of up to 300,000 learners.
Why does it matter?
Easily report on up to 300,000 learners in a single Program report. Of course, you can still report on the progress of more than 300,000 learners, but you’ll need to split them across multiple reports.
What’s changed?
We’ve increased the learner limit for Program reports from 200,000 learners to 300,000 learners. While other report types do not limit the number of people you can report on, this limit ensures that Program reports load in a reasonable time.
How do I do it?
This limit is increased on all program reports by default, so just make sure that the populations you configure for program reports are below 300,000 people.
Restrict LRS credentials to write only and read only.
In addition to Watershed’s existing permission options, you can now restrict permissions on a set of LRS credentials to read only or write only.
Read and write permissions allow data to be both written to and read from the LRS. Read-only permissions prevent the activity provider from writing data to the LRS. Write-only permissions prevent the activity provider from reading data from the LRS.
Why does it matter?
These new permissions give you greater flexibility to control what activity provides are able to do in terms of sending and receiving data.
What’s changed?
Previous permissions were either disabled, isolated, or global. As a result, activity providers could either write statements and read back their own statements, or write statements and read any statements.
Two new levels of permission have been added:
- Global read only. This allows the activity provider to read all the data, but not send statements to the learning record store. This could be used, for example, to pull statements to another LRS or to display xAPI data in another tool.
- Write only. This allows the activity provider to send data to the LRS, but not read it. Any activity providers that do not have a requirement to read xAPI data back from the LRS (i.e. most activity providers) should use this setting.
We recommended using server-side tracking to help ensure the security of credentials (see our xAPI Implementation Guide for more details). But even then, using minimally scoped credentials is still good practice.
How do I do it?
LRS activity provider credentials are configured on the Data / xAPI Data settings page. To edit the permissions of a set of credentials, click edit and then select the appropriate permissions from the LRS Access drop down. Read more.
Helpful Tip: Take some time now to review your xAPI activity provider permissions in Watershed to see if you should apply any of the new options to them.
Try these new Watershed features for yourself!
This series has outlined the new features we’ve released this year for reports, report building, and for performance, scale, and security. Check out the following video to see these features in action. And if you have questions about how to use these features, you’ll find full documentation on our knowledge base. You also can login to your Watershed account now to get started.
About the author
As a co-author of xAPI, Andrew has been instrumental in revolutionizing the way we approach data-driven learning design. With his extensive background in instructional design and development, he’s an expert in crafting engaging learning experiences and a master at building robust learning platforms in both corporate and academic environments. Andrew’s journey began with a simple belief: learning should be meaningful, measurable, and, most importantly, enjoyable. This belief has led him to work with some of the industry’s most innovative organizations and thought leaders, helping them unlock the true potential of their learning strategies. Andrew has also shared his insights at conferences and workshops across the globe, empowering others to harness the power of data in their own learning initiatives.
Subscribe to our blog