Data is powerful, but can be overwhelming. Especially if you don’t have a background in databases and/or analytics. This is why many self-service analytics projects become frustrating for everyone involved - users are unsure about what to do with all of the data, while analysts can’t understand why users aren’t digging into what they’ve built.
As a pre-sales team at Looker, we’ve worked with many companies from a multitude of data backgrounds to get them up and running with Looker. From working with these customers and prospects, we’ve seen over time what makes (or breaks) an end user’s experience, both with Looker and with data in general.
Here are some of our best practices.
In order to provide real self-service analytics, you should consider your different users and their goals. Here are a few guiding questions to get you started:
Not sure about some of these questions? Don’t hesitate to sit down with a user and hear what they think.
Next, you need to start thinking about how these apply. First, we will start with some high level advice then dive into an example to show what this looks like in real life.
With LookML you don’t have to feel limited by the table structure or the naming conventions of your database, you have the power to curate the self-service environment to make exploring data an amazing and intuitive experience for your end users.
hidden: Hides a field from the field picker but the field is still accessible to use behind the scenes in calculations / joins
view_label: Enables you to change how a view name appears in the field picker. Also allows you to group multiple views together in the drop down by giving them the same view_label
label: Rename a field or explore in the field picker without changing how it’s referenced in LookML
description: Add a description to any field or explore. Will appear to users as they hover over the field in the field picker
value_format_name: Apply a format to a field using built in Looker format names (currency, percents, decimals)
value_format: Apply a custom format to a field using excel-style formats
group_label: Combine fields together in a common drop down within a view in the field picker
Check out our Explore Menu and Field Picker developer tutorial page for examples, screenshots, and additional ideas.
In this example we started from scratch with Looker’s sample e-commerce dataset “The Look” and decided to explore Order Items.
First, we ran Looker’s LookML generator to get the basic dimensions and measures.
The table names were all still showing as the database table names “dwh.tablename” which is informative as a database admin, but for a less technical user can be confusing, and frankly it doesn’t look very nice. Luckily user has the ability to re-label them with “view_label”.
Once that was cleaned up, we looked through the information presented in each drop down and thought about where we could clean-up the information by removing duplicates and hiding unnecessary dimensions.
An easy place to start is hiding primary keys and deciding which dates to include. With Looker’s “hidden: yes” function in LookML, you can retain the functionality of dimensions but hide the option from the Explore.
We also grouped users and users_order_facts together. Why? Because business users don’t need to know that you created a facts table, they just want to be able to find information about the users. We did some more consolidation with “group_labels” where there were natural groups across the user dimensions: Lifetime Value, Location, Personal Information.
Once you’ve done the initial clean-up it’s time to start testing out the data and making sure it will help business users ask and answer questions that help them do their job.
Looker is going to automatically bring in each column name from a table as a dimension along with a simple count, so there needs to be some leg work done before bringing in business users. Let’s use sales price as an example.
When sales price is first exposed in Looker, it is a dimension, so we added the value_format_name: usd and a description "The price of an individual order item, if you want the total or average sales price across a group, use the measures below".
Then you’ll need to create the new measures a business user might expect, like Total Sales Price and Average Sales Price
To create the “Total Sales Price” measure, it is actually a type:sum; so you could name it something like “Sum of Sales Price” or “Sales Price Summed.” The actual name is up to you, but we recommend however you start naming sums, continue. It will help users know what to expect.
You can also create brand new metrics that don’t already exist in the database like Gross Margin which uses fields from different tables in your model. Adding descriptions and the value_format_name: usd, business users will understand the calculation behind it.
In the end, the key to building a user friendly Explore is empathy. Always be thinking about your user and finding ways to make it as easy as possible for them to find the answers to their questions.
For more examples, check out these public datasets. Have fun!