Performance Executive Summary
The Performance Executive Summary 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 |
|---|---|---|
| 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). |
| Users having goals | Count of distinct goal owners (workers with at least one goal)÷ count of all people in the directory | Share of the population that owns a goal; i.e. the goal-setting adoption rate. It puts # Users having goals in context so groups of different sizes compare fairly, answering "what proportion of our people have set any goal." A low or falling rate flags a goal-setting gap; its complement is % Users having no goals . |
| Users having aligned goals | Count of distinct workers who own at least one aligned goal (Is Aligned = 1)÷ count of all people in the directory | Share of the population who own at least one goal that is aligned to a parent or company goal, i.e. how widely people connect their goals to something higher up. It measures cascade/alignment reach across people, not the share of goals that are aligned (that's a goal-level measure). A low value means goals are being set in isolation rather than tied to broader objectives. Shared goals: counts goal owners who have an aligned goal, by owner attribution. A goal shared with a worker does not make them count; a goal they own and shared out still counts if it is aligned. Own aligned goals only. |
| Cumulative First Time Login 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. |
| Users having feedback | Count of distinct workers who sent or requested feedback÷ count of all people in the directory | Share of the population who actively used the feedback feature by giving or requesting, i.e. the feedback adoption rate. It puts # Users used feedback in context so groups of different sizes compare fairly; a low value flags feedback not catching on. Receive-only participation is excluded, so it reflects active use, not exposure. |
| Users having check-ins | Count of distinct people who took part in a check-in÷ count of all workers | Share of the workforce who participated in at least one check-in, i.e. the check-in adoption rate. It puts # Users having check-ins in context so groups of different sizes compare fairly; a low value flags check-ins not catching on. A person with many check-ins still counts once in the numerator. |
| Check-ins having messages | Count of check-ins where has-message flag = Yes÷ count of all check-ins | Share of check-ins that include a written message, i.e. how many carry a qualitative comment rather than just a status or rating. It puts # Check-ins having comments in context so periods with different check-in volumes compare fairly; a low rate means check-ins are mostly quick tick-box entries with little written detail. Read against % Discussion points to gauge overall check-in richness. |
| Device usage | For each platform, count of distinct users who signed in on that platform | 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. |
| Users having behaviors | Count of distinct workers who sent a behavior÷ count of all people in the directory | Share of the population who gave behavior-based feedback, i.e. adoption of the behaviors feature. It counts people who sent at least one behavior, not the behaviors themselves, so someone who cited many behaviors counts once. A low value means behavior feedback is little used across the workforce. Read against % Users used feedback to see whether feedback-givers also tag behaviors. |
| Behavior distribution | Count of behavior references, by behavior | How behavior citations spread across the behavior framework, showing which behaviors get referenced most in feedback. It counts behavior instances, not feedback items or people, so a behavior cited across many feedbacks shows a larger slice. The donut renders each behavior as a share of the total, so it reads as the behavior mix rather than raw counts. Read against # Behaviors sent for the overall volume. |