A Head of Internal Communication at a 14,000-person engineering group asked us a question last year that is worth quoting: “We have SharePoint numbers, Viva Engage numbers, Teams numbers and newsletter numbers. Why can I still not answer whether the Southern Europe region is better informed than it was in January?”
She had four tools and no model. Every one of those systems could produce a chart. None of them held the thing that would let her answer her actual question, which was a stable definition of a person, attached to a stable definition of a business unit, over time. This article is about that layer. It is the decision most digital workplace analytics programmes skip, and skipping it is why they stall in month four.
The four entities you need, and only four
Strip away the vendor architecture diagrams and a digital workplace measurement model has four entities. Everything you will ever be asked reduces to a question about how these four relate.
The person. One row per human being, with a key that does not change when they marry, move country or get a new job title.
The organisational unit. The function, division, site, country, contract type and language of that person. This is the entity that turns activity data into an answer an executive cares about.
The content item. A news post, a community message, a Teams announcement, a newsletter edition. It has an author, a publication moment and an intended audience, and that last attribute is the one nobody records.
The event. A person did something to a content item at a point in time. Viewed, read to the end, reacted, replied, clicked through.
The grain that works in practice is one row per person, per content item, per event type, per day. Coarser than that and you lose the ability to answer segment questions. Finer and you are storing telemetry you will never query. Once you have committed to that grain, most tooling arguments resolve themselves, because a tool either supports it or it does not.
The identity key is the decision that costs the most to get wrong
Here is the position this article argues for: your identity key is a more consequential choice than your visualisation tool, and it is usually made by accident.
Most improvised models key on email address, because it is the field that appears in every export. Email is a terrible key. It changes on marriage, on rebranding, on acquisition, and on the day IT decides to standardise the domain. Every one of those changes silently splits one person into two, and your unique-reader counts drift upwards while your participation rates drift down.
The stable key is the Entra ID object identifier. It is a GUID, it does not change, and it is what the Microsoft Graph endpoints use natively[1]. Whatever your organisational attributes come from, a directory sync or an HR extract, they need to land against that identifier rather than against a name or an address. This is unglamorous work. It is also the difference between a model that survives three years and one that has to be rebuilt after the next acquisition.
Two related traps. Shared accounts on the shop floor mean one identifier represents fifteen people, so count devices and sessions there rather than pretending it is a person. And service accounts and automated posting will appear as extraordinarily engaged colleagues unless you exclude them explicitly.
Organisational structure is a dimension that moves
This is the part almost every internally built model gets wrong, and it is worth spending a section on because it has a right answer.
Your organisational structure is not a fixed reference table. Teams merge, sites close, a region gets renamed, an entire division moves under a different executive. If your model holds only the current structure and joins historical activity to it, then the day after a reorganisation your entire history quietly rewrites itself. Last January’s numbers for a division that no longer exists get reassigned to whatever absorbed it, and the trend you presented in February is no longer reproducible.
There are two legitimate treatments and you must pick one deliberately.
- As it was. Store the person’s unit at the time of the event. History stays reproducible and last year’s slide still matches. The cost is that comparisons across a reorganisation get awkward, because the units on either side are not the same units.
- As it is now. Restate all history against the current structure. Comparisons are clean and the current leadership sees their own organisation. The cost is that your numbers change retrospectively, which you must be able to explain.
Most IC teams should store both and default to “as it was” for reporting, with “as it is now” available for planning. What you must never do is store only the current structure and present it as history. If you are heading into a restructure, the note on measuring internal communications through a corporate restructuring covers the reporting choreography around this.
Which class of tooling fits which model
Now the tool question, which is answerable once the model is settled. There are four classes in play, and each imposes a data model whether or not you notice.
| Tooling class | Model it imposes | Genuinely good at | Where it stops |
|---|---|---|---|
| Native panels: SharePoint site usage, Viva Engage community insights, Teams analytics | One product, one surface, fixed windows | Answering “is this site or community working” with zero setup and zero cost | No person-level organisational attributes, no cross-product joins, finite retention |
| Microsoft Graph plus Power BI | Whatever you build, which is the point | Full control, already licensed, combines sources[2] | You own the identity key, the slowly changing dimension and the reliability problem |
| Web analytics tags on the intranet | Sessions and pages, anonymous by default | Page-level behaviour, navigation paths, search terms | No person, therefore no segmentation by function or site, and consent complexity |
| Dedicated IC analytics layer | Person, unit, content, event, with history | Cross-channel segmented reporting out of the box | A product decision and a procurement cycle |
The honest framing on native first. Microsoft’s own panels are free, already switched on, and genuinely sufficient when the question is bounded to one surface. A community manager running one Viva Engage community, or an intranet owner watching one communication site, does not need anything else and should not buy anything. Viva Connections reporting adds a useful view of how the intranet is being reached across desktop and mobile[3]. The limits are structural rather than a failing: native panels report on a product, and your question is about an organisation.
If you build it on Power BI
Building the model yourself on Graph and Power BI is a legitimate route, and some organisations run it well. Three things must be said plainly before anyone budgets for it. The Microsoft Graph 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. And a dependable build needs a robust ingestion process with scheduled reconciliation against the native figures, which means you are budgeting for a pipeline rather than a dashboard. The honest guide to building SharePoint analytics with Power BI works through what that costs over three years.
Sequencing the work
The order that works: agree the four entities and the grain, fix the identity key, decide the slowly changing dimension treatment, then choose the tool. Teams that reverse this end up with a dashboard nobody trusts and a rebuild eighteen months later.
Two companion decisions belong here. Define your units before you total anything across channels, because a SharePoint view and a newsletter open are not the same event, a point the piece on why cross-channel totals do not add up makes in detail. And settle who owns what, which the digital workplace guide works through, because a model with no owner decays.
This is the layer Tryane occupies. It reads SharePoint, Viva Engage, Teams and newsletter platforms into one model, keys on Entra ID, joins organisational attributes from the directory or an HR file, holds structure history so a reorganisation does not rewrite last year, and retains unlimited history across product transitions. SOC 2 Type 2 certified, GDPR compliant by design, EU hosting by default with US data residency on request, single sign-on through Azure AD or Entra ID, no agent to install, and a deployment measured in a couple of hours. For the attribute design itself, the guide to audience segmentation for internal communications is the practical companion, and the measurement strategy article covers how to phase it.
Frequently asked questions
What is digital workplace analytics, precisely?
Measurement across the set of Microsoft 365 surfaces employees actually use, joined to organisational structure so the results can be read by function, site, country or contract type. The distinguishing feature is not the number of dashboards but the presence of a shared person and unit model underneath them.
Can we do this with native Microsoft tools only?
For single-surface questions, yes, and you should. Native site and community reporting is free, already switched on and adequate for a bounded question. It becomes insufficient when you need person-level organisational attributes, joins across products, or history beyond the native retention window.
Why not just key everything on email address?
Because it changes. Marriage, rebranding, acquisition and domain standardisation all rewrite email addresses, and each rewrite splits one person into two in your history. Key on the Entra ID object identifier and treat email as a display attribute.
What happens to our reporting after a reorganisation?
That depends on a choice you should make in advance. If you store organisational unit at the time of the event, history stays reproducible. If you restate against the current structure, comparisons are cleaner but past numbers change. Storing both and labelling which one a given report uses is the safest arrangement.
Where does Tryane fit against our existing Power BI reporting?
Usually underneath it rather than instead of it. Teams that have standardised on Power BI as the presentation layer keep it and take Tryane as the source through the API, so what changes is the ingestion, identity resolution and structure history rather than the visuals the organisation already reads.
Sources
• Microsoft Learn, Microsoft Graph reports overview
• Microsoft Learn, Microsoft 365 activity reports
• Microsoft Learn, Viva Connections overview
Further reading
• Why your cross-channel totals do not add up
• The digital workplace guide: components and ownership
• Audience segmentation for internal communications
• Measuring cross-channel internal communications
• Building an internal communications measurement strategy
Tryane runs a 15-minute working session with Heads of Internal Communication, sketching the person and unit model against your own Microsoft 365 estate and showing where the current reporting cannot answer a segment question. Book a slot with Jérémy to schedule yours.