The safety bulletin went out on Monday and the analytics tab says 4,100 views. On Wednesday the operations director asks whether the night shift saw it. You open the tab again, as though it might have changed since the last time, and it says 4,100 views.
Every internal communication team on SharePoint has had a version of that morning. The usual response is to list what native analytics is missing, which produces a long list and no decision. It is more useful to notice that the list has one cause. SharePoint analytics is instrumentation for a website. Internal communication asks questions about an organisation. Every limit you will run into follows from that mismatch, and once you see it you can sort your questions rather than complain about the tool.
The design fact everything follows from
SharePoint site analytics and the Microsoft 365 usage reports do exactly what their documentation says: they report traffic, files and site activity, over fixed windows, per site[1]. That is a coherent product decision. SharePoint is a platform for sites and content, and its telemetry describes sites and content[2].
The questions an internal communication function is judged on are not about sites. They are about populations, about change over time, and about the whole channel estate at once. Did the message land with the people it was written for. Is that better than the same campaign last year. What did it cost per person actually reached. None of those can be derived from site traffic, no matter how many views the tab reports, because the missing information was never collected.
Sort your questions into two piles
This is worth doing literally, on paper, once. Take the ten questions your stakeholders actually ask and mark each as a website question or an organisation question. The website questions are already answered and you can stop worrying about them. The organisation questions need something else, and knowing which is which stops you from waiting for a Microsoft release that will not come, because nothing is broken.
| The question | Type | Native answer | What it would take |
|---|---|---|---|
| Which news page performed best this month? | Website | Yes, directly | Nothing |
| Is intranet traffic up or down since the redesign? | Website | Yes, within the retained window | Nothing, if the window covers it |
| Did the night shift in Rotterdam see the safety bulletin? | Organisation | No | Activity joined to workforce attributes |
| Is engagement in manufacturing improving year on year? | Organisation | No | History beyond the retained window |
| How many distinct people did the campaign reach in total? | Organisation | No | Deduplication of people across channels |
| Which populations never see anything we publish? | Organisation | No | A denominator, which native does not hold |
Four consequences, one cause
No organisational attributes, so no rates
SharePoint knows accounts and permissions. It does not know function, grade, country, site, language, shift or contract type, because those live in your HR system and in Entra ID. Without them there is no denominator, so every figure stays an absolute count and no count can be turned into a rate. This is why “4,100 views” cannot become “62 per cent of the intended audience”, and it is the same constraint that makes a defensible reach figure impossible from native data alone.
There is a second-order version of this that catches teams by surprise. Microsoft 365 usage reports can be configured at tenant level to display anonymous identifiers in place of user names. Many organisations switch that on for good privacy reasons, and it removes any possibility of segmenting the native reports at all, no matter what else you build on top.
A finite retained window, so no long narrative
Native reporting works over fixed recent windows. That is appropriate for operating a site and unhelpful for a function whose credibility rests on year-on-year improvement. The damage is quiet and cumulative: every month that passes without an independently held baseline is a comparison you can never make later. Teams usually discover this in the month they are asked for a three-year trend.
One product at a time, so no total
SharePoint reports SharePoint. Viva Engage reports Viva Engage. Teams reports Teams. Your newsletter platform reports itself. Each is accurate and none of them can tell you how many distinct human beings a campaign touched, because a person who read the intranet page and opened the newsletter appears twice when you add the figures. That arithmetic problem is the whole subject of cross-channel measurement, and it is not solvable inside any single product’s reporting.
An administrative access model, so the wrong people hold the data
The tenant-wide usage reports sit in the Microsoft 365 admin centre and require an administrative role to read. Page-level analytics sit with whoever owns the page. The result in most organisations is that the internal communication team has good visibility of the sites it owns, no visibility of the tenant, and a dependency on an IT colleague for anything wider. That is a governance choice rather than an analytics limitation, but it shapes what a communication team can actually do on a Tuesday afternoon.
When native is genuinely the right answer
Worth saying plainly, because the vendor version of this article never does. If you run one communication site for one audience, native analytics is the correct tool and you should not buy anything. It is free, already switched on, requires no project, and answers the site questions well. A team of two running a single intranet with a homogeneous desk-based population will get everything it needs from the analytics panel and a spreadsheet.
The threshold is not company size on its own. It is the number of distinct populations you are accountable for, multiplied by the number of channels you run. One population and one channel needs nothing. Six populations across four channels is where the manual reconciliation starts to consume more time than the communications work does, and where the numbers start disagreeing with each other in public.
The workarounds, and where each one gives out
Most teams try to close the gap themselves before they consider anything else, which is reasonable. Manual exports, spreadsheet joins against an HR extract, a custom Power BI model, a SharePoint list used as a register. Each buys a period of relief and each has a specific failure point, usually arriving with a reorganisation or a departure. We have written those up separately, gap by gap, in our companion piece on where native SharePoint analytics runs out and what teams try next, so this article will not repeat them.
The Power BI route deserves a specific warning because it is the one most often presented as the serious answer. Building against the Microsoft Graph reporting API is technically possible and some organisations run it well[3]. Be clear about three things before you commit. The reporting API is not consistently reliable and produces days with missing data, which Microsoft acknowledges in its own known issues documentation[4]. Customers have observed KPI values in Power BI that do not reconcile with the native SharePoint reports for the same period, and that argument is very hard to win in front of an executive audience. And a dependable build needs a robust ingestion process, scheduled reconciliation against the native figures, and a named owner who is still there in eighteen months. Budget for the pipeline rather than the dashboard. Our note on SharePoint analytics in Power BI goes through each failure mode.
What actually closes the gap
Whatever you choose, closing an organisation question requires the same three ingredients: activity from every channel, a join to your organisational structure, and history that survives product transitions. That combination is what Tryane provides. It reads SharePoint, Viva Engage, Teams and your newsletter platform together, joins them to Entra ID or an HR file, deduplicates people across channels, and keeps unlimited history so a SharePoint redesign or a Viva Engage migration does not reset your trend line. Tryane is SOC 2 Type 2 certified and GDPR compliant by design, hosts in the EU by default with US data residency on request, deploys in a couple of hours over single sign-on with Azure AD or Entra ID, and installs no agent.
Gallagher’s State of the Sector research keeps finding measurement at the top of the capability gaps internal communicators name[5]. The reason is structural, not a shortage of skill. The tooling most teams have reports on products, and the profession is asked about people. If you are working out how to frame that argument internally, our piece on why internal communication reporting became essential covers what changed on the demand side.
Frequently asked questions
Will Microsoft add segmentation to SharePoint analytics?
Nothing suggests it, and the reason is architectural rather than a matter of roadmap priority. Segmenting by function or country means holding workforce attributes inside the analytics of a content platform, which is a different product with different privacy implications. The pattern Microsoft has followed instead is to expose data through the Graph reporting API and leave the joining to whoever needs it.
How much history does native SharePoint analytics keep?
Native reporting operates over fixed recent windows rather than an open archive, so multi-year comparisons are generally not available from it. The practical consequence is that the baseline has to be captured by something else, continuously, starting before you need it. Retrospective recovery of a lost baseline is not possible.
Can I just export to Excel each month?
You can, and many teams do it for years. It works while one person owns it and stops working the week that person changes role, because the join rules live in their head and in unversioned formulas. It also cannot fix deduplication across channels, which needs an identity match rather than a spreadsheet lookup.
Is a third-party analytics layer a replacement for SharePoint?
No, and be sceptical of anything that claims to be. SharePoint remains the platform. An analytics layer reads what SharePoint and its sibling products already record and adds the joins native was not designed to make. Our comparison of Tryane against SharePoint native analytics sets out which questions sit on which side.
What is the first thing to fix if we have no budget?
Write down the intended audience for every significant campaign before you publish, in the same attribute terms your HR system uses, and store it. It costs nothing, it is the denominator you will need later, and it is the one piece of information no tool can reconstruct after the fact. Our note on audience segmentation covers how to structure it.
Sources
• Microsoft Learn, Microsoft 365 reports, SharePoint site usage
• Microsoft Learn, Introduction to SharePoint
• Microsoft Learn, Graph reportRoot getSharePointSiteUsageDetail
• Microsoft Learn, known issues with Microsoft Graph
• Gallagher, State of the Sector
Further reading
• Where native SharePoint analytics runs out, gap by gap
• Building a defensible SharePoint reach figure
• SharePoint analytics in Power BI, and where it breaks
• Tryane compared with SharePoint native analytics
• Measuring after a SharePoint redesign
Tryane runs a 15-minute working session with Heads of Internal Communication, sorting your current reporting questions into the ones native already answers and the ones that need a join to your organisational structure. Book a slot with Jérémy.