A communications manager opens SharePoint analytics properly for the first time, a fortnight before a budget conversation. The site usage page reports 4,100 unique viewers in the last thirty days. The analytics panel on the flagship news post says 2,780 views. The SharePoint site usage report in the Microsoft 365 admin centre gives a third number again. All three are correct. They measure different things over different windows, and picking one at random is how a credible reporting pack turns into an argument.
Native SharePoint analytics is free, switched on by default, and more useful than most internal communication teams give it credit for. It is also frequently misread, and it was never designed to answer the organisational questions a Head of Internal Communication is judged on. Both halves of that sentence matter.
Where the numbers actually live
There are three distinct surfaces, and knowing which one you are quoting is the first discipline.
The site usage page, reached from site settings on any modern site, is the fastest view. It gives unique viewers, site visits, popular content and trends over rolling windows. It answers “is this site being used” for a site owner, and it is the right tool for that job.
Page-level analytics on a modern page or news post gives views, unique viewers and an estimate of average time spent for that item. This is the closest native equivalent to an article-level readership figure, and it is what you should be quoting when you talk about a specific communication rather than a site.
The SharePoint site usage report in the Microsoft 365 admin centre works at tenant scale, with a row per site, several reporting periods and a CSV export[1]. It is the only one of the three that supports an organisation-wide view, and it needs admin rights, which is why most communications teams have never seen it.
| Surface | Scope | Best question for it | Export |
|---|---|---|---|
| Site usage page | One site | Is this site alive and what is popular on it? | Limited |
| Page analytics | One page or news post | How many distinct people read this communication? | No |
| Admin centre site usage report | Every site in the tenant | Which sites carry the traffic, and how is that shifting? | CSV |
How to read them without fooling yourself
Four misreadings account for most of the credibility damage done by native numbers in executive meetings.
Views are not readers. Views count page loads, unique viewers count people. A news post with 2,780 views and 1,900 unique viewers was read by 1,900 people, some of them twice. Quote unique viewers, always, and say which one you are quoting.
Average time spent is an estimate. It is genuinely useful as a relative signal, comparing this month’s leadership post with last month’s. Treated as an absolute measure of attention it is fragile, because a tab left open and a page skimmed in eight seconds distort it in opposite directions. Use it to rank, not to certify.
The reporting window truncates your history. Native reporting keeps a finite period. That is fine for operational monitoring and awkward the moment you want a year-on-year comparison, which is exactly the comparison an executive asks for. If you have redesigned your intranet, the problem compounds, as our note on measuring after a SharePoint redesign covers.
Traffic sits where the page lives, not where the reader came from. A news post surfaced on the hub home page and in a Viva Connections feed still reports under its home site. Teams that read hub numbers as campaign numbers systematically misattribute performance between sites.
Getting more out of native before you spend anything
Several things improve the quality of native data at no cost, and they are worth doing whatever you buy later.
Set up an organisational news site so official news is authoritative and consistently surfaced, which also makes its traffic identifiable rather than scattered across departmental sites[2]. Keep a stable site and hub structure, because every reorganisation of sites costs you comparability. Use consistent page templates so time-on-page comparisons are between similar objects. And run Microsoft’s portal health guidance before a major launch, since a slow page depresses every engagement number you will later try to interpret[3].
Get your admin to send you the site usage CSV monthly. Two years of those exports, kept in a folder you control, is a poor substitute for a measurement layer and a great deal better than nothing when the retention window closes behind you.
The four questions native cannot answer
These are not defects. They are consequences of what the product was built for: SharePoint reports on SharePoint, and it has no view of your organisation.
Who read it, in organisational terms? Native analytics does not join to Entra ID attributes or an HR file, so it cannot express readership by function, country, site, language or contract type. It can tell you 1,900 people read the post. It cannot tell you that 4 per cent of manufacturing did. Structuring those attributes is covered in our piece on audience segmentation for internal communications.
How many distinct people did the campaign reach across channels? SharePoint counts SharePoint. The same person reached by the intranet, the newsletter and a Teams post is three numbers in three places, and nobody reached by any of them appears anywhere. The method for fixing this is in our piece on cross-channel measurement.
Compared with when? Retention windows and redesigns break the baseline. A multi-year trend needs history held independently of the platform that produced it.
Did the population it was written for read it? Native gives you a numerator with no denominator, which is the single reason most intranet reporting cannot survive a follow-up question. The four questions behind every number are set out in our guide to internal communication analytics, and the detailed teardown of where native stops is in the limits of SharePoint analytics.
The Power BI route, honestly
The standard next step is a Power BI build against the Microsoft Graph reporting API[4]. It is a legitimate route and several organisations run it well. It is also more demanding than the first proof of concept suggests.
The reporting API is not consistently reliable and produces days with missing data. Customers have observed KPI values in Power BI that do not reconcile with the native SharePoint reports for the same period, which is a difficult thing to explain in front of an executive audience after you have presented both. A dependable build needs a robust ingestion process, scheduled reconciliation against the native figures and a named owner for the pipeline. Budget for the pipeline rather than the dashboard. The specific failure modes are in our note on SharePoint analytics in Power BI.
Where a dedicated layer earns its place
Everything above is still worth doing if you never buy anything, and for a single team on a single site it may be the whole answer. The case for a dedicated layer starts when the questions become organisational: reach as a share of a named population, segmentation by attributes SharePoint does not hold, one deduplicated figure across channels, and history that survives a redesign.
That is what Tryane does. It reads SharePoint alongside Viva Engage, Teams and your newsletter platform, joins the activity to your organisational structure through Entra ID or an HR file, and keeps unlimited history across product transitions. Tryane is SOC 2 Type 2 certified and GDPR compliant by design, hosts in the EU by default with US data residency on request, and deploys in a couple of hours over single sign-on with Entra ID, with no agent to install and no change to your SharePoint configuration. A direct comparison sits in Tryane against SharePoint native analytics.
Frequently asked questions
How far back does SharePoint analytics go?
Native reporting retains a finite window that varies by report, which is enough for operational monitoring and not enough for year-on-year narrative. Export the admin centre site usage CSV monthly if you want a longer record and have no other layer, and expect an intranet redesign or a migration to interrupt comparability regardless.
Can I see which departments read a news post?
Not natively. SharePoint records the activity but does not join it to organisational attributes, so department, country, site and contract type are not available in the native panels. Answering that question means combining SharePoint activity with Entra ID or an HR file, either by building the join yourself or by using a layer that does it.
Is average time spent on a page trustworthy?
As a relative signal, yes. As an absolute measure of attention, no. It is derived from client-side behaviour that a background tab or a quick skim distorts. Use it to compare similar pages over time and avoid quoting it as a precise reading duration in an executive report.
Do we need admin rights to use SharePoint analytics?
For the site usage page and page-level analytics, no, site permissions are enough. The tenant-wide SharePoint site usage report lives in the Microsoft 365 admin centre and does need the appropriate administrator role, which is why arranging a monthly export with IT is usually the fastest unblock for a communications team.
Does Tryane replace SharePoint native analytics?
No. SharePoint carries on recording what it records. Tryane sits on top, reads it together with your other channels, and joins the whole set to your organisational structure so reach, segmentation and long-run trend become answerable. You keep the Microsoft 365 investment and add the layer for what native was never built to do.
Sources
• Microsoft Learn, SharePoint site usage report
• Microsoft Learn, organisation news site
• Microsoft Learn, portal health and launch guidance
• Microsoft Learn, Microsoft Graph reporting API
Further reading
• The limits of SharePoint analytics
• SharePoint analytics in Power BI
• Tryane compared with SharePoint native analytics
• Measuring after a SharePoint redesign
• A guide to internal communication analytics
Tryane runs a 15-minute working session with Heads of Internal Communication: bring one news post and we will show what your native SharePoint data already proves about it and what it does not, on your own tenant. Book a slot with Jérémy.