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.
Is this what you are looking for? Drill-through | Holistics Docs (4.0)
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.
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.
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!
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!
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.
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 oncount(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?
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.
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?
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!
Thanks @Becca_Perry for your input!
Yes weāll think carefully when rolling out the View Underlying Data on embedded dashboards
Hi @py1209
Good news! View Underlying Data is now available on Conversion Funnel. I hope you and your team will find it useful
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.
- When drilling into a chart that uses
- Expectation:
- If the measure shows
COUNT(DISTINCT user_id) = 13
, I would expect the drill to return exactly 13 rows, each representing a uniqueuser_id
.
- If the measure shows
- Problem:
- Instead, the drill shows multiple rows per user_id, often with repeated or unnecessary data.
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.