Inventory Dashboard Usage
Updated
by
Rico
What is an Event?
In general, we have 4 different types of “usage” events that we collect:
- Load Events - when a user loads a page or the url of the page changes
- Minutes on System (MOS) Events - tracks the number of seconds that a user spends using a particular product (which could span multiple url changes)
- iOS App Events - any network request initiated by an app, which is roughly equivalent to usage (in theory - apps don’t always request new data when users interact with the app)
- iOS Web Events - any network request initiated by mobile safari. This is analogous to Load Events.
* We also collect some data about internet speeds, but this is not visible in the LearnPlatform.
Load and MOS events are collected only in the Chrome Extension and iOS App and Web events are only collected by the LearnPlatform iOS App.
What Constitutes a Usage Event?
Chrome Extension
The chrome extension listens for 3 types of actions from the user:
- A tab is “activated” - this happens when a user switches tabs
- A tab’s url is updated - i.e. the user navigates to a different page or in some cases (like a single-page-app (SPA)) the user performs an action on the page which updates the url
- The current window changes - if the user has multiple Chrome windows open and switches between them (or switches away from Chrome)
When any of these actions occurs, we attempt to lookup the url and match it against our list of tracking domains. We take the best match and then do 2 things:
- For Load Events, we increment a counter for the product. i.e. one url change is a single load event.
- For Minutes on System (MOS) Events, we start or resume an “active” session for that product. This allows us to track “how long” by accumulating the time that a session is active.
Every 60 seconds we take all the usage data that we’ve collected and then send them to LearnPlatform. Each time we send we clear all the existing usage information from the chrome extension so that it does not accumulate and cause performance problems.
iOS App
In the iOS app we use the Web Content Filter - this essentially sends us ALL network traffic. For each network request, we inspect the url and the bundle id to determine if it’s an iOS App or iOS Web Usage Event. We then match that url or bundle id against our list of products and track usage based on that.
Bear in mind that we’re using network traffic as an approximation of “usage”. Not every app will send a network request when the user interacts with the app and not every network request is initiated by the user (e.g. an app might refresh data in the background). This is a “best guess” given the limitations in Apple’s ecosystem, but gives us a way to gauge usage in broad terms.
When Would We Not Send Data?
Chrome Extension
User Email Missing
We might not send data if the user’s profile does not have an email address. We use the Chrome Profile to obtain the user’s email address (rather than asking them to log in). If the identity of the user cannot be determined, then we won’t send usage information.
Background Requests Not Captured
Another key difference between the Chrome Extension and the iOS Extension is how we handle background requests. In the Chrome Extension, “background” requests (i.e. any network requests that are not the main page url) DO NOT generate load events, so this data is not collected.
iOS Extension
The most common cause would be requests being blocked by the District’s network or device policies. As long as the user’s device is setup correctly per our installation instructions, the iOS app should send data regularly.
