Report/Dashboard Usage Monitoring

Hi,

I am the new Product Manager Data Warehouse & BI at our company and new to holistics.io, which we use for dashboarding.

To get an overview which of the lots of dashboards my team developed in the past are really in use, I would need sth. like an overview of how often each dashboard was opened lately (ideally by which user and including a usage trend of the last year).

Is this or sth similar possible in holistics?

Thanks alot for any help,
Peter

2 Likes

Hi Peter,

Currently we haven’t had any feature to monitor dashboard usages as you mentioned. However, would you like to share more details about your case, and what does your ideal solution look like?

Hi,

thanks for the answer and I am happy to share more details. My use case is twofold:

A)
We are having hundreds of dashboards and it is quite hard and time-consuming to keep them all up and running. Just a normal maintenance trap which consumes more and more time.
If we had an overview that half of the dashboards are not used at all, we could simply remove them and concentrate on the used dashboards, freeing us time for other tasks than mere dashboard maintenance.

B)
An important performance KPI of my analyst team is how much value we are providing to the company. This value is broken down to dashboard usages. The more a dashboard is used in our company, the more value it obviously provides. The more of those valuable dashboards we create, the better we are performing.
If we had an overview on the number of usages by dashboard, we can track this number and see an evolution over time and measure how much value we are providing for our users.

Solution idea:
There is already a page for jobs monitoring and activity log. I could imagine an additional menu item for dashboard (and report) usages with the possibility to select a time range, maybe a filter/search possibility to restrict the results. If there would be a simple list of dashboards and corresponding usages with timestamp and user, together with an export possibility to csv… that would already be great!

Thanks alot,
Peter

1 Like

Thank you for sharing your case @Peter_Massuthe
As far as we understand, you’d like to know which reports/dashboards are used the least, so that you can remove them / don’t need to maintain them anymore. Please correct us if we missed anything.

If it’s your case, would you mind sharing with us more detailed on what it will look like:
1/ What (important) information do you need to monitor the dashboard/report usage?
For example, number of dashboard/report views through time.

2/ What behaviors do you want to do to know more about the dashboard usage?
For example, filtering data by date

It would be better if you could give us a sketch of your ideal usage monitoring page. Thank you!

Yes that is exactly the goal: see/detect unused dashboards in order to lifecycle them and reduce maintenance efforts.

As important dimensions I would only need the name of the dashboard and the only KPI I am interested in is #views per month over the last months. A table would be sufficient for me, a column chart with numbers and totals would be nice to have.

As for filtering or additional features, I think all of them are ‘nice to have’ in my use case. But I could image a date selector to focus on a specific time period, and maybe a text filter for the dashboard name. Sorting ascending/descending according to the number of usages would also support my use case.

In a perfect high-end scenario I could image to have a few internally accessible holistics variables similar to the filter variables (e.g. sth like {{#dashboard_views}}, {{dashboard_name}}, {{user_name}}, etc.) available. Then I could use all dashboard capabilities of holistics and just build my own dashboard according to my needs :slight_smile:

1 Like

I think basic data like dashboard viewed, user, date/time is a great starting point.

I’d love to see that explanded though to also include things like

  • time spent
  • filters applied
  • report interactions
  • etc

that will get a better idea of whether they’re simply viewing it, or whether they’re interacting with it (and what parts they’re interacting with)

If I see there is a specific report that is interacted with a lot, I can consider whether I can provide some additional enrichment to this report.

2 Likes

We would also love the ability to see this data.

Our use case is very similar to the above explanations.

The main underlying issue is not being able to understand usage of Holistics at all. Are people using the platform or not? Are people accessing dashboards or not?

I think a Holistics Dashboard on Holistics would be a great start to this to provide the sort of overviews as described above by all.

The best scenario might be a basic dashboard but also the ability to extract the data, via a webhook or API that we can load into our warehouse and use. This can then be fed into another dashboard that we have more control over.

1 Like

Seeing this supported by more users, I thought to share the workaround that we found for us.

Using an SQL dashboard (holistics 2.0), you just take any of the tiles and hardcode an insert statement right before the actual business logic. This is how it could look like

INSERT INTO dashboard_access_logs VALUES (NOW(),‘Dashboard XYZ’);
select from ; – whatever you would normally do here

As you know which dashboard it is, you hardcode the title parameter to contain the dashboard name. The timestamp parameter will allow you to analyze later. Do not forget to click the radio button “non-select query” as otherwise holistics will complain that this is not a SELECT statement.

For also being able to track a dashboard 3.0, we created a database function which does the same insert statement but additionally returns the timestamp. (Actually we could use the same approach for dashboards 2.0, too, now that I am thinking about it ;)) Additionally, we created one individual data model per dashboard that we want to track. The data model basically just does this:

SELECT insert_dashboard_tracking(‘Dashboard XYZ’) AS current_time_stamp

Now you will need a separate tile on your dashboard XYZ showing “current_time_stamp” from the corresponding data model XYZ. You need this step since if the data model is not really used, it will not trigger the insert.

Having a table with access timestamps and dashboard name in your DWH, you now can build your own dashboard visualizing access over time grouped by dashboard name, for instance.

Hope this helps :slight_smile:

1 Like