Individual People Day Summary
The Individual People Day 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 |
|---|---|---|
| Worker full name | Worker's full name when exactly one worker is in view Otherwise blank | A label, not a number; it echoes the currently selected worker's name so the Individual People-Day page can title itself for that person. It shows a name only when the filters narrow to a single worker; with several (or none) selected it stays blank, which is how the page signals "pick one worker." It drives page headings, so it never aggregates or counts anything. |
| Behavior received | Sum of each recipient's received-behavior count (total behaviors received across recipients) | Number of behaviors referenced in the feedback that people received, in scope. It counts behavior instances on the receiving end, not feedback items and not people, so a person who received feedback citing many behaviors contributes many. It shows how much behavior-anchored feedback is landing on people. Read against # Behaviors sent (should broadly track it) and # Feedback received . |
| Total goals | Count of goals (one per goal record) | Total number of goals in scope, each goal being counted once (goals, not people; shared goals included once each). Two exclusions are built in at load and worth knowing: goals in the completed-pending-approval state are left out entirely, and goals not attached to a goal plan are excluded. So a goal a worker has marked complete but whose completion the manager hasn't yet approved won't appear here at all, which can make the count dip while approvals are pending. Archived and completed goals are included. |
| Avg. progress | Sum of goals' progress %÷ number of goals (in scope: goals that are In Progress or in a completion state, with a non-blank progress value) |
Mean completion progress of goals that are actually being worked on or closing out, on a 0–100% scale. Not-started/draft goals are excluded from both the sum and the count, so it reflects momentum on live goals rather than being dragged down by ones that haven't begun. Rising means goals are advancing toward completion; read it with % Goals completed to separate "progressing" from "finished". Shared goals: this divides over goals, each counted once and attributed to its owner. A goal shared by its owner with a team contributes one progress value to both the sum and the count; goals shared with someone are never counted as theirs. Individual, team and org goals are pooled together. |
| Goals completed | Count of goals where [Is Completed] = Yes | Number of goals having reached the completed state, i.e. fully done with completion approved. Read against # Goals (or via % Goal Completed ) to see how much of the goal load is finished. One subtlety from the data scope: a goal a worker has marked complete but the manager hasn't yet approved is not counted here and isn't in the totals at all (that's the excluded completed-pending-approval state), so this reflects approved completions only. Shared goals are included and counted only once (per owner). |
| Feedback received | Sum of each recipient's received-feedback count (total feedback items received) | Total number of feedback items people received, in scope. It counts pieces of feedback, not recipients, so someone who got 10 pieces contributes 10. It measures volume on the receiving end, not reach. Read against # Users received feedback (distinct recipients) to separate a few heavily-reviewed people from broad coverage, and against # Feedback sent to see the broad feedback tracking. |
| Feedback requests | Count of feedback requests (one per request record) | Number of feedback requests made, in scope. It counts request items, not people, so someone who asked several times contributes several. It measures the volume of requesting activity, not how many distinct people requested. Read against # Users who requested feedback (distinct requesters) to separate heavy requesting by a few from broad participation. |
| Behavior requested | Sum of each request's requested-behavior count (total behaviors requested across requests) | Number of behaviors that feedback requests asked to be assessed on, in scope. Behaviors are the competency/value tags, so this counts behavior instances attached to requests, not the requests and not people; one request asking about three behaviors adds three. It shows how much requesting is anchored to the behavior framework. Read against # Feedback requests and # Requests with behaviors . |
| Feedback received over time | Sum of received-feedback count, by date (feedback items received each period) | Number of feedback items received in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows when feedback arrived rather than a cumulative build-up. On the Individual People Day Summary page, the whole view is scoped to one selected worker, so it reads as that person's incoming-feedback timeline. Read against the sent-over-time line to compare giving and receiving rhythms. |
| Check-ins | Count of check-in IDs (one per check-in) | Total number of check-ins that took place, in scope. It counts check-in events, not people, so one person with many check-ins adds many; it measures activity volume, not reach. Read against # Users having check-ins (distinct participants) to separate heavy repeat use from broad adoption. |
| Check-ins with message | 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. |
| Check-ins in the future | Count of check-ins where future-check-in flag = Yes÷ count of all check-ins | Share of check-ins that are scheduled for a future date rather than already held. It puts # Check-ins in the future in context so periods with different check-in volumes compare fairly, showing how much check-in activity is still ahead versus behind. A higher share signals active forward planning; a very low share means check-ins are mostly logged after the fact. |
| Check-ins over time | Count of check-in IDs, by date (check-ins each period) | Number of check-ins created in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of check-in activity (spikes around review cycles, quiet stretches). The points sum back to # Check-ins over the full range. It counts check-in events, not people. |
| Feedback sent | Count of feedback items sent (one per feedback record) | Number of pieces of feedback given, in scope. It counts feedback items, not people, so a prolific sender who gave 20 pieces contributes 20. It measures volume of feedback activity, not reach. Read against # Users who sent feedback (distinct givers) to tell heavy use by a few apart from broad participation. |
| Avg. words count | Sum of feedback word counts÷ number of feedback items | Average length, in words, of the feedback messages that were sent. It's a rough proxy for how detailed or substantive feedback is: a higher value suggests richer, more considered feedback, a very low value suggests terse one-liners. It averages over feedback items with a non-blank word count, so a few long messages can pull it up. Read against # Feedback sent to see whether volume comes with substance. |
| Behaviour sent | Count of behavior records sent (one per behavior referenced in feedback) | Number of behaviors referenced in the feedback that was given, in scope. Behaviors are the competency/value tags on feedback, so this counts behavior instances, not feedback items and not people; one feedback citing three behaviors adds three. It shows how much feedback is anchored to the behavior framework by volume. Read against # Feedback sent and # Feedback with behaviors . |
| Feedback sent over Time | Count of feedback items sent, by date (feedback sent each period) | Number of feedback items given in each period, plotted as a trend. Each point is that period's total, not a running total, so it shows the rhythm of feedback-giving (spikes around review cycles, quiet stretches). The points sum back to # Feedback sent over the full range. On the Individual People Day Summary page, it's scoped to one selected worker, so it reads as that person's outgoing-feedback timeline; on the Feedback report it's the whole population in view. |
| Activity | Section heading (no data) | A textbox label marking the Activity section of the Individual People Day Summary page. It carries no metric or value and simply groups the widgets beneath it. |
| 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. |
| Behaviors received | Sum of each recipient's received-behavior count (total behaviors received across recipients) | Number of behaviors referenced in the feedback that people received, in scope. It counts behavior instances on the receiving end, not feedback items and not people, so a person who received feedback citing many behaviors contributes many. It shows how much behavior-anchored feedback is landing on people. Read against # Behaviors sent (should broadly track it) and # Feedback received . |
| Behaviors sent | Count of behavior records sent (one per behavior referenced in feedback) | Number of behaviors referenced in the feedback that was given, in scope. Behaviors are the competency/value tags on feedback, so this counts behavior instances, not feedback items and not people; one feedback citing three behaviors adds three. It shows how much feedback is anchored to the behavior framework by volume. Read against # Feedback sent and # Feedback with behaviors . |
This is a tip message.
For more information about the visuals and metrics used in Analytics Hub, refer toVisuals in Analytics hub and Metric dictionary, respectively.