By Megan Walker, Senior Product Manager D2L
Originally published 3-Sept-2020
In the September 2020 release, we will introduce the concept of system access in several places in Brightspace.
- As a Brightspace Data Set: System Access Log
- As a column in Class Progress
- As a page in User Progress
System access is very similar to sessions which we will discuss more in this post. The value of this new metric is that it captures system access wherever it occurs. Today, this could be in Brightspace using a browser or in the Pulse app. Prior to this change, login data was often used to indicate usage, which can be misleading in some cases.
When using Brightspace within a browser, a user is asked to log in every time they access the platform, meaning that all sessions have a corresponding login. When using our apps however, a user will log in once and then have a persistent authorization token so that a log in is not required every time the app is opened. Try this out with any app on your phone. Most keep you logged in persistently outside of something like a banking app. This means that a single login corresponds to many sessions where the login could have occurred a year ago and the most recent session happened this morning. This is where just looking at logins as an indication of use is misleading if your users often use Pulse.
Another pre-existing metric is sessions. There are a couple problems with this metric. First, only sessions in Brightspace are logged, which leaves a large gap when your users rely on one of our apps such as Pulse. The second issue is that we rely on a configuration variable value (d2l.SessionTimeout) to know when the session should time out due to inactivity. This configuration value is great for security purposes especially when using shared computers. However, it is not a good representation of how users use the platform because it is often much longer than an industry standard session time. Our research and industry knowledge tells us that 30 minutes of inactivity is a good indication that the user is no longer engaged, compared to 90 minutes which is what a client’s timeout variable is set to on average. This significant difference can inflate session duration and leaves you in the dark as to how often the user re-engages during that time.
This brings us to the new metric: system access. While very similar to sessions, we chose a new name here in order to differentiate it from the pre-existing sessions metric and to reduce disruption to our users who rely on sessions for reporting. System access respects the industry standard of 30 minutes of inactivity indicating that a user has concluded their access. It also captures access of Brightspace and Pulse. While your timeout for security will still be respected, you may see that several system accesses occur during a single session if the user has multiple periods of inactivity that last more than 30 minutes in that time. We will begin capturing this data for Brightspace and Pulse in the September 2020 release.
Our research shows that the following questions, listed in priority order, are important to you when it comes to how users engage in our platform.
- When was the last time someone accessed the platform?
- How does that access trend over time?
- How long does the access last? (interest was shown here but few use this metric at present time)
Our new system access metric allows you to answer each of these questions using the System Access Log Brightspace Data Set. You can also answer the first two questions by looking at Class and User Progress at the course level.
Figure: Class Progress Example with System Access
Figure: User Progress Example with System Access
To summarize, below is a visual representation of the 3 metrics discussed and their definitions.
Figure: Example of metrics across Brightspace and Pulse
Logins
App: Occurs initially and then rarely because the auth token persists.
Brightspace: Occurs every time a user returns to Brightspace and enters their credentials.
Session
App: Not applicable or counted.
Brightspace: Begins following a successful login. Ends after the session times out due to the configured time being reached, the user logs out or the session is force ended by an administrator.
System Access
App: Begins every time a user launches the app when it has been >30 mins since last launch. Ends when the app has been in the background for >30 mins or the user logs out.
Brightspace: Begins following a successful login or re-engaging with the platform after >30 mins inactivity. Ends after the session times out, the user logs out, the session is force ended by an administrator or when the last activity occurred when there has been >30 mins of inactivity.
Call to Action
As a recommended take away from this change, we recommend shifting from relying on login or session data to indicate usage to system access. This will give all usage credit and provide more consistency in your usage data.
