LookML Dimensions vs. Measures: What You Must Understand

The most frequently confused concept on the Looker Certified Explorer exam is the relationship between dimensions and measures in LookML. Both are fields. Both appear in the Explore field picker. But they work completely differently, they appear in different sections of the field picker, and choosing the wrong one produces incorrect or misleading results.

What Is the Actual Difference Between a Dimension and a Measure?

A dimension is a field you use to describe, group, or filter data. It represents a property of a single row — an order's status, a user's country, a product's category. When you add a dimension to an Explore query, you are asking Looker to group results by that value.

A measure is a field that aggregates data across rows — a count, a sum, an average. It answers the question "how many?" or "how much?" for a group. Measures do not make sense at the individual row level; they only have meaning when applied to a set of rows defined by the dimensions you have selected.

LookML Examples: Three Dimension Types and Two Measure Types

view: orders {
  sql_table_name: "ecommerce"."orders" ;;

  # --- DIMENSIONS ---

  # type: string — a text field, no aggregation
  dimension: status {
    type: string
    sql: ${TABLE}.order_status ;;
    label: "Order Status"
  }

  # type: number — a numeric value at the row level (not a sum or average)
  dimension: days_to_ship {
    type: number
    sql: DATEDIFF(${TABLE}.shipped_at, ${TABLE}.created_at) ;;
    label: "Days to Ship"
  }

  # type: yesno — creates a true/false dimension from a SQL condition
  dimension: is_returned {
    type: yesno
    sql: ${TABLE}.returned_at IS NOT NULL ;;
    label: "Returned?"
  }

  # --- MEASURES ---

  # type: count — counts rows (with optional filter)
  measure: order_count {
    type: count
    label: "Number of Orders"
    drill_fields: [order_id, status, total_revenue]
  }

  # type: sum — sums a numeric column across rows
  measure: total_revenue {
    type: sum
    sql: ${TABLE}.revenue ;;
    label: "Total Revenue"
    value_format_name: usd
  }
}

What the Exam Actually Tests About Dimensions and Measures

The exam does not ask you to write LookML from scratch, but it does present code snippets and asks what a field does or what type it should be given a scenario. Common question patterns include: "A developer needs to count only orders where the status is 'complete'. What LookML field type and approach is correct?" (Answer: a measure of type: count with a filter parameter, not a dimension of type: yesno). Or: "Which of the following would appear in the GROUP BY clause of the SQL Looker generates?" (Answer: dimensions, not measures).

Another tested concept is the difference between type: number as a dimension and type: sum as a measure. A type: number dimension holds a numeric value at the row level — it does not aggregate. A type: sum measure aggregates a numeric column across all rows returned by the query. If you define revenue as a type: number dimension, you will see a revenue value per row, but you will not get a total revenue figure without also creating a type: sum measure.

The Measure Filter Pattern

One of the most tested LookML patterns on the exam is the filtered measure — a measure that only counts or sums rows meeting a specific condition. In LookML, this is done with the filters parameter inside a measure definition:

  measure: completed_order_count {
    type: count
    filters: [status: "complete"]
    label: "Completed Orders"
  }

This generates SQL with a CASE WHEN inside the COUNT, counting only rows where status = 'complete'. It is cleaner and more reusable than writing a CASE WHEN inside the sql parameter, and it is the pattern Looker's documentation and best practices recommend.

For more LookML field concepts, see the LookML basics introduction and the LookML type system guide. The Looker Cert Prep PDF guide includes a complete dimension and measure reference with exam-specific tips for every field type.