Pourquoi vos communications sur SharePoint sont ignorées

Why SharePoint News Goes Unread, and What the Data Actually Shows

By Nicolas Saliba · 8 min read

The strategy update went live on the intranet home site at nine on a Tuesday. By Friday the page reported 2,300 views. Headcount is 14,000. Before Monday’s leadership call, the Head of Internal Communication has to decide whether that means the message failed, the distribution failed, or the number is not measuring what everyone in the room assumes it measures.

Most teams answer with instinct and a redesign brief. The evidence points somewhere less flattering and more fixable. Intranet news is rarely ignored uniformly. It is ignored in identifiable populations, at particular hours, on particular surfaces. An aggregate view count is constructed in a way that hides those populations, which is why a redesign so often changes the look of the intranet and not the numbers.

Three different failures, one identical view count

When someone says a communication was ignored, they are usually describing one of three things, and the three have almost nothing in common except that they produce the same low number.

The first is that the item never surfaced. It was published to a site most of the workforce has no reason to visit and was never promoted into a feed those people occupy, so it never entered anybody’s field of view. This is not an attention failure. Nothing was offered to ignore.

The second is that it surfaced and was skipped. The headline appeared in a feed, was read in the peripheral way that headlines are read, and did not earn a click. This is a headline and framing problem, and it is the only one of the three that a writing workshop will fix.

The third is that it was opened and abandoned. Someone clicked, spent four seconds, and left. That usually means the first screen did not match what the headline promised.

A view count cannot distinguish between them. Two of the three are distribution problems. Teams that respond to a low number by rewriting harder are, statistically, fixing the wrong one.

The denominator problem, which is the real one

The number 2,300 is not interpretable on its own. It becomes interpretable the moment you can say what it is 2,300 out of.

If the update was written for the 3,400 people in the commercial organisation, 2,300 is a good result and the team should be told so. If it was written for all 14,000, it is a poor one. And if 1,900 of those views came from head office, the message reached the population that was already best informed and missed the one that needed it. Those three readings lead to three different actions, and the raw count supports all of them equally, which is another way of saying it supports none.

This is why audience segmentation is not a reporting refinement. It is the precondition for the number meaning anything. Gallagher’s State of the Sector research has consistently found measurement to be the capability internal communicators name first when asked what they are missing^[1]. The gap is structural. The native tooling counts what it can see, and what it can see is traffic to a page, not participation in a workforce.

The audience targeting trap

SharePoint audience targeting makes this worse in a way that catches experienced teams. Targeting narrows who is shown an item, which is what it should do. But most reporting still expresses reach against the full tenant, so an article deliberately shown to 3,400 people is judged against 14,000. The team penalises itself for doing the right thing.

Publishing is not distribution

A SharePoint news item can reach a person through the home site news web part, the SharePoint start page, the Viva Connections feed inside Teams, the automated news digest email, enterprise search, or a link someone pasted into a Teams channel. These are not equivalent. Microsoft’s own guidance on organisation news sites is explicit that whether an item is boosted across the tenant depends on how the site is designated in the information architecture, not on how important the author considered the message^[2]. The portal health guidance makes a related point about how site structure and performance shape what people actually encounter^[3].

In practice, much of what gets described as ignored content was published to a departmental site, never designated as an organisation news source, never surfaced in Viva Connections, and never linked from anywhere people already were. It was available. It was not distributed. Our note on SharePoint communication reach separates the two.

What the numbers show about when people read

Two patterns hold across almost every tenant we see, and neither is controversial.

Readership is front-loaded. The overwhelming majority of a news item’s lifetime views arrive in the first day or two, after which the item is effectively invisible unless it is re-promoted. Most editorial calendars ignore the consequence: publishing four items on the same morning does not multiply reach, it makes four items compete for one short window.

Reading hours are also not uniform. An office population reads in the first hour of the day and again after lunch. A shift population has no such shape, and a single publication time systematically disadvantages whichever shift is not at a screen. Gallup’s workplace research has repeatedly found the engagement gap widest in frontline and deskless populations^[4], and a publishing rhythm built around head office hours quietly reinforces it. The pieces on identifying the best time to post and on measuring frontline communications go into the mechanics.

Symptom	What the view count shows	What it cannot tell you	What to measure instead
Low views on an important item	A single aggregate number	Whether the item was ever surfaced to the target audience	Reach against the intended audience, by segment
Views concentrated on day one	A decaying curve	Whether late-shift populations had a chance at all	Reach by shift pattern and time zone
Good views, no action	Views and possibly likes	Whether anyone read past the first screen	Read depth and completion, plus the downstream action
Targeted item, poor score	Views against the full tenant	That the denominator was deliberately reduced	Reach against the targeted audience only

The honest case for native SharePoint analytics

SharePoint site usage reports and page-level analytics are free, already switched on, and adequate for the question a site owner actually has^[5]. If you own one communication site and you want to know whether last week’s page was viewed more than the week before, the native reports answer that and you should not buy anything.

They stop short in three places. They do not join to organisational attributes, so function, country, site and contract type are unavailable without exporting and joining the data yourself. They are organised by site rather than by campaign, so a message that ran across the intranet, a Viva Engage community and the newsletter has no single number. And the retained window is finite, which makes the multi-year comparison awkward at exactly the moment you need it. The detail is in our piece on the limits of SharePoint native analytics.

The usual next move is a custom Power BI build over the Microsoft Graph reporting API^[6]. It can be made to work, and it is harder than it looks. The reporting API is not consistently reliable and produces days with missing data. Customers have observed KPI values in their Power BI dashboards that do not reconcile with the native SharePoint reports for the same period, which is a difficult conversation to have in front of an executive audience. A dependable build needs a robust ingestion process, scheduled reconciliation against the native figures, and a named owner. Budget for the pipeline rather than the dashboard. Our note on SharePoint analytics in Power BI sets out the failure modes.

A diagnostic sequence that separates the three failures

Before the next redesign brief, run the item through this order. It takes an afternoon and usually settles the argument.

Write down the intended audience before publishing. Not “everyone”. A named population with a size. This is your denominator and it has to exist beforehand, not be reverse-engineered afterwards.
Record which surfaces carried it. Home site, Viva Connections, digest email, Teams link, newsletter. If the answer is “the site”, you have a distribution finding.
Express reach as a rate against that population, by segment. Twelve per cent of manufacturing and 61 per cent of commercial is an instruction. A raw total is not.
Look at read depth, not only views. A four-second visit and a two-minute read are the same view.
Compare like with like. Same author, same format, same audience, over several months. A single item’s number is noise.

This is the layer Tryane occupies. It reads SharePoint alongside Viva Engage, Teams and your newsletter platform, joins that activity to your organisational structure through Entra ID or an HR file, and keeps history across redesigns so a three-year trend reads as one 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 with single sign-on through Entra ID, and installs no agent. If you are rebuilding the intranet, the companion piece on measuring after a SharePoint redesign covers how to keep the before-and-after comparison honest.

Frequently asked questions

How do I know whether it is a content problem or a distribution problem?

Compare the number of people shown the item with the number who opened it. If very few were ever shown it, no amount of rewriting will help. If many were shown it and few clicked, the headline is the place to work. The native reports do not make this comparison easy because they count page traffic rather than impressions against an audience, which is why the denominator has to be defined before publishing.

Does SharePoint tell me who read an article?

Page-level analytics report views and unique viewers, and site usage reports aggregate activity at site level. They do not join to your HR structure, so you cannot answer questions about function, country, site or contract type without exporting the data and joining it yourself. That join is the whole difficulty, and it is where most spreadsheet-based reporting programmes stall.

Is a low view count always bad?

No, and treating it that way distorts editorial behaviour. A safety notice written for 400 plant operators that reaches 340 of them is a strong result with a small number attached. A tenant-wide announcement with the same 340 is a failure. Until reach is expressed against an intended audience, the number cannot be judged at all.

Should we just email everything instead?

Email raises delivery figures without necessarily raising attention, and it degrades fast once it becomes the default. Decide the surface by the nature of the message, then measure every surface against the same audience definition so cross-channel comparison is possible. Counting only the channel that reports most generously is how teams end up confidently reporting reach they do not have.

Does Tryane replace SharePoint analytics?

No. SharePoint continues to record what it records. Tryane sits above it, reading SharePoint alongside Viva Engage, Teams and newsletters, joining all of it to your organisational structure so you can answer segmented and cross-channel questions no single native panel can. You keep the Microsoft 365 investment and add the measurement layer for what native does not do.