Measures - Cube Documentation

While dimensions describe attributes of individual rows, measures compute values across rows — sums, counts, averages, and other aggregations. Measures can aggregate columns directly (like sum of revenue) or reference other measures to create compound metrics (like revenue / count).

See the measures reference for the full list of parameters and configuration options.

Defining measures

A measure specifies the SQL expression to aggregate and the aggregation type:

cubes:
  - name: orders
    sql_table: orders

    measures:
      - name: count
        type: count

      - name: total_amount
        sql: amount
        type: sum

      - name: average_amount
        sql: amount
        type: avg

cube(`orders`, {
  sql_table: `orders`,

  measures: {
    count: { type: `count` },
    total_amount: { sql: `amount`, type: `sum` },
    average_amount: { sql: `amount`, type: `avg` }
  }
})

Filtered measures

You can apply filters to a measure to create conditional aggregations. Only rows matching the filter are included:

cubes:
  - name: orders
    # ...

    measures:
      - name: count
        type: count

      - name: completed_count
        type: count
        filters:
          - sql: "{CUBE}.status = 'completed'"

cube(`orders`, {
  // ...

  measures: {
    count: { type: `count` },

    completed_count: {
      type: `count`,
      filters: [{ sql: `${CUBE}.status = 'completed'` }]
    }
  }
})

When completed_count is queried, Cube generates SQL with a CASE expression:

SELECT
  COUNT(CASE WHEN (orders.status = 'completed') THEN 1 END) AS completed_count
FROM orders

Calculated measures

Calculated measures perform calculations on other measures using SQL functions and operators. They provide a way to decompose complex metrics (e.g., ratios or percents) into formulas involving simpler measures.

Referencing measures in the same cube

cubes:
  - name: orders
    # ...

    measures:
      - name: count
        type: count

      - name: completed_count
        type: count
        filters:
          - sql: "{CUBE}.status = 'completed'"

      - name: completed_ratio
        sql: "1.0 * {completed_count} / NULLIF({count}, 0)"
        type: number

cube(`orders`, {
  // ...

  measures: {
    count: { type: `count` },

    completed_count: {
      type: `count`,
      filters: [{ sql: `${CUBE}.status = 'completed'` }]
    },

    completed_ratio: {
      sql: `1.0 * ${completed_count} / NULLIF(${count}, 0)`,
      type: `number`
    }
  }
})

Referencing measures from other cubes

If cubes are joined, you can reference measures across cubes. Cube generates the necessary joins automatically:

cubes:
  - name: users
    # ...

    joins:
      - name: orders
        sql: "{CUBE}.id = {orders}.user_id"
        relationship: one_to_many

    measures:
      - name: count
        type: count

      - name: purchases_to_users_ratio
        sql: "1.0 * {orders.purchases} / NULLIF({CUBE.count}, 0)"
        type: number

cube(`users`, {
  // ...

  joins: {
    orders: {
      sql: `${CUBE}.id = ${orders}.user_id`,
      relationship: `one_to_many`
    }
  },

  measures: {
    count: { type: `count` },

    purchases_to_users_ratio: {
      sql: `1.0 * ${orders.purchases} / NULLIF(${CUBE.count}, 0)`,
      type: `number`
    }
  }
})

Multi-stage measures

Multi-stage measures are calculated in two or more stages, enabling calculations on already-aggregated data. Each stage results in one or more CTEs in the generated SQL query.

Multi-stage measures are powered by Tesseract, the next-generation data modeling engine. In versions before v1.7.0, it was not enabled by default.

Rolling windows

Rolling window measures calculate metrics over a moving window of time, such as cumulative counts or moving averages. Use the rolling_window parameter:

measures:
  - name: cumulative_count
    type: count
    rolling_window:
      trailing: unbounded

  - name: trailing_month_count
    sql: id
    type: count
    rolling_window:
      trailing: 1 month

Period-to-date

Period-to-date measures analyze data from the start of a period to the current date — year-to-date (YTD), quarter-to-date (QTD), or month-to-date (MTD):

measures:
  - name: revenue_ytd
    sql: revenue
    type: sum
    rolling_window:
      type: to_date
      granularity: year

  - name: revenue_qtd
    sql: revenue
    type: sum
    rolling_window:
      type: to_date
      granularity: quarter

Time shift

Time-shift measures calculate the value of another measure at a different point in time, typically for period-over-period comparisons like year-over-year growth. Use the time_shift parameter:

measures:
  - name: revenue
    sql: revenue
    type: sum

  - name: revenue_prior_year
    multi_stage: true
    sql: "{revenue}"
    type: number
    time_shift:
      - interval: 1 year
        type: prior

You can combine time shift with period-to-date for comparisons like “this year’s YTD vs. last year’s YTD”:

measures:
  - name: revenue_ytd
    sql: revenue
    type: sum
    rolling_window:
      type: to_date
      granularity: year

  - name: revenue_prior_year_ytd
    multi_stage: true
    sql: "{revenue_ytd}"
    type: number
    time_shift:
      - time_dimension: time
        interval: 1 year
        type: prior

Time-shift measures can also be used with calendar cubes to customize how time-shifting works, e.g., to shift by retail calendar periods.

Percent of total (fixed dimension)

Use the grain parameter with keep_only to fix the inner aggregation to specific dimensions, enabling percent-of-total calculations:

measures:
  - name: revenue
    sql: revenue
    type: sum

  - name: country_revenue
    multi_stage: true
    sql: "{revenue}"
    type: sum
    grain:
      keep_only:
        - country

  - name: country_revenue_percentage
    multi_stage: true
    sql: "{revenue} / NULLIF({country_revenue}, 0)"
    type: number

Use the filter parameter to override the filters that a multi-stage measure inherits from the query. This enables “share of total” calculations where the denominator must ignore a filter applied by the query. In the example below, amount_all_statuses uses exclude to drop the status filter, so it always aggregates across all statuses. When the query is filtered to a single status, total_amount reflects that status while amount_all_statuses stays the full per-category total, and percent_of_total is the share that the filtered status represents:

measures:
  - name: total_amount
    sql: amount
    type: sum

  - name: amount_all_statuses
    multi_stage: true
    sql: "{total_amount}"
    type: number
    filter:
      exclude:
        - status

  - name: percent_of_total
    multi_stage: true
    sql: "100.0 * {total_amount} / NULLIF({amount_all_statuses}, 0)"
    type: number
    format: percent

Nested aggregates

Use the grain parameter with include to compute an aggregate of an aggregate, e.g., the average of per-customer averages:

measures:
  - name: avg_order_value
    sql: amount
    type: avg

  - name: avg_customer_order_value
    multi_stage: true
    sql: "{avg_order_value}"
    type: avg
    grain:
      include:
        - customer_id

When a nested aggregate combines two or more other multi-stage measures that share the same grain, set grain on the combining measure — not on each of its inputs. For example, to average a per-day ratio, group the per-day components by day through the combining measure:

measures:
  - name: total_amount
    sql: amount
    type: sum

  - name: total_count
    sql: id
    type: count

  # Intermediate multi-stage measures — the grain is set on the combining
  # measure below, so these inherit it and are joined on the shared grain.
  - name: daily_amount
    multi_stage: true
    sql: "{total_amount}"
    type: number

  - name: daily_count
    multi_stage: true
    sql: "{total_count}"
    type: number

  - name: avg_daily_order_value
    multi_stage: true
    sql: "1.0 * {daily_amount} / NULLIF({daily_count}, 0)"
    type: avg
    grain:
      include:
        - created_at

grain fixes the inner grain of the measure it’s declared on and does not expose the added dimension to a measure built on top of it. If each input measure declares the same grain.include (rather than the combining measure), the inputs no longer carry a shared grouping key, so they are combined with a cross join instead of being joined on that key — producing incorrect results. Declare grain on the combining measure so its inputs are joined on the shared grain.

Ranking

Use the grain parameter with exclude to rank items within groups:

measures:
  - name: revenue
    sql: revenue
    type: sum

  - name: product_rank
    multi_stage: true
    order_by:
      - sql: "{revenue}"
        dir: asc
    grain:
      exclude:
        - product
    type: rank

grain replaces the standalone group_by, reduce_by, and add_group_by parameters, which remain supported. See the grain reference for the migration mapping.

Conditional measures

Conditional measures depend on the value of a dimension, using the case parameter with switch dimensions:

measures:
  - name: amount_in_currency
    multi_stage: true
    case:
      switch: "{CUBE.currency}"
      when:
        - value: EUR
          sql: "{CUBE.amount_eur}"
        - value: GBP
          sql: "{CUBE.amount_gbp}"
      else:
        sql: "{CUBE.amount_usd}"
    type: number

Formatting

Use the format parameter to control how measures are displayed:

measures:
  - name: total_revenue
    sql: revenue
    type: sum
    format: currency

  - name: conversion_rate
    sql: "1.0 * {completed_count} / NULLIF({count}, 0)"
    type: number
    format: percent

Next steps

See the measures reference for all parameters
Learn about dimensions for grouping and filtering
Explore pre-aggregations to accelerate measure queries
See the period-over-period recipe for advanced time comparisons

​Defining measures

​Filtered measures

​Calculated measures

​Referencing measures in the same cube

​Referencing measures from other cubes

​Multi-stage measures

​Rolling windows

​Period-to-date

​Time shift

​Percent of total (fixed dimension)

​Share of total (filter override)

​Nested aggregates

​Ranking

​Conditional measures

​Formatting

​Next steps

Defining measures

Filtered measures

Calculated measures

Referencing measures in the same cube

Referencing measures from other cubes

Multi-stage measures

Rolling windows

Period-to-date

Time shift

Percent of total (fixed dimension)

Share of total (filter override)

Nested aggregates

Ranking

Conditional measures

Formatting

Next steps