These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers, from implementation to long-term success. The practices are written to work for most users and situations, but as always use best judgment when implementing.
Provide Users with Meaningful Field Names
- Use the label parameter to apply friendly names to dimensions or measures for end users, while maintaining database-friendly names within the View and Model files. A couple of common terms to consider renaming, would be changing “Count” 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 This||Instead of This|
- Avoid exposing multiple fields with the same name. For example: count measures are automatically created within Looker with the name "count." This results in most view files containing a count measure with the same name. Multiple fields with the same name can be confusing for users. Adding labels or renaming count measures, to indicate the object that is being counted, will prevent confusion. Other ones to keep in mind include created dates and updated dates.
- Provide clear names for yesno fields. For example: use “Is the Item Returned” instead of “Returned” for naming a field, that indicates whether or not an items has been returned.
- Name ratios descriptively. For example: “Orders Per Purchasing Customers” is clearer than “Orders Percent.”
- Name fields consistently and represent values consistently across the model. Use value_format or value_format_name for things like currency symbols, percentages, and decimal precision, to help make everything readable.
Group Similar Fields Together for Easier Navigation
- Use the group_label parameter to consolidate dimensions and measures from individual or multiple joined Views that are related. For example: grouping all geographic information into a “Geography” group will pull all address and location information together within the field picker, rather than having it all listed alphabetically.
- Break up large, denormalized tables, using the view_label parameter. Utilize the view_label parameter within fields, to logically group fields together into separate headings within the field picker. Large, denormalized tables with a lot of fields can be difficult to navigate, so this gives the illusion of multiple views to users.
Less is More
- Avoid exposing too much to users upon an initial Looker roll-out. Start small, and then expand the options. You don’t have to expose all the tables or dimensions and measures at once. You can expose fields that are most important, and then continue to build more functionality as business users become more confident with data exploration.
- Hide dimensions that are not relevant to users from the user interface. Use the hidden: parameter, on dimensions that will never be used through the user interface, (such as ID fields or database update dates).
- Utilize the fields parameter within Explores and joins, to limit the number of fields available to users. Included fields should be only those relevant to the Explore. This reduces bloat and provides a better experience for end users. Unlike the hidden parameter, this enables fields to be included or excluded on an Explore-by-Explore basis.
- Hide any Explores that exist solely for populating specific Looks, dashboard tiles, or filters using the hidden parameter. Explores that are not meant for exploration by end users, should be hidden from the user interface.
- Use the fewest number of Explores possible, while still allowing users to easily get access to the answers they need. Consider splitting out Explores into different models for different audiences, to limit the options available for each user group. The optimal number of Explores is different for every business, but having too many Explores tends to be confusing for end users. Consider using the group_label parameter for Explores within a model, in order to group them in a sensible way within the Explore dropdown menu.
Add Descriptions so Users Know Which Fields and Explores to Use
- Use the description parameter on dimensions and measures, to provide additional information to end users about the logic or calculations utilized within the model. This is particularly important for dimensions and measures that leverage complex logic or calculations. However, descriptions should also be considered for ensuring users understand the definitions behind simpler fields.
Explore descriptions should be defined for users. Add a short description to each Explore, to specify the purpose and audience using the description parameter.
Build Common Workflows into Looker
- Add drill_fields to all relevant measures. Drill fields enable users to click into aggregate values, in order to access detailed data. Utilize the set parameter, to create reusable sets of fields that can then be applied to any number of measures within a view.
- Add drill_fields to all hierarchical dimensions. For example: adding a drill_field for city into a state dimension will enable users to select a state and then drill deeper into the cities within that state. Note that this hierarchical drilling will automatically be applied within time dimension groups.
- Set up links that enable users to easily navigate and pass filters to other Looker dashboards, or to systems or platforms external to Looker. See our Documentation for examples of passing filters through drills.