Measuring BI Adoption: Usage Data That Tells You What to Retire

Nobody retires reports. Teams build them, publish them, and move on. Five years later the workspace holds four hundred reports, half of them stale, and every one of them is a maintenance liability nobody wants to own. The fix is not a spring clean. It is treating the reporting estate like an asset register, with a lifecycle, an owner, and telemetry that tells you what is actually in service.

Your reports are an asset register

In asset management, you would never leave a pump on the books without knowing whether it runs, who maintains it, and what it costs to keep. Every asset has a lifecycle: commissioned, in service, degraded, decommissioned. A reporting estate deserves the same discipline, and most organisations give it none. Reports are commissioned enthusiastically and then never decommissioned, because nobody is sure who still relies on them and nobody wants to be the person who deleted a dashboard the CFO opened once a quarter.

The discipline is not hard. It requires two things: an owner for the estate, and evidence. The evidence is usage telemetry. If you cannot see who opened a report, how often, and how deeply, then every retirement decision is a guess, and guesses lose to politics every time. Instrument the estate first, and the decisions make themselves.

The three data sources

In Power BI you have three distinct telemetry sources, and they answer different questions. Do not try to make one do the job of another.

1. Per-report usage metrics.

Every published report carries its own usage metrics report: views, unique viewers, and the split across the web and mobile. This is your first stop and the easiest to reach. It answers "is this specific report used, and by how many people?" The catch is that it is per-report and viewed one at a time, so it is fine for spot checks but useless for reasoning about the estate as a whole. Microsoft's usage metrics documentation covers what each field means.

2. Tenant-level activity events from the audit log.

The audit log records every view, edit, share, and export across the whole tenant as individual events, tagged with user, artifact, and timestamp. This is the source you build portfolio analysis on, because it covers every report at once rather than one at a time. The audit and activity log documentation explains the event schema and how to pull it.

3. Capacity metrics for cost attribution.

If you run Premium or Fabric capacity, the capacity metrics tell you which reports and refreshes consume the resource. This is how you turn "unused" into "unused and expensive," which is a far stronger retirement argument. Pair this with your licensing and capacity planning so you can attribute cost to the reports actually earning their keep.

Adoption metrics worth tracking

Raw view counts flatter popular reports and hide the interesting failures. These five metrics tell you more:

• Unique viewers per report per month. The headline health signal. A report with three hundred views from one person is not adopted, it is one refresh habit.
• Views per intended audience member. Divide viewers by the size of the audience the report was built for. A finance report seen by four of forty controllers has an adoption problem the raw count hides.
• Depth of use, or interactions per session. Do people filter, drill, and cross-highlight, or open and bounce? Shallow sessions on a heavy report usually mean it answers a question nobody actually has.
• Time since last view. The single most useful retirement trigger. Sort the estate by this and the candidates surface themselves.
• Ratio of viewers to authors. A report whose only viewer is its author is not a report, it is a saved query. This ratio finds the private work masquerading as published assets.

A portfolio review on 140 reports

Here is what the numbers look like in practice. On one estate I reviewed 140 published reports against ninety days of exported activity events. Three groups jumped out immediately: 31 reports with zero views in ninety days, 22 reports viewed only by their own author, and a top 9 reports that between them carried 71 percent of all views. That last figure is the one that reframes the whole conversation. The estate is not 140 reports, it is 9 reports and 131 liabilities of varying weight.

The zero-view 31 and the author-only 22 are the easy wins: 53 reports, more than a third of the estate, gone in one pass with almost no risk. The 78 in the middle are the real work, because that is where duplicate versions of the same report accumulate. The top 9 are where your certification and reliability effort belongs, since they are what the organisation actually runs on. Reports fed from operational systems, such as a Business Central financials dashboard or a Maximo maintenance dashboard, tend to cluster in that top group, and they are exactly the ones worth hardening because their absence would be noticed within the hour.

Retiring the director's pet report

The hard retirements are not technical, they are political. Somewhere in your zero-view list is a report a director commissioned, praised in a meeting, and has not opened in four months. Delete it and you will hear about it. So do not delete it.

Move it to an archive workspace and give it a recall window. The routine I use: at the point of retirement, the report moves to a dedicated archive workspace, the owner gets a short note ("this has had zero views in 90 days, it is archived and fully recoverable for 60 days, tell me if you still need it"), and only after the 60-day window passes with no recall does anything get deleted. This does three things. It removes the clutter from the live estate immediately, it gives the owner a genuine, low-friction way to object, and it converts a confrontation into a process. When a director does come back, restoring from archive takes two minutes and you look responsive rather than reckless. In practice, most archived reports are never recalled, and the ones that are usually get promoted back with a real owner attached, which is a better outcome than the limbo they were in before.

The recall window is the whole trick. Deletion is a decision you defend; archiving with recall is a decision the owner declines to reverse. The burden of proof moves to the person who claims they need it, and the telemetry has already made that claim hard to sustain.

The quarterly estate review

Make this a recurring ritual, not a one-off purge, or the estate simply regrows. A workable quarterly agenda:

1. Refresh the usage export and rebuild the four groups (dead, private, watch, core).
2. Action the dead and private lists: archive with the 60-day recall window, notify owners.
3. Review last quarter's archive: delete anything past its recall window, promote anything recalled.
4. Consolidate duplicates in the watch group and assign an owner and next-review date to survivors.
5. Re-certify the core reports and confirm their refreshes and capacity headroom are healthy.

One person owns the agenda, it takes an afternoon a quarter once the export exists, and the estate stops growing without limit.

The one metric to report upward:

Do not send leadership a spreadsheet of 140 rows. Report a single number: the share of the estate that is actively used, defined as reports with at least one unique viewer beyond their author in the last 90 days. In the example above that is roughly 62 percent before the cleanup. Track it quarter over quarter. A rising number means the estate is getting leaner and more trusted; a falling one means reports are being built faster than they are being adopted, which is a signal leadership understands without any BI vocabulary at all.

A note on independence: I do not resell Power BI, capacity, or any reporting platform, and I take no vendor commissions. The product names here are the tools I use on client work, nothing more. Feature and retention details change, so confirm the current behaviour against the linked documentation before you build a process on it.