LookML Basics Every Looker Explorer Candidate Should Know

You Don't Need to Write LookML to Pass the Explorer Exam — But You Need to Understand It

The Looker Certified Explorer is a consumer-level certification — it tests your ability to use Looker for analysis, not your ability to build data models. But the exam assumes you understand what LookML is, how it shapes what you see in an Explore, and why certain fields behave the way they do. If you walk into the exam without that conceptual foundation, you'll lose points on questions that seem straightforward but rely on LookML logic. These are the eight LookML concepts every Explorer candidate needs to know.

What Is LookML and Why Does It Matter for Explorers?

LookML (Looker Modeling Language) is the code that data developers write to define how Looker connects to your database, organizes data into views and Explores, and creates the dimensions and measures that analysts use for analysis. Every field you see in an Explore — every dimension, every measure, every filter — was defined by a LookML developer in the model layer.

As an Explorer, you work with the results of that LookML model. You don't write it. But understanding what dimensions versus measures are, how views relate to Explores, and why certain filter behaviors exist requires understanding the LookML layer — even at a conceptual level. The Google Cloud certification exam tests this understanding directly.

Concept 1: Views vs. Explores

A view is a LookML object that maps to a database table (or a derived table). It contains the field definitions — the dimensions and measures — for that table. An Explore is the interface users navigate to run queries. An Explore joins one or more views together and presents their combined fields for analysis.

When you open an Explore and see fields grouped under headings on the left panel, each group corresponds to a view. The Explore you chose determined which views are available and how they're joined. If a field you want isn't available in an Explore, it means either it wasn't included in that Explore's join, or it doesn't exist as a LookML field definition in the underlying view.

Concept 2: Dimensions vs. Measures

This is the most fundamental LookML concept and the one most directly tested on the Explorer exam. Dimensions are attributes — individual values that describe a row. Examples: product name, customer ID, transaction date, region. Dimensions don't aggregate; they describe. Measures are aggregations — calculations performed across rows. Examples: count of orders, sum of revenue, average order value, maximum discount.

In an Explore, dimensions appear as rows or group-by fields. Measures appear as the numerical values being aggregated. When you select a dimension and a measure in an Explore, Looker generates SQL that groups by the dimension and aggregates the measure. Understanding this distinction explains why you can pivot on a dimension but not a measure, and why table calculations behave differently depending on whether they reference dimensions or measures.

Concept 3: Dimension Groups and Date Dimensions

Date handling in Looker is different from most BI tools. A LookML dimension group of type time takes a single date/timestamp field and automatically generates multiple time granularities: date, week, month, quarter, year, hour, minute, and more. In an Explore, you'll see these as separate fields grouped under the parent field name.

For example, a field called "Order Date" might expand to "Order Date Date," "Order Date Week," "Order Date Month," and so on. When you filter on "Order Date Month," you're filtering at the month level — which affects the SQL granularity differently than filtering on "Order Date Date." This distinction appears on the exam in filter-behavior questions.

Concept 4: Filters in LookML vs. Filters in Explores

LookML developers can build filters directly into dimensions, measures, and Explores. An always_filter parameter forces a filter to be applied to every query in an Explore — users can change the filter value but can't remove the filter. A conditionally_filter requires that at least one of a set of specified filters be applied before a query can run. A sql_always_where adds a SQL WHERE clause that users can't see or modify.

When you're in an Explore and notice that a filter field is locked or a certain filter appears automatically, that behavior was written into the LookML model. Explorer candidates need to recognize these behaviors and understand why they exist — the exam tests this in scenarios where a user is frustrated that they can't remove a filter or change a filter's scope.

Concept 5: Derived Tables

A derived table is a LookML view that's built from a SQL query or a native Looker query rather than directly from a database table. Derived tables allow LookML developers to pre-aggregate data, create calculated columns, or combine tables in ways that the database schema doesn't provide natively.

As an Explorer, you may encounter derived tables without knowing it — they look exactly like regular views in the Explore field picker. But understanding that derived tables exist and that they may have different refresh behaviors (persistent derived tables versus volatile derived tables) helps explain why some data feels "stale" or why queries run faster on some Explores than others.

Concept 6: Parameters and Liquid Templating

LookML supports dynamic field values using Liquid templating — a syntax that allows field definitions to change based on user input. A LookML parameter creates a user-facing filter option that doesn't directly filter data but instead passes a value into a Liquid-templated dimension or measure.

You've seen this if you've ever used a Looker Explore with a filter labeled something like "Currency" or "Timeframe" where selecting an option changes the data being displayed rather than simply narrowing rows. The Explorer exam tests your ability to recognize that these filter types exist and that their behavior differs from standard field filters.

Concept 7: Model Files and Project Structure

A LookML project consists of model files, view files, and (optionally) manifest and explore files. The model file defines which Explores exist and how views are joined within them. Understanding that each Explore is defined in a model file explains why different Explores in the same Looker instance may have entirely different field availability, join logic, and filtering behavior.

Explorer candidates don't need to know LookML syntax, but they should understand that the Looker admin and LookML developers control what you can see and do. If an Explore is missing fields you expect, the answer is almost always "those fields aren't defined in the model for this Explore" — not "Looker can't do that."

Concept 8: Explores and Join Logic

An Explore can join multiple views together using SQL join logic — LEFT JOIN, FULL OUTER JOIN, and so on. The join type affects how rows are included in the result set, especially when there are NULLs or unmatched records. An Explorer seeing unexpected NULL values or inflated row counts often has a join issue at the LookML level.

The exam may present a scenario where a dashboard is showing unexpected results and ask you to identify the most likely cause. Understanding that join type (left vs. inner vs. full outer) can cause these artifacts — even if you didn't set up the join yourself — is the key to getting these questions right.

Translate LookML Knowledge into Exam Points

SimpuTech's Looker AI tutor practices every LookML concept from the Explorer perspective — with scenario questions about field behavior, filter logic, and dashboard troubleshooting that mirrors the actual exam format. Practice for free at SimpuTech →

Related reading: Looker Certified Explorer Exam: What to Expect and How to Use Looker Studio to Supplement Your Explorer Prep.

Certification details verified against cloud.google.com/learn/certification as of March 2026. Requirements are subject to change — confirm current details before registering.