How to Create an Explore in Looker

Building a powerful report in Looker starts with something called an "Explore." It’s the foundational, curated window into your data that allows your team to freely and accurately ask business questions. This guide will walk you through exactly how to create a Looker Explore, from the basic setup to the essential customizations that make for a great user experience.

What is a Looker Explore?

Think of an Explore as a starting point for a query. When you log into Looker and click the "Explore" button in the navigation, you're presented with a list of these pre-configured datasets. Each one is designed around a central business concept, like "Orders," "Users," or "Website Traffic."

Technically, an Explore is defined in Looker’s modeling language, LookML. It tells Looker which database tables (called "Views" in LookML) to show to users, how those tables are connected (using "Joins"), and which specific columns (called "Dimensions" and "Measures") are available to use in reports. By creating an Explore, you are essentially building a safe, user-friendly environment for your team to build reports without needing to write a single line of SQL.

The Building Blocks: What You Need First

You can't create an Explore in a vacuum. It relies on a few other components that must be in place within your LookML project. Before you write your first line of explore code, make sure you have the following ready:

• A LookML Project: This is the repository of files that contains all your data models.
• A Model File: Your project will have at least one .model file. This file specifies a database connection and is where you will define your Explores.
• At Least One View File: A view (in a .view file) is a representation of a database table or a derived table. An Explore must be based on at least one view. For example, to create an orders Explore, you first need an orders view that defines the dimensions and measures for your orders table.

With these elements in place, you’re ready to bring them together into a functioning Explore.

Step-by-Step Guide: Creating a Basic Explore

For this walkthrough, let's assume you have a view file named orders.view.lkml that models your company's orders data. Now, let’s make it available for users to analyze.

1. Navigate to Your Model File

In the Looker IDE, find your main model file (e.g., your_project_name.model.lkml). This file orchestrates the different pieces of your data model and is the correct place to define your Explores.

2. Use the explore Parameter

Inside your model file, you will add a new block of code using the explore parameter. The simplest possible definition just names the view you want to expose. It looks like this:

# In your_project_name.model.lkml

connection: "your_database_connection"
include: "/views/*.view.lkml"

explore: orders {
  # We will add customizations here later
}

That's it! In this example:

• explore: orders tells Looker that we are creating a new Explore named "orders". By default, Looker assumes this Explore is built upon a view with the same name (the orders view).
• The curly braces {} are where we will add more configurations, such as joins and labels. For now, leaving it empty is perfectly valid.

Once you’ve saved this change (and assuming your LookML is valid), you can navigate to the Explore section of the Looker UI, and you will now see "Orders" as an option. Clicking it will take you to the Explore interface, showing all the dimensions and measures defined in your orders.view.lkml file, ready for analysis.

Powering Up: Enhancing Explores with Joins

Analyzing a single table is rarely enough. To answer meaningful questions like "Which registration source leads to the highest lifetime value?" you need to connect your orders data with your users data. In Looker, you achieve this using the join parameter inside your Explore definition.

Let's extend our orders Explore by joining it to a users view.

Defining the Join Relationship

The goal is to link the orders table to the users table on their common field, which is likely a user ID. Here's how you’d add that join to your model file:

# In your_project_name.model.lkml

connection: "your_database_connection"
include: "/views/*.view.lkml"

explore: orders {
  join: users {
    type: left_outer         # Defines the SQL join type
    relationship: many_to_one # Tells Looker the kind of join
    sql_on: ${orders.user_id} = ${users.id} ,,
  }
}

Breaking Down the join Parameters

This code block might look complex, but each parameter has a clear purpose:

• join: users { ... }: This introduces a new join to the users view. Fields from the users view will now be available in the "Orders" Explore.
• type: left_outer: This specifies the type of SQL join. It ensures that all records from the base table (orders) are kept, even if there isn't a matching user. Other common types include inner, full_outer, and cross. Best practice is to almost always use left_outer.
• relationship: many_to_one: This is a crucial parameter for Looker's symmetric aggregates feature. It informs Looker of the relationship between the tables. Here, we're saying that many orders can belong to one user. Accurately defining this helps avoid calculation errors (fancounting) when you aggregate data across joined tables. Other options include one_to_one, one_to_many, and many_to_many.
• sql_on: ${orders.user_id} = ${users.id} ,,: This defines the join condition itself - the SQL ON clause. It specifies that the user_id field from the orders view should be matched against the id field from the users view. The ${view_name.field_name} syntax is how you reference LookML fields.

With this join in place, business users can now go to the "Orders" Explore and build reports that combine fields from both tables, like grouping Total Sales (from orders) by Acquisition Source (from users).

Customizing the User Experience for Clarity

A functional Explore is one thing, but a great Explore is one that is intuitive and easy for your team to use. LookML provides several parameters to polish how your Explore appears in the user interface.

label: Creating User-Friendly Names

Your database tables might be named with prefixes or abbreviations (e.g., dim_users, fct_orders). The label parameter lets you assign a cleaner, more readable name for the UI.

explore: orders {
  label: "All Company Orders"
  
  join: users {
    label: "Customer Information" # Applies only to the join group, not a full Explore
    ...
  }
}

description: Adding Helpful Context

Use the description parameter to add helpful tooltips. When a user hovers over the Explore name or a field name in the UI, this text will appear, guiding them on what the data represents.

explore: orders {
  label: "All Company Orders"
  description: "Use this Explore to analyze order history, revenue, and product performance. Data is refreshed daily at 6 AM."

}

group_label: Organizing Fields for Navigation

When you have many joins, the field picker on the left side of the Explore page can become cluttered. The group_label parameter lets you bundle fields from different joined views under a single, collapsible heading.

explore: orders {
  label: "All Company Orders"

  join: users {
    group_label: "Customer Demographics"
    ...
    // All fields from the users view will now appear under this label
  }

  join: products {
    group_label: "Product Details"
    ...
    // All fields from the products view will now appear here
  }
}

Testing and Validating Your Explore

After making changes to your LookML, two steps are critical:

1. Validate Your LookML: Looker has a built-in content validator tool. Use it to check for syntax errors or invalid references. It will catch typos and logic errors before you push your code to production.
2. Test in the UI: Navigate to your new Explore and run a few sanity-check queries. Select some dimensions and measures from your base view and each joined view. Do the numbers look correct? Are the joins behaving as you expect? Spending two minutes testing can save hours of confusion for your users down the line.

Final Thoughts

Creating an Explore in Looker transforms your raw database tables into a powerful, interactive analytics tool for your entire team. By carefully defining your base views, establishing clear join logic, and adding user-friendly labels and descriptions, you can build an intuitive and reliable environment for self-service reporting.

While Looker offers incredible power, the technical setup and LookML learning curve can be steep for marketing and sales teams who just want a clear view of their performance. At Graphed, we handle all that complexity for you. We built a platform that lets you connect your data sources - like Google Analytics, Salesforce, and Shopify - and then use simple natural language to create the exact dashboards you need. Instead of learning code, you just ask, “Show me my campaign ROI by channel for last month,” and get a live, interactive dashboard in seconds.