Function similar to drill-fields in looker?

Ask the Community
1

i was wondering if anyone happened to know if holistics supports drill-fields, where if i click on a count measure - it will show the list of counted rows with relevant fields defined in the dimension.

2

Is this what you are looking for? Drill-through | Holistics Docs (4.0)

3

not really - this just links to other dashboards through filtering that row.

i was hoping that if i click on the count measure in a month, it will show me what rows are being returned.

4

Hi @py1209

May I ask, which kind of drilling in Lookerā€™s doc are you referring to? Drilling into dimensions or drilling into measures?

Currently, we donā€™t support either of those in Holistics yet. An alternative is our drill-through as Becca has suggested above.

  • If you want your users to drill into dimensions like in Looker, you can set up a dashboard with relevant breakdown charts for the drill-through.
  • If you want your users to drill into a measure, you can set up a dashboard with a table containing the underlying data of that measure.

However, we understand that sometimes our drill-through isnā€™t the most efficient/intuitive for those use cases. Thatā€™s why weā€™re already actively working on the solutions for those kinds of drilling. Our tentative release date is in Q1 2025. Weā€™ll keep you updated on the progress. In the mean time, if you have any feedback or ideas for the features, please feel free to share them!

Thank you,
Phuong.

5

I see - I was talking about drilling into measures. Iā€™m glad you guys are working on this because itā€™s super useful for my business users to know which rows are being returned by a measure.

Hopefully itā€™s implemented soon - thank you!

1 Like
6

Hi @py1209 and @Becca_Perry

Weā€™ve just released a new feature: View Underlying Data

It requires zero setup and lets you flexibly tailor the underlying data table to your needs.

Supported visualizations in this Beta version:

  • Line, column, bar, area and combination charts
  • Pie, donut, pyramid and funnel charts
  • KPI
  • Table
  • Pivot table

Since itā€™s still a Beta version, weā€™d love to hear your feedbacks so we can fine tune it for the final version. Thank you so much! :pray:

7

Thanks for the new functionality. My initial reactions are ā€“

  • This is neat!
  • I love that you can choose to still see the visualization while looking at the data.
  • The data table displays too many fields/columns by default.
  • The query pulls too many rows by default.
  • Iā€™m excited about this for internal users, but I have real hesitations about this in our embedded dashboard uses. Our external users would not know what to make of all the data fields. I would want to either keep this feature off for them or somehow limit the fields they have access to display when clicking through to underlying data.
9

Hi @Becca_Perry

Thank you so much for your feedbacks! Please check my response to each of your comment below:

The data table displays too many fields/columns by default.

  • Currently we return all the fields in the data model which is directly related to the selected metric. For example, we return all the fields in data model users when you click on count(user_id)
  • This is our best guess of relevant detail fields, though we understand itā€™s not always as users expect.
  • Do you have any suggestions on how we can improve the default columns here?
  • For the next version, weā€™re planning to support dashboard builders to configure the underlying data table. Hereā€™s our draft, can you please take a look and see if itā€™d be useful to you? Customizing Detail Views

The query pulls too many rows by default.

  • Thisā€™s a valid feedback. Weā€™ve taken note of it for improvement.

Iā€™m excited about this for internal users, but I have real hesitations about this in our embedded dashboard uses. Our external users would not know what to make of all the data fields. I would want to either keep this feature off for them or somehow limit the fields they have access to display when clicking through to underlying data.

  • At the moment we donā€™t support this feature in embedded dashboards yet.
  • Do you think the Customizable Detail Views would be a solution to your concern?
  • Would you want to be able to disable View Underlying Data entirely in embedded dashboards?
10

Looks great!

Glad a user can click on a number on a chart and see exactly which rows are being returned - super useful.

Hoping you guys will be able to add this to the conversion funnel chart (which weā€™ve been using as one of our main use-cases).

In terms of feedback,

  • I think for our external users - if we can preset which data columns they are looking at (per visualization) when they click ā€˜view_underlying_dataā€™, itā€™ll be easier for them to understand. Since, of course, not every column is relevant.
11

Hi @py1209

Thank you for your recognition and feedback!

Yes weā€™re actively working on enabling this feature in conversion funnel. Weā€™ll keep you updated when itā€™s available.

  • I think for our external users - if we can preset which data columns they are looking at (per visualization) when they click ā€˜view_underlying_dataā€™, itā€™ll be easier for them to understand. Since, of course, not every column is relevant.

Regarding this feedback of yours:
Initially we only thought of presetting the data columns at metric level, or maybe dashboard level at the most. But you mention ā€œper visualizationā€. So I have this intepretation:

  • Letā€™s say you have 2 visualizations: (1) Revenue by Country, and (2) Revenue by Product
  • Both feature the metric ā€˜Revenueā€™
  • But you want to be able to configure a set of columns for each visualization.

Can you please confirm whether my understanding is correct?

12

Yes, I do think customizable detail views could solve the problem for the embedded use case but I would not want it to be added work for every. single. chart.

I canā€™t say for sure, but itā€™s possible that we would want to disable View Underlying Data entirely for embedded dashboards. It definitely gave me a sigh of relief to hear it wasnā€™t released there yet!

1 Like
13

Thanks @Becca_Perry for your input!

Yes weā€™ll think carefully when rolling out the View Underlying Data on embedded dashboards :+1:

1 Like
14

Hi @py1209

Good news! View Underlying Data is now available on Conversion Funnel. I hope you and your team will find it useful :slight_smile:

15

Thanks so much!

I also wanted to echo that the current query is pulling too many rows by default, especially when using COUNT(DISTINCT) measures. Hereā€™s what Iā€™m seeing:

  • Issue:
    • When drilling into a chart that uses COUNT(DISTINCT user_id), the underlying data returns all matching rows, not just the unique ones.
  • Expectation:
    • If the measure shows COUNT(DISTINCT user_id) = 13, I would expect the drill to return exactly 13 rows, each representing a unique user_id.
  • Problem:
    • Instead, the drill shows multiple rows per user_id, often with repeated or unnecessary data.
16

Hi @py1209

Thanks for sharing your feedback! I totally empathize with your issue here.

Currently, by default Holistics return all the columns within the data model which your selected measure is related to.

From the case you described above, Iā€™d make a guess that user_id isnā€™t the key identifier in the data model. For example, in this model, order_ids are unique but user_ids can be repeated:

order_id user_id product_id order_date total_amount
101 user123 prod456 2025-05-10 10:00:00 25.00
102 user456 prod789 2025-05-10 10:15:00 50.00
103 user123 prod111 2025-05-10 10:30:00 12.50
104 user789 prod456 2025-05-10 10:45:00 75.00
105 user123 prod999 2025-05-10 11:00:00 30.00
106 user456 prod111 2025-05-10 11:15:00 15.00

To view the table by the unique user_id, directly on the underlying table, you can remove other fields such as order_id and product_id from the table.

However, we still totally understand the frustration when seeing the unexpected result at first, and weā€™re aware that not many users (especially who donā€™t understand data modeling) would know which fields to remove or to keep in the table.

For long term solution, we will try to improve our default set of fields here, and at the same time, work on a feature which allows dashboard builders to define a set of detail fields for their users.