Forum Discussion
How to build a Usage Metrics Dashboard for Power BI Embedded customers?
Hi Baqa ,
You can get user and report level usage, but not page-level usage for embedded reports. Power BI REST APIs and the Microsoft 365 / Power BI Activity Log reliably capture governance-level events, such as report viewed, dataset refreshed, export actions, sharing and access events. These logs work for embedded scenarios as well, but they do not expose page navigation or in-report interactions. They are not real-time and have limited retention.
In embedded setups, activity may appear under a service principal or app identity, depending on the authentication model. So, APIs and audit logs are suitable for answering “who accessed which report and when”, but not “which pages were used or how users interacted with the report.”
For embedded analytics, the supported approach is to use the Power BI Embedded JavaScript SDK provided by Microsoft. The SDK exposes client-side events such as report loaded, page changed, errors during rendering or querying. These events are not stored by the Power BI service, but they are intentionally exposed so the hosting application can capture them.
In practice, this means:
Instrumenting the hosting application with the Embedded JS SDK
Logging page-level and session-level events
Correlating those events with Power BI artifacts (workspace, report, tenant)
This is the only supported way to achieve page-level usage insights for embedded reports today.Power BI Activity Logs that is accessible via REST API or PowerShell are the supported mechanism for governance-level usage such as report views, exports, and refreshes, but they do not capture page-level interactions. For embedded scenarios, page navigation and client-side errors are intentionally exposed via the Power BI Embedded JavaScript SDK, which is the supported way to capture interaction level telemetry in the hosting application. Azure Monitor and Log Analytics are the supported tools for monitoring Power BI Embedded capacity health, throttling, performance, and failures. Microsoft guidance is to combine these components such as: Activity Logs for audit, Embedded SDK events for interaction telemetry, and Azure Monitor for capacity and reliability using consistent tenant, report, and session identifiers, and to export native logs to customer-owned Azure storage for extended retention and analysis.
Hope this helps,
Chaithra E.
Continued ContributorRe: Architecture for Power BI Embedded Usage Metrics Dashboard
Hello! Building usage metrics for Embedded Analytics requires a different approach than standard internal reporting because you are often dealing with external identities. Here is the recommended architecture to achieve your Page 1 and Page 2 requirements:
1. Data Sources: Use the Power BI Activity Log
For Page 1 (Overall usage), the Power BI REST API (Activity Events) or Microsoft Purview Audit Logs are your best bet. Unlike the "Usage Metrics" UI, the Activity Log provides a JSON stream of every "ViewReport" event.
- Benefit: It captures the Workspace ID, Report ID, and User ID.
- Limitation: It does not natively capture "Page Level" clicks or "Button" interactions within the iframe.
2. Architecture for Page 2 (User/Page Level & Errors)
To get granular page-level activity and monitor errors, you should implement Client-Side Telemetry.
- Method: In your application code where you initialize the Power BI Embed object, use the Power BI JavaScript API to "listen" for events.
- Events to Capture: pageChanged, buttonClicked, error, and rendered.
- Storage: Send these events from your app to Azure Application Insights or a Log Analytics Workspace.
3. Recommended Workflow:
- Extraction: Use an Azure Function to pull the Power BI Activity Log daily.
- Telemetry: Push client-side events (Page changes/Errors) from your web app to Azure SQL or Log Analytics.
- Modeling: Combine these two sources in a Power BI Semantic Model.
- Multi-tenancy: Use Row-Level Security (RLS) on your Usage Dashboard so you can use one report to show different clubs their own data.
Why this works:
This hybrid approach gives you the "Official" audit data for licensing/compliance and the "Granular" telemetry for user behavior and error debugging.
I hope this helps you build a robust monitoring solution! If this architectural overview helps, please mark this as an "Accepted Solution."
Best regards,
Vishwanath