System Usage Overview
The System Usage Overview report page presents the visuals listed below. Each row gives the on-screen name, its underlying metric, and a short description; see the metric glossary for the full formula and interpretation.
Visuals:
| Name | Measure | Description |
|---|---|---|
| Total active users | Count of worker IDs | Number of users in scope, used as the denominator for the adoption percentages (for example % users having plans ). It sets the "out of how many people" baseline, so every share on the page is read against it. Filtering to a team or org unit re-bases it to that population. |
| Users having logged in | Count of distinct users who signed in÷ count of all users | Share of the user directory that has actually signed in, the login rate. It puts Unique Logins in context so groups of different sizes compare fairly, answering "what proportion of the people who could use the platform did." A low or falling rate flags an activation gap; it says nothing about how often those users return (that is the average-logins measure). |
| Data Privacy acceptance | Count of users where [Has Accepted Data Privacy] = Yes÷ count of all active users | Share of users in the directory who have accepted the data-privacy statement; i.e. the consent rate. It puts the raw count in context so groups of different sizes compare fairly; a low or falling rate flags a consent gap to chase. |
| Device usage | For each platform, count of distinct users who signed in on that platform÷ count of all users | Channel mix of your user base by reach: how many distinct people used each platform to sign in (desktop/iPhone/Android/Outlook/Teams), displayed as a donut so each is a share of the whole. It counts people, not sessions, so it tells you where users actually work from rather than raw traffic. One caveat on the shares: a user who signs in from more than one platform is counted in each slice, so the slices can add up to more than the unique-user total, and the percentages describe per-platform reach rather than a clean split. |
| First Time Logins over time | Count of connection IDs, by date (one point per period) | Same sign-in event count as # logins , broken out along a date axis so you can see activity rise and fall period by period. Each point is the logins in that bucket (not a running total), so the points sum back to the single # Logins figure. Read it for trends and seasonality in usage; pair it with the cumulative first-time-login curve to tell repeat activity apart from new adoption. |
| Active users by role | Count of worker IDs | Number of users in scope, used as the denominator for the adoption percentages (for example % users having plans ). It sets the "out of how many people" baseline, so every share on the page is read against it. Filtering to a team or org unit re-bases it to that population. |
| First-time logins over time (cumulative) | Count of connection IDs, by date (one point per period) | Same sign-in event count as # logins , broken out along a date axis so you can see activity rise and fall period by period. Each point is the logins in that bucket (not a running total), so the points sum back to the single # Logins figure. Read it for trends and seasonality in usage; pair it with the cumulative first-time-login curve to tell repeat activity apart from new adoption. |
| Functionality usage | For each of the three core features, count of users who used it÷ count of active users | Share of the user base that has adopted each core feature (feedback, goals, check-ins), shown side by side so uptake can be compared across the three. It plots the three existing adoption rates ( % Users Used Feedback , % Users Having Goals , % Users Having Check-ins ) together, and the hover tooltip shows the underlying counts. Read against # of active users for the population each share is based on. |
| Last data refresh | Timestamp of the most recent successful data refresh | Shows when the report data was last refreshed, so readers know how current every figure on the page is. It is a freshness stamp, not a business metric. Read against your expected refresh schedule to spot stale data. |