System Logins

The System Logins 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 logins	Count of connection IDs (one per sign-in event)	Number of sign-in events. It counts events, not people: one user logging in ten times adds ten. So it measures activity volume, not reach, and should be read alongside Unique logins (distinct people) to tell heavy repeat use apart from broad adoption. Filtering to a period or team re-bases it to those sign-ins.
Unique logins over time	Count of distinct users who signed in, by date (one point per period)	Reach of logins over time: how many distinct people signed in during each period, regardless of how often. Within a period a user is counted once no matter how many times they connect, so this strips out repeat activity that # Logins over time includes. Comparing the two curves shows intensity: if total logins climb but unique logins stay flat, the same people are just logging in more. It measures active users per period, not a running total.
Avg. 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.
Unique logins	Count of distinct users who signed in	Number of distinct people having signed in at all, i.e. the reach of logins as opposed to the volume. Counts each user once no matter how many times they connect, so it answers "how many people used the platform," which paired with # Logins (events) shows whether a high login count is broad use or a few heavy users. Filtering to a period or team re-bases it to those users.
Avg. logins per user	Count of sign-in events÷ count of distinct users who signed in	On average, how many times each user who signed in did so, i.e. the login intensity. It divides total sign-in events by the distinct users behind them, so it isolates depth of use from reach: Unique Logins tells you how many people came, this tells you how often they came back. A value near 1 means most users signed in just once; a higher value means habitual, repeat use.
Logins per platform	Count of sign-in events, by date, split by platform	Login event volume over time, broken out by the device/platform each sign-in came from (desktop/iPhone/Android/Outlook/Teams), so you can see the usage trend and the channel mix together (for example desktop dropping while Teams rises). Each point is the events in that period for that platform, not a running total and not distinct people, so a heavy repeat user inflates their platform's bars. Read it for adoption of access channels over time rather than reach.
Total 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.
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.

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.