topic Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers? in Developer

How to build a Usage Metrics Dashboard for Power BI Embedded customers?

Baqa — Tue, 30 Dec 2025 07:17:27 GMT

Hello,

We have integrated Power BI Embedded (Analytics module) into our application for multiple customers. We want to build a Usage Metrics Dashboard to monitor customer activity, including:

Page 1 – Overall usage

Total customers
Customers using Analytics
Idle customers
Active clubs using Analytics regularly

Page 2 – Customer-level metrics

Single-select slicer for each club
Metrics such as reports/pages actively used, user-level activity, and error monitoring

Questions:

Can we use Power BI REST APIs or audit logs to get usage information for embedded reports at the user, report, and page level?
If APIs/audit logs aren’t sufficient, what are the best alternative methods to track usage externally for embedded reports?
What is the recommended architecture to capture both report activity and errors for embedded analytics across all customers?

Any guidance, sample approaches, or best practices would be highly appreciated.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

v-echaithra — Tue, 30 Dec 2025 10:40:59 GMT

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.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

Baqa — Tue, 30 Dec 2025 11:44:19 GMT

Hi @v-echaithra Thank you for the detailed response. It has clarified many of my questions.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

cengizhanarslan — Tue, 30 Dec 2025 13:28:32 GMT

Power BI’s Activity Log / REST APIs can give you tenant-level events (e.g., report viewed) and governance signals, but they’re not reliable for page-level usage in Embedded, and in app-owns-data they often reflect the service principal rather than the real end user.

For an Embedded usage dashboard, the standard approach is:

Use the Power BI JavaScript SDK events in your app to capture real usage:
- loaded, rendered, pageChanged, dataSelected, and error
- Log: customerId, userId (or hashed), reportId, pageName, timestamps, duration, error details
Send those events to Application Insights / Log Analytics (or your telemetry DB), then load that telemetry into Fabric/Power BI for reporting.

Recommended architecture:

App (embed) → JS SDK events + app errors → App Insights/Log Analytics
(Optional) Activity Log API → same store for admin/audit context
Build a small “Telemetry” model → your two pages (overall + per-customer) and error rates/top errors.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

Baqa — Thu, 01 Jan 2026 12:49:28 GMT

Thanks @cengizhanarslan

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

AshokKunwar — Thu, 01 Jan 2026 14:34:01 GMT

Re: 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

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

AshokKunwar — Sun, 04 Jan 2026 13:34:20 GMT

Hii @Baqa

Hi! Glad that worked. Could you please click 'Accept as Solution' on my previous reply so I can close this out and help other community members find the fix?

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

v-echaithra — Mon, 05 Jan 2026 08:27:14 GMT

Hi @Baqa ,

I just wanted to check if the issue has been resolved on your end, or if you require any further assistance. Please feel free to let us know, we’re happy to help!

Thank you
Chaithra E.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

v-echaithra — Fri, 09 Jan 2026 11:53:20 GMT

Hi @Baqa ,

May I ask if you have resolved this issue? Please let us know if you have any further issues, we are happy to help.

Thank you.

Re: How to build a Usage Metrics Dashboard for Power BI Embedded customers?

AshokKunwar — Wed, 21 Jan 2026 05:29:55 GMT

Hii @Baqa

I hope this helps you build a robust monitoring solution! If this architectural overview helps, please mark this as an "Accepted Solution."