Comment analyser SharePoint avec Power BI

How to Analyse SharePoint with Power BI, and What a Build That Survives an Executive Review Requires

By Nicolas Saliba · 8 min read

The question usually arrives from IT rather than from you, and it is a fair one. The organisation already pays for Power BI, SharePoint already emits usage data, and someone reasonable wants to know why internal communication needs a separate analytics platform when a developer could wire this up in a fortnight. That developer is right that it can be built. What the fortnight estimate misses is that the hard part is not the report. It is keeping the numbers defensible for the eighteen months after the report is delivered.

This article is the practical version: what you are actually connecting to, an architecture that holds up, the reconciliation habit that keeps the dashboard credible, and an honest read on when not to build at all. The specific ways these builds fail are covered separately in our piece on SharePoint analytics in Power BI, which is worth reading alongside this one.

You are connecting to three different things, not one

The first design mistake is treating SharePoint as a single data source. There are three, they have different grain, and they do not agree with each other by construction.

	Microsoft 365 usage reports	SharePoint site and page analytics	Audit log and Purview
Grain	Site and user level, daily aggregates	Page and site level, in the UI	Individual events
How you get it	Microsoft Graph reporting API	Site usage panel, limited export	Audit search or the management activity API
Typical retention	Rolling windows of up to 180 days	Rolling window per panel	Depends on licence and retention policy
User identity	Concealed by default in the tenant privacy setting	Aggregate only	Named, subject to policy
Good for	Trend lines and site comparison	Checking a single page	Forensic and compliance questions
Bad for	Anything needing named users or long history	Anything automated	Routine reporting, it is expensive to query

One setting deserves naming because it silently breaks more builds than any other. In the Microsoft 365 admin centre, reports conceal user, group and site names by default, and the API returns pseudonymised identifiers accordingly^[1]. If your model joins usage to an HR extract on user principal name, it will return nothing and it will not tell you why. Changing the setting is a tenant-wide privacy decision that belongs with your DPO and your works council, not with the developer building the model.

The three things you must know before you start

These are not edge cases. Every organisation that has run one of these builds for a year has met all three.

The Microsoft Graph reporting API is not consistently reliable. It produces days with missing data^[2]. Not corrupted data, absent data. If your model sums a month without checking for gaps, the month is simply low and the dashboard says engagement fell.

The numbers will not always reconcile with the native reports. Customers have observed KPI values in Power BI that do not match the native SharePoint reports for the same period. When a site owner opens their own site usage panel and sees a different figure from the one on your executive dashboard, the conversation that follows is about your credibility, not about the discrepancy.

A dependable build needs a robust ingestion process and scheduled reconciliation. Not a direct query against the API from the report. A proper ingestion job with retry, gap detection and a stored history, plus a monthly reconciliation against the native figures, plus a named person who owns it when they are on holiday. Budget for the pipeline rather than for the dashboard. The dashboard is the cheap part and always was.

An architecture that holds up

Four layers. Skipping any of them is where the fortnight estimate comes from.

Ingestion, scheduled and idempotent. Pull from the Graph reporting API on a schedule, write raw responses to storage, and re-pull any day that came back empty. Idempotent means a re-run does not double-count, which matters the first time a job half-fails at two in the morning.
A landing store with real history. The API’s rolling window is the reason your multi-year trend does not exist. If you keep every daily pull, you accumulate the history the platform does not retain. This is cheap and it is the single highest-value thing in the whole build.
A semantic model with written definitions. Active user, reach, unique viewer: define each one once, in the model, and document it. Most reconciliation arguments are definition arguments wearing a data costume.
The report, last. Connect Power BI to the modelled data rather than to the API^[3]. Reports built directly on a volatile source inherit the volatility.

If you are designing what actually goes on the page, our guide to building an internal communications dashboard covers the layout and the measures, and the note on campaign ROI in Power BI covers the campaign-level view.

The reconciliation habit

One hour a month, and it is what separates a dashboard people trust from one they quietly stop opening. Pick three KPIs. Recompute them from the native SharePoint site usage report for the previous full month^[4]. Log the delta against your model. Then publish the delta next to the dashboard rather than hiding it.

That last step is counterintuitive and it is the important one. A dashboard that says it is within two per cent of native has authority. A dashboard that says nothing loses all of it the first time somebody finds a gap on their own.

When to build, and when not to

Build it if the scope is one or two channels, you have a data engineer with capacity, IT is willing to own the pipeline as a service rather than as a project, and you can live with tenant-level segmentation. That is a real situation and the build is a sensible answer to it.

Think harder if any of the following are true. You need participation by function, site, country or contract type, which means joining to Entra ID or an HR file and confronting the pseudonymisation setting; our note on audience segmentation sets out what that join requires. You need SharePoint, Viva Engage, Teams and your newsletter platform in one reach figure. Or you need history spanning a redesign or a product transition, which no rolling window will give you. Gallagher’s State of the Sector research keeps finding measurement to be the capability internal communicators name first as missing, and a half-finished Power BI build is one of the most common reasons why^[5].

Tryane exists for that second column. It reads SharePoint alongside Viva Engage, Teams and newsletter platforms, joins the activity to your organisational structure through Entra ID or an HR file, and keeps unlimited history across redesigns and product transitions. It also exposes an API, so if Power BI is where your executives already look, Tryane can feed it rather than compete with it. 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. If you have not yet exhausted what is free, start with the guide to SharePoint native analytics and the note on where native SharePoint analytics stops.

Frequently asked questions

Can Power BI connect directly to SharePoint analytics?

Not to the site usage panel, which is a user interface rather than an endpoint. What you connect to is the Microsoft Graph reporting API for tenant-level usage data, and optionally the audit log for event-level data. SharePoint lists and libraries are directly connectable, but they hold your content, not your usage statistics.

Why do my Power BI numbers differ from the SharePoint site usage panel?

Usually one of three reasons: the API returned days with no data and your model summed the gap as zero, the two sources define the metric differently, or the date windows do not align because one is rolling and the other is calendar. Run a monthly reconciliation on three KPIs, log the delta, and publish it alongside the dashboard so the difference is documented rather than discovered.

Can I report by department or country in Power BI?

Only if you join usage data to an attribute source such as Entra ID or an HR extract, and only if the tenant privacy setting that conceals user, group and site names has been reviewed. That setting is on by default and quietly returns pseudonymised identifiers that will not match your HR keys. Treat changing it as a privacy decision involving your DPO, not a configuration task.

How much history can I get?

From the API, rolling windows of up to 180 days depending on the report. Anything longer has to be accumulated by you, which is why a landing store that keeps every daily pull matters more than the visuals. If you start storing today, in two years you have something the platform cannot give you at any price.

Does Tryane replace Power BI?

No, and it does not need to. Tryane provides the measurement layer, joins across channels and holds the history. If Power BI is where your leadership already reads its numbers, Tryane feeds it through the API. You keep the Microsoft 365 investment and stop maintaining the ingestion pipeline yourself.