This content, written by Arielle Strong & Katherine Gillespie, was initially posted in Looker Blog on Mar 14, 2017. The content is subject to limited support.
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.
Start with your user
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:
Some guiding questions
- Who will be using the data?
- How will they be using it?
- How can you make their job easier?
- Where would you logically look for something?
- Do you see natural groups in the dimensions and measures?
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.
- Rename data jargon into business user terminology. A couple of common terms to consider renaming would be changing “Counts” to “Number of” and “Sum” to “Total”. If you aren’t sure which words are jargon, work with a business user to build out some common reports and see what words they use to describe what they are looking for.
- Try to not have too many duplicates. For example, in a database there are often many “created dates”, as an analyst it might be clear which date you would use, but as a business user it would be helpful to have either more context or only one option.
- Create conventions and consistency in the way you expose data. Use value formats such as currency symbols, percentages, and decimal precision to help make everything human readable.
- Add explicit descriptions. If you build a dimension or measure, add a description about how it is calculated, where the source is from and/or give advice about how to use it. By anticipating the questions a business user may have and then writing a description, you will save everyone time.
- Start small, and then expand the options. You don’t have to expose all of the tables or dimensions and measures all at once. You can expose which ones are most important and then continue to build more functionality as business users become more confident with data exploration.
Ok, but how do I do this?
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.
Quick list of LookML tools
: Hides a field from the field picker but the field is still accessible to use behind the scenes in calculations / joins
: 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
: Rename a field or explore in the field picker without changing how it’s referenced in LookML
: Add a description to any field or explore. Will appear to users as they hover over the field in the field picker
: Apply a format to a field using built in Looker format names (currency, percents, decimals)
: Apply a custom format to a field using excel-style formats
: Combine fields together in a common drop down within a view in the field picker
Check out our 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.
Clarifying the difference between dimensions and measures
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 . Have fun!