Designing Explorations

What makes a good exploration

There are three things you should be optimizing for when building your explores:

1. Correctness Are query run through the exploration giving the proper numbers?

2. Usability When you design an Exploration, you’re like a Product Designer and you deliver your users an application. And when you design software, it not only has to work, it has to be usable. When a user who is not an expert in your data loads your exploration, it should be immediately clear how to get the answers they’re looking for.

3. Performance While there may be multiple ways to get Whaly to generate a query, there will typically be one way that has the optimal performance. Having a fast exploration will lower your data consumer waiting time, increase their productivity and willingness to query your company data.

Whaly guidelines to make powerful Explorations

Make multiple small explores instead of a single big one

It's really tempting to create a single Exploration and make it grow with every new metric / use case that your Data Consumers are coming with. The power of using "Related Data" can easily make you join a dozen of tables in the blink of an eye.

But every new added table in an Exploration comes at a performance cost, making queries using it slower. Also, opening a very large Exploration can be very intimidating for Data Consumers and might scare them off.

As a rule of thumb, a properly balanced Exploration should have between 3 and 6 related tables. If your Exploration have more tables than that, you probably have to push some of the joining logic into your "Modelisation Layer" to produce Models that are more consolidated.

We generally advise to produce 1 or 2 Explorations that should be very generalist and cover most of your business domains (Marketing / Sales / Product Usage / Revenue) thanks to an "Event Model" approach. Those should be the go to Exploration for very broad questions. Only important metrics and dimensions should be surfaced in those.

When Data Consumer needs to ask more precise question and look further, there is a second range of Exploration that should be built to help them dive in on a specific topic / domain. Those should be "specialist explorations" that will contains more details over what is going on.

There is no silver bullet in Exploration design but rather a good balance between generalist and expert ones.

Aggressively curate field lists

When you design an explorations, Data Consumer will try it and run queries that you never thought of previously. This is a good thing but you don't want it to become: “When I did this, the answer didn’t make sense! I don’t trust the data.”.

You want users to have predictable, positive interactions with the explorations you give them.

When you deliver software, every feature is “exposed area”  it means  stuff that people will start relying upon and that can break.

The more features, the more exposed area, the more opportunities for things to go wrong. Simple applications work better because there are fewer things to break.

In the case of Explorations, Dimensions and Metrics are features that you offer to your users. Each new one will create an entire field of new possibilities and of bugs / problems. So every time you add a new Dimension or Metric, you have to weight the pro and cons.

It's not because you can that you should expose every field of the database to your Exploration. A curated list of the most useful fields should be defined with end users to reduce the exposed area.

It will as well reduce the cognitive load of Data Consumer when writing down Queries. The less choice, the less "analysis paralysis" you'll create.

Document everything

Writing documentation is paramount for your Exploration to be properly discovered and used by Data Consumer. It'll decrease the chance of them to do things the wrong way, will improve their chance to run query by themselves and will improve their overall happiness.

It's really hard sometimes to document dimensions / metrics because they make so much sense for us as we build them but for newcomers or people that never worked in a given domain, it can be very hard to understand what is a given for you.

So, document everything, create dummy dashboards and question with your Exploration to demonstrate how they could be used to get business insights and make sure that all descriptions are always filled!

Do personalized workshops / training

Whenever you build an Exploration, you are doing it for your Data Consumers. You need to train them in the most personalized way to use the tool that you created for them in order to increase adoption.

It'll be also the perfect occasion for you to gather feedback about how they want / need to consume data and what their business challenges are like. It'll grow you as a person and will give you additional insights on how you can deliver new experience for them.