Usage, audit and adoption

Two views: audit and adoption

Usage data serves two masters. Audit asks 'who did what' — for security and compliance. Adoption asks 'is this being used, and is it worth what it costs' — for ROI and rationalisation. The same telemetry feeds both.

The activity log

Power BI/Fabric records an activity log of operations — views, shares, publishes, exports, deletes, print, refresh, tenant-setting changes and more — each with the actor, timestamp and target. Two ways to read it:

• Get-PowerBIActivityEvent (and the admin/activityevents REST API) — the Power-BI-native feed, queryable per day.
• The Microsoft 365 / Purview audit log — Power BI events also flow here, alongside the rest of the tenant's activity, for unified investigation and longer retention.

This is the evidence layer for exposure and change: an unexpected export of sensitive data, a publish-to-web event, a share to an external user — all land here with a name attached.

Usage metrics

Per-report usage metrics show views, distinct users, and trends over time, so you can see which content is loved and which is ignored. At estate scale, the admin monitoring workspace and the scanner APIs let you build a tenant-wide adoption picture.

Building the adoption/ROI story

• Rationalise — reports/models with near-zero views are candidates to retire; they still cost capacity memory and clutter.
• Attribute value — high-usage content justifies its capacity and licence spend (ties to cost governance and the F64 decision).
• Spot risk in usage — heavy export/print or external-share activity flags where governance controls may be too loose.

Failure modes

• No monitoring — decisions on gut feel; nobody knows what's used or who's exporting.
• Short retention — the native activity feed is queried per-day and isn't a long archive; without routing to the audit log/an archive, older evidence is gone (serv365's own archiving thesis).
• Adoption ignored — orphaned and duplicate content accumulates, inflating capacity cost and confusing users.
• Audit reviewed only after an incident — the events were always there; nobody was watching.

What to watch (proofs)

• The activity feed itself: Get-PowerBIActivityEvent / admin/activityevents pulled daily and archived — the durable who-did-what record (point-in-time queries alone lose history).
• Risky operations: export, print, publish-to-web, external-share and delete events surfaced with the actor — the security-relevant subset.
• Adoption census: per-report usage metrics and the scanner (admin/workspaces/getInfo) to find zero-view reports and orphaned semantic models — the rationalisation list.
• Change attribution: tenant-setting and permission-change events tied to the drift monitoring (governance concept) — an unexpected actor is an incident.
• Cross-check with the M365 audit log for events beyond the native feed's window.