Big Looker Explore vs Small

I have too many explores at my org at the moment which clutters the user experience. Are there best practices and  also governance principles for  data practitioners to implement and enforce at the implementation level?

0 2 239
2 REPLIES 2

Dawid
Participant V

Good basis is to leverage two things:

  1. Multiple joins vs separate explore - you need to find a good balance between having things separately or just adding them to a main explore of an entity. Remember Looker builds SQL dynamically so even if you have 10 joins but use fields from 2 - there will actually be 2 joins in SQL
  2. Aggregation explore - this is a must in every instance for me. Many queries are just building a time series with measures (sometimes with filters or pivots) but people use raw data explores to create them, and also merge queries if they have to merge simple metrics from different areas. Aggregation explore where all your metrics are aggregated by a small list of dimensions (something that spans across all or 90%+ of your metrics), ie. time, country, user_type

To me this is the beginning when I evaluate a Looker instance. Unfortunately it’s very easy to let th enumber of explores grow out of control 😄

@Dawid Thanks for your response. I completely agree its so easy to let the number of explores go out of hand. But is it too common a problem?

My question was more on the lines on how to cater to different business requirements before we even set out to build an explore. Should we have one explore with large number of use cases like multiple feature analysis on a website to build a omnichannel experience bundled in one explore,(e.g visits →  conversions or cohort analysis of all features bundled into one ) which does need  a lot of data modelling rather one explore for each feature?  

Top Labels in this Space
Top Solution Authors