Direct answer: The main Power BI Usage Metrics limitations are workspace-level scope, short built-in retention, permission requirements, differing definitions between current and legacy experiences, client-side gaps for page and performance telemetry, and the fact that usage evidence cannot establish ownership, business criticality, or safe retirement on its own.
Power BI Usage Metrics is often the right first tool. It is included in the platform, familiar to report creators, and useful when you need a recent answer about one workspace. Problems begin when a team treats it as a complete tenant inventory, a permanent history, or an automated report-retirement system.
The details also matter because Microsoft currently documents both a previous usage report and an improved usage report in preview. They have different retention periods, telemetry definitions, and limitations. Any policy or extraction process should name the experience and review date instead of repeating one universal “Power BI retention limit.”
Power BI Usage Metrics limitations at a glance
| Limitation | Operational consequence | Practical response |
|---|---|---|
| Workspace-oriented experience | Portfolio review becomes repetitive across many workspaces. | Use a consistent cross-workspace collection and model when the portfolio question justifies it. |
| Short rolling history | Old activity disappears before annual, seasonal, or long-term trend questions are asked. | Export and retain supported activity in an approved external store before it expires. |
| Edit-level access required | Viewers and some governance stakeholders cannot open the report themselves. | Define the identity, workspace access, and distribution model before relying on it operationally. |
| Client telemetry gaps | Page and performance events can be undercounted or missing. | Publish source limitations beside the metric and avoid false precision. |
| Usage is not inventory | Items with no events can disappear from an activity-only analysis. | Combine current inventory with activity history. |
| Usage is not business context | Low activity can be mistaken for permission to delete. | Add owner, criticality, seasonality, replacement, dependency, and recovery checks. |
1. The current and previous reports are not interchangeable
Microsoft’s improved Usage Metrics Report is currently documented as a preview experience. Microsoft states that it covers the last 30 days, excluding the current day. The previous usage metrics report documents a 90-day window. That difference alone is enough to make an undated comparison unreliable.
The definitions also changed. In the improved report, a Report View is an open-report event based on service activity. Changing pages is measured separately as a Report Page View. The previous report relied more heavily on client telemetry and used different view behavior.
Policy rule
Record the exact Microsoft experience, metric definition, evidence period, and review date. “Views in Usage Metrics” is not a sufficiently precise data definition.
2. Built-in retention is not a long-term history
A rolling 30- or 90-day report can answer recent questions. It cannot reconstruct activity that has already left the source. That becomes a problem when report owners review quarterly, when a report is used only during budgeting season, or when a governance team needs year-over-year adoption evidence.
Microsoft’s improved usage documentation explicitly recommends periodically exporting data to an external store when longer retention is required. The key word is periodically: storing today’s snapshot does not recover last year’s expired events.
If durable history matters, define the collection frequency, late-arriving behavior, retention policy, backup, and recovery process. See the companion guide to keeping Power BI usage history beyond native windows.
3. Usage Metrics does not provide a complete inventory
Activity answers “what events were recorded?” Inventory answers “what exists now?” Those are different datasets.
Microsoft notes that admin APIs represent the current deployment state, whereas usage history can still refer to content that was later deleted. The inverse matters too: an item with no qualifying activity might not appear in an activity-only result. A governance model needs stable report and workspace identifiers from inventory as well as events from usage sources.
This is why an unused-content process should begin with inventory and left-join activity to it—not begin with activity and assume the missing items do not exist. Read the report inventory and ownership article for the fields usage data cannot supply.
4. Permissions and tenant settings affect availability
For the improved usage report, Microsoft documents that a user needs Power BI Pro or Premium Per User to run and access the usage data, edit access to the report, and an enabled usage-metrics tenant setting. Viewer permission is not enough. Per-user data can also be disabled or masked by tenant configuration.
That means “we cannot see viewer names” is not always a collection bug. It may be the intended privacy setting. Document who approved identifiable usage, which security groups are in scope, who can read the output, and how long those identities are retained.
5. Page views and performance depend on the client
The improved report uses service telemetry for Report Views, but Microsoft says Report Page Views and performance metrics still depend on information reaching Power BI from the user’s device. Network latency, ad blockers, firewalls, and organizational network rules can prevent those events from arriving.
Microsoft also lists specific gaps: some fields are blank in preview, app-report pages can be absent from the report-pages table, performance measurements exclude some kinds of views, and paginated reports do not provide the same performance metrics.
Page and performance signals are valuable for prioritization, but they should be described as recorded telemetry—not a perfect count of every human interaction.
6. Usage Metrics and the activity log will not always match
Microsoft distinguishes client-collected usage data from service-collected audit activity. Some metrics exist only in one source. Page views, for example, are not part of the audit log. Subscriptions can also create view events when the service captures a report snapshot for email.
A discrepancy therefore does not prove that one dataset is corrupt. Define the question first:
- Use inventory APIs to establish what content currently exists.
- Use service activity when the question is about auditable open-report events.
- Use supported page telemetry when the question is about page-level behavior.
- Use owner and process data when the question is whether content is valuable or safe to change.
The detailed comparison is in Power BI Usage Metrics versus the activity log.
7. Usage evidence cannot make the retirement decision
Zero recorded activity is a reason to review, not a deletion instruction. A report can be annual, regulatory, newly published, used through an unsupported path, or retained as a recovery artifact. Usage also cannot tell you whether a replacement exists or whether an owner approved retirement.
A responsible workflow adds business criticality, seasonality, audience, owner, replacement coverage, dependencies, communication, archive location, and recovery period. Use the free Power BI report retirement checklist before removing content.
When native Usage Metrics is enough
Stay with the native experience when the scope is one or a few workspaces, recent activity is sufficient, the relevant owners already have access, and nobody needs an operated historical pipeline. Adding infrastructure to answer a small question creates unnecessary maintenance.
A maintained cross-workspace system becomes more useful when you repeatedly reconcile important workspaces, need history under your retention controls, or require consistent definitions for portfolio decisions.
Primary sources
- Microsoft Learn: Monitor Usage Metrics in Power BI workspaces (preview)
- Microsoft Learn: Monitor report usage metrics
- Microsoft Learn: Tenant-level auditing
Need one maintained view across selected workspaces?
UsageVault preserves supported activity in your SQL environment and delivers a Power BI-native decision model. Confirm the scope, source boundaries, and fit in a 30-minute walkthrough.