Report and Dashboard Usage Metrics in Power BI

One thing we tend to overlook as technical folk working in the business intelligence arena is the importance of analytics about analytics. However, to business folk, it is quite important that they know how valuable their reports and dashboards are to others, if not what’s the purpose in them doing what they do if nothing is being used. The same applies to reports and dashboards in Power BI.

Power BI Usage Metrics Location

Power BI offers something known as Usage Metrics for each report when you access reports or dashboards off the Power BI portal. You can find it above the top left of each report, which when clicked on gives you a summary of how your report or dashboard has been used.

Power BI Usage Metrics

It includes quite a few useful insights as to the main report’s usage. However, as humans can never be satisfied, the business user naturally will ask for more analysis on top of what they see on the summary. For instance, “I need to see at-a-glance which user looks at which page of the report more often”. That’s when you wished you had a way of providing users with customization options of report usage metrics. But there is actually a way.

Each app workspace gets its own report usage metrics data set, it’s just that you don’t see it when you are in the portal. In order to access it (at least for now) you need to use Power BI Desktop. When you open Power BI Desktop, you need to sign-in with the appropriate login, and then choose Power BI service from Get Data menu item. You then get listed with a set of app workspaces; within each you would find a list of all the datasets that were every published to each of the workspaces. Additionally, Power BI will also give you two more datasets: Report Usage Metrics Model and Dashboard Usage Metrics Model. However, these data models will only show up if you had attempted to view usage metrics at least once on one of the reports of the app workspace. The moment you click on the Usage Metrics link and the following happens; that is when the model is created:

Usage Metrics Generating

Usage Metrics Generated

And now, it’s your playground, a whole new data model that gives you analytics on the produce of another data model.

Power BI service



Unexpected Exception in Power BI connected to SQL Server 2016 Analysis Services

One interesting issue that showed its ugly head in my recent project was an unexpected exception that popped up on all visuals on a Power BI report. How it happened was quite strange; one moment all the reports were working fine. The next moment when a report visual was modified and deployed to Power BI, all the visuals start turning into a grey box with a cross, with a “See details” link. The details weren’t at all helpful. Just, “An unexpected exception occurred.”:

Clicking on the “Copy Details” link and pasting on a text editor, and quickly scanning through showed this:

And to make matters worse, all subsequent report loads, including that of other reports, puts the reports into hang, until Analysis Services is restarted. The cycle starts again when the offending report is opened again.

A little digging around pointed at a bug on SQL Server 2016 SP1 Analysis Services. I’m not sure if the problem occurs on a version prior to SP1, however there is a fix: SP1 CU5 (KB Article: KB4037354). Once installed the problem disappears. I tested the issue out on SQL Server 2017 Analysis Services, and this problem does not occur on SQL Server 2017.

Distinct Count of Dimension based on a Filtered Measure

Okay, so we have this brand new awesome project going on; first time on Tabular model, and that too with a large number of measures connected to Power BI and all that jazz. The model would contain all those standard measures that the organization used, while we built some Power BI reports using these measures, with some visuals needing some improvisation on top of the standard measures, i.e. requirements specific to the reports.

Enthusiastic as we were, one of the hardest nuts to crack, though it seemed so simple during requirements gathering, was to perform a distinct count of a dimension based on a filtered measure on a couple of the reports. To sketch it up with some context; you have products, several more dimensions, and a whole lot of measures including one called Fulfillment (which was a calculation based on a couple of measures from two separate tables). The requirement was to get a count of all those products (that were of course filtered by other slicers on the Power BI report) wherever Fulfillment was less than 100%, i.e. the number of products that had not reached their targets.

Simple as the requirements seemed, the hardest part in getting it done, was the limited knowledge in DAX, specifically, knowing which function to use. We first tried building the data model itself, but our choice in DAX formulae, and the number of records we had (50 million+) soon saw us running out of memory in seconds on a 28GB box; Not too good, given the rest of the model didn’t even utilize more than half the memory.

Using calculated columns was not a possibility since the columns that made up the measures that made up Fulfillment was from a different table, and the calculation does not aggregate up.

Since it was a report requirement, we tried doing it visually, by pulling in the Product and the Fulfillment fields on to a table visual, and then filtered Fulfillment, as so:

And then performed a distinct count on product, and voila! it performed a count, but alas! we realized that the filter gets disabled/removed when that happens. Which means the count always ends up being a count of all.

A frenzy of DAX formulae at the Power BI level did not help either, until we tried out the VALUES() function, courtesy direction from Gerhard Brueckl (b|t), trust the MVP community to have your back.

The VALUES() function returns a single-column table of unique values from a specified table. Hence using the FILTER() function we were able to extract the unique products where fulfillment was less than 100%, and then used the COUNTROWS() function to simply count the number of records returned.

Product Short of Target =
VAR ProductCount =
COUNTROWS ( FILTER ( VALUES ( 'Product'[ProductCode] ), [Fulfillment] < 1 ) )
RETURN IF ( ISBLANK ( ProductCount ), 0, ProductCount )

It is very easy to overlook VALUES as a function that would give you unique values. Hence why it is important that you have an overall understanding of what each DAX function can be used for, or at least get your hands on a DAX cheat sheet of sorts pinned against your wall. Glad this worked out though.

What’s the difference between Live Connection and DirectQuery in Power BI, and where do they fit?

Hot on the heels of the question I was asked a few days ago, comes another closely related one: “What’s the difference between Connect live to a data source and DirectQuery a data source in Power BI?”

We had already established that there are two methods in which we could interact with data using Power BI: loading data into Power BI and accessing the data source directly.

Connecting live and DirectQuery both fall into the latter method, but there is a difference.

In DirectQuery mode, you access the data source, such as a relational database or data mart for data, but then you would create calculated columns or measures on top of it in Power BI generating a data model layer, something similar to a database view, if you may. The data still exists at the data source; but is pulled through the data model on Power BI onto the the visuals. The end users and report creators will see and interact with the data model on Power BI.

In the case of Connect live, the data model itself is at the source, you interact with it directly and no data model layer is created on Power BI. All measures, calculated columns and KPIs are provided by the data model at the source, along with the data. End users and report authors will see and interact with this data model through Power BI.

If you would compare these two methods on a conceptual level; DirectQuery mode is used in cases of self-service where you have data marts or a data warehouse on a relational database, and business users build their own data models off this for their business needs. The data marts or data warehouse will integrate data from various systems, and provide base measures with related dimensions.  Business user may create custom measures and calculated columns on top of this to suit their reporting and analytic requirements, and then explore data and build visual reports. Think of this as the data discovery phase of the self-service exercise.

Live connections would probably be used in scenarios where the analytic needs are better understood, and/or the type of analytics that were described above have matured and has become a mainstream in the organization. Here data models are built off the data warehouse using Analysis Services (multidimensional or tabular), with measures, calculations and KPIs that were earlier part of the self-service (and the data discovery exercise) incorporated in it. Business users now have established reports and dashboards that showcase organizational performance powered by established data models. Think of this phase where things have evolved into corporate BI that gives real value.

[SUBJECT TO CHANGE] Out of the whole bunch of supported data sources, Power BI currently supports the following in DirectQuery mode:

  • SQL Server
  • Azure SQL Database
  • Azure SQL Data Warehouse
  • Oracle Database
  • Teradata Database
  • Amazon Redshift (Preview)
  • Impala (Preview)
  • Snowflake (Preview)

and the following using a Live connection:

  • Analysis Services Tabular
  • Analysis Services Multidimensional
  • Azure Analysis Services (Preview)

Consuming Live Data Sources vs On-Premise Data via gateways

So I got this question today, on what seemed to be a little confusing for the questioner, about two features of Power BI Pro.

Power BI Pro - Two Features

The question: “Why does it say ‘Consume live data sources with full interactivity’ as one feature while the other feature says ‘Access on-premise data using the Data Connectivity Gateways’, while it is obvious that if you need to connect to an on-premise data source to consume live data it has to be through a gateway?”

Okay, this is how I would explain this:

‘Consume live data sources with full interactivity’ means that you can directly access live data sources, such as relational databases, or data models built atop Analysis Services without having to load the data into Power BI first. Power BI has two ways of providing data to the user to build reports: “Import” and “Direct Query/Connect live”. The former allows you to connect to the data source, pull in the required data into Power BI and build a model off that, and then let the consumer build reports off this data model. Here the user hits Power BI for the data. The latter allows you to directly connect to the data source via Power BI and build reports off the data structure that already exists at the source, either by creating a model layer or using the model at the source. It is this latter method does this feature describe.

The other feature, ‘Access on-premises data using the Data Connectivity Gateways’ just mean that in order for you to get data from an on-premise source you need to use a Data Connectivity Gateway. The gateway is but a security mechanism that allows Power BI (which is a cloud service) to access a client’s secure environment (which is on-premise) to access data, regardless of it using the “Import” or the “Direct Query/Connect live” modes.

Of course, if you were accessing a cloud based data source such as an Azure SQL Database, an Azure SQL Data Warehouse or Excel files on a SharePoint Online folder, you would not need a gateway; and you can access them using “Import” or consume live data with full interactivity using the “Direct Query/Connect live” mode.