Activity Analysis

Web Portal → Activity analysis

Insights > Activity analysis shows how people use Microsoft 365, week by week. It is the portal's version of the Analytics page of the Activity & usage analytics Power BI report - its Activity Analysis and Filter Settings views - and reads the same weekly activity profile that the profiling runbooks compile. You can explore it without Power BI Desktop, a published dataset or a Power BI licence.

It answers questions such as: how has Teams, Outlook, OneDrive, SharePoint, Copilot and Viva Engage activity moved week by week over the last year? Which departments and companies are most active? And, for readers with See PII: who are the most active people - the champions - whatever licence they hold, and how do the figures change for one country, one licence, or people above or below an activity threshold?

What the page shows

Section	What it shows
Period	Last 3 months (13 weeks), Last 6 months (26 weeks), Last 12 months (52 weeks, the default), All available, or Custom (a first and a last week). Presets end on the latest compiled week. Weeks run Monday to Sunday, and any date you pick is moved to the Monday of its week. One view covers at most 105 weeks (about two years); All available is limited to the latest 105 weeks and says so.
Matching people / active	How many people match, and how many of them were active in at least one selected metric. When filters narrow the population, it also says how many people had recorded activity in the period.
Metrics	A tree of the 58 metrics the profiling runbooks compile, grouped by service: Teams (18), Outlook (5), OneDrive (4), SharePoint (4), Copilot (24) and Viva Engage (3). The page opens with the six core Teams metrics, as the Power BI page does. Tick a service to select all its metrics; Select all and Clear act on every metric.
Active people by company / by department	How many matching people were active, per company (bar chart) and per department (treemap), most active first. A chart has at most 50 entries: when there are more groups, the smallest are combined into Other.
Metrics by week	One line per selected metric. Switch between Total activity (the week's sum) and Active people (how many people had that metric above zero that week).
Results by department	For each department and each selected metric, Sum and Unique, with a Total row that stays in view at the foot of the table. Sort by any column. Departments are drawn 100 at a time, with Show more for the rest, so a tenant with thousands of departments stays responsive. With See PII, a department expands to its people: up to 100, most active in the first selected metric first.
Top people	With See PII: the most active matching people (top 10, 25, 50 or 100), ranked by any selected metric (Rank by), with every selected metric shown. These are your champions, whichever licence they hold.

Teams audio, video and screen-sharing durations are stored in seconds and shown, and filtered, in hours.

How the figures are worked out

• Who is counted. Licensed, enabled accounts with an Entra ID object ID (the profiling view profiling.users) that have recorded activity in the selected period. The source line at the foot of the page says the same: only licensed, enabled accounts with recorded activity in the period are counted. Accounts are taken as they are now, so someone disabled or left without a licence since then is not counted in past weeks either. Department and company come from each person's current directory profile.
• Sum. The total of a metric over the period, for the people in that row.
• Unique. How many of those people had a total above zero for that metric over the period: they did it at least once. This is the Power BI report's Unique measure.
• Active. A person with a total above zero in at least one of the selected metrics. Changing the selection changes who is active.
• Total row. Every matching person, once. Each person is in exactly one department row (or in Other), so the department rows add up to it.

Filters

Select Filters to open the filter panel. Every filter needs the See PII permission, because any condition you choose could narrow the figures down to a single person: a report filtered to every licence but one, say, can leave out exactly one person, and its difference from the unfiltered report is that person's figures. Without See PII the panel only explains this, and the API refuses any filter, not just the page.

With See PII, the panel has three parts. Nothing changes until you select Apply filters; until then, the panel says your changes are not applied yet. Its footer shows how many people match the filters already applied. Reset clears every filter in the panel; apply that to show everyone again.

• People: the same people filter as the other Insights pages, over department, job title, company, office, country or region, postal code, manager, management chain and the other directory attributes.
• Licences: people who hold any of the selected licences. The list shows the licences held by people in the period, with how many people hold each.
• Activity ranges: a minimum and/or maximum for each person's total of a metric over the whole period - for example Teams calls at least 5 or Emails sent at most 2,000. Leave a box empty for no limit, and a person must be within every range you set. Each Maximum box shows the highest total anyone has, as a guide. The list shows each service's core metrics, plus any metric that already has a range; Show every metric lists them all.

An administrator's report filter narrows the population first, for every reader, as on every other Insights page; the bar at the top of the page says when one applies.

Who sees what

Everyone who can sign in to the portal can open the page and see the aggregates. Filtering and anything that names a person need the See PII permission (the Portal.SeePII app role; see Portal permissions):

	Without See PII	With See PII
Charts, weekly lines, department table and totals	Yes, for everyone with recorded activity in the period. Companies and departments with fewer than 5 people are combined into one Other row. If those come to between 1 and 4 people, the smallest named groups are combined as well, because the total minus the named rows would otherwise give a handful of people's figures.	Yes, every company and department by name, within the charts' 50-entry limit.
Only 1 to 4 people have recorded activity in the period (within any report filter)	Only the number of people is shown; every other figure is hidden (Figures hidden). Try a longer period.	All figures.
Filters	Not available.	Available.
Department drill-down and Top people	Not available.	Available, listing people by sign-in address.

Staff names are not collected, so people are always listed by their sign-in address (UPN).

Prerequisites

• The profiling runbooks from Activity & usage analytics must be deployed and must have compiled at least one week. Until then, the page says Activity analysis is not set up on this deployment (the profiling tables do not exist) or No weekly activity has been compiled yet (they exist but hold no weeks). Administration > Profiling shows whether the runbooks have run, and administrators get an Open Profiling link from the message.
• The weeks shown are the weeks the runbooks have compiled and kept. See Runbook schedules, the WeeksToKeep retention setting in Activity & usage analytics, and, to add older weeks, Rebuilding profiling data.
• A metric whose column an older profiling install lacks is left out of the tree rather than failing the page; a note under the tree says how many metrics are not available.

The page only reads data: the compiled profiling tables, the licence tables and the imported user directory. It needs no database migration, new SQL object or installer setting.

Performance and caching

The first view of a period reads that period's compiled weeks once - every person's totals and the population's weekly figures - and keeps them in the web app's memory, shared by every reader. After that, changing metrics or filters is answered from memory, except for the weekly lines of a filtered set of people, which take one more query that is also cached.

What	Behaviour
First view of a period	One read of the period's rows. In a synthetic test with 50,000 people and 52 weeks, on a developer machine's LocalDB (Express edition, at most four cores), it took about 16 seconds, or 25 seconds from cold. The time grows with the number of people and weeks, so expect roughly four times that at 200,000 people, depending on your Azure SQL tier.
Later views	Immediate while the period stays in use. A period unused for 15 minutes is dropped; at most two periods are held, about 50 MB each at 200,000 people. After a run of the profiling runbooks adds a week or deletes old ones, a period in use is read again within about 5 minutes.
Filtered weekly lines	One query per distinct set of people, cached the same way. When most people match - a licence most staff hold, at least one Teams call - the page reads everybody else instead and subtracts, so this query never covers more than half the people. If the runbooks have changed the weeks since the period was read, it reads the matching people instead, so the lines never mix the table before and after a run.
Several periods at once	One period loads at a time. Another request waits up to 90 seconds, and the page retries twice by itself before it says Another period of activity is being loaded right now. Try again in a few seconds.

Each load is recorded in Application Insights:

customEvents
| where name == "ActivityAnalysisLoad"
| project timestamp,
          Stage = tostring(customDimensions.Stage),          // ReadModel or WeeklyTotals
          Outcome = tostring(customDimensions.Outcome),
          DurationMs = todouble(customMeasurements.DurationMs),
          People = todouble(customMeasurements.People),
          Weeks = todouble(customMeasurements.Weeks)
| order by timestamp desc

Differences from the Power BI report

• Same data. The page reads the same compiled profiling tables, and Sum and Unique mean what they mean in Power BI. If figures differ, first check that both cover the same weeks: the portal's periods are whole Monday-to-Sunday weeks.
• Permissions. The portal's See PII permission governs filters and named people on this page. It does not protect a separately published Power BI report, which relies on its own workspace and report security.
• Top people and the per-department drill-down by sign-in address are new, and are limited to readers with See PII.
• Viva Engage metrics (named Yammer in the profiling tables and the Power BI report) are listed whenever the profiling tables have them.
• There is no export. Print prints the period, filters, charts and results table on screen.

Troubleshooting

Symptom	Cause and action
Activity analysis is not set up on this deployment	The profiling tables were not found. Deploy the profiling runbooks: see Activity & usage analytics.
No weekly activity has been compiled yet	The runbooks are installed but have not compiled a week. Check Administration > Profiling, that the runbooks are linked to their schedules, and the Weekly_Update runbook's job history.
The latest week is missing	A week appears only once the scheduled Weekly_Update runbook has compiled it. Reload the page: the portal picks up a newly compiled week within about 5 minutes of the run.
Fewer people than in the user import	Only enabled, licensed accounts with recorded activity in the period are counted, as they are now.
Figures hidden	You do not hold See PII, and only 1 to 4 people have recorded activity in the period within your administrator's report filter. Choose a longer period.
The Filters panel has nothing to set	You do not hold See PII. Every filter needs it.
The page keeps saying another period is loading	Someone's first view of a period is still loading. On a large tenant that can take a minute or more; wait, then select Try again. Use the query above to see how long ReadModel loads take.

---

Return to Web Portal · Workload reports · Licence activity · Activity & usage analytics (Power BI)