When a model reads a measure from its source, how you write it decides what readers of the model get. A pass-through gives them the same measure. An EVAL gives them a value fixed at your model’s grouping. A MEASURE declaration gives them a new measure that you own. A tick in the field list writes a pass-through.

The three choices

These lines come from the Region Mix query:

1
SELECT
2
  shop.region_group,
3
  shop.sum__amount,
4
  MEASURE(
5
    'revenue_per_customer',
6
    EVAL(shop.sum__amount) / NULLIF(EVAL(shop.count_distinct__customer_id), 0)
7
  ) AS "Revenue per Customer"
8
FROM workspace.shop AS shop

An AS alias changes the label only. shop.sum__amount AS "Sales" is still the pass-through of Revenue, with the name sum__amount.

What readers get

These examples save two queries of the sample shop, then read each of them from a third query. A query reads another query of its workspace as FROM query.<name>.

Pass the measures through

The query orders_by_region passes Orders and Customers through, grouped by region:

1
SELECT
2
  shop.region_group,
3
  shop.region,
4
  shop.count_distinct__order_id,
5
  shop.count_distinct__customer_id
6
FROM workspace.shop AS shop
7
GROUP BY
8
  shop.region_group,
9
  shop.region
10
ORDER BY
11
  shop.region_group,
12
  shop.region

A reader with no grouping:

1
SELECT
2
  q.count_distinct__order_id,
3
  q.count_distinct__customer_id
4
FROM query.orders_by_region AS q

A reader grouped by region group:

1
SELECT
2
  q.region_group,
3
  q.count_distinct__order_id,
4
  q.count_distinct__customer_id
5
FROM query.orders_by_region AS q
6
GROUP BY
7
  q.region_group
8
ORDER BY
9
  q.region_group

Each reader counts again from the order rows. Rest of World has 240 customers, not 229 + 228 + 56, because Kater counts each customer once.

Evaluate the measures

The query orders_by_region_fixed is the same query with EVAL around each measure:

1
SELECT
2
  shop.region_group,
3
  shop.region,
4
  EVAL(shop.count_distinct__order_id),
5
  EVAL(shop.count_distinct__customer_id)
6
FROM workspace.shop AS shop
7
GROUP BY
8
  shop.region_group,
9
  shop.region
10
ORDER BY
11
  shop.region_group,
12
  shop.region

Its own rows are the same as those of orders_by_region. But a reader now gets two dimensions, fixed at the region. A reader with no grouping gets the five fixed values:

1
SELECT
2
  q.region,
3
  q.count_distinct__order_id,
4
  q.count_distinct__customer_id
5
FROM query.orders_by_region_fixed AS q

To get one total, the reader has to add the fixed values up:

1
SELECT
2
  MEASURE('orders_added_up', KATER__SUM(q.count_distinct__order_id)) AS "Orders Added Up",
3
  MEASURE('customers_added_up', KATER__SUM(q.count_distinct__customer_id)) AS "Customers Added Up"
4
FROM query.orders_by_region_fixed AS q

Orders adds up to the right number by chance, because each order has one region. Customers adds up to 976, because a customer who ordered in four regions counts four times. The pass-through gave 240. Evaluate a measure only when its value at your grouping is the number readers need.

Declare a new measure

A MEASURE declaration over EVALs is a measure of its own. Readers work it out again at their grouping. See Measures built from measures for Revenue per Customer, which a reader grouped by currency works out again as $1,544.44.

When Kater writes EVAL for you

Kater writes EVAL around a measure where a pass-through cannot stand, and when you lock a measure in:

• In HAVING, QUALIFY or ORDER BY. A condition or a sort reads the measure’s value at the model’s grouping.
• Inside an expression. EVAL(shop.sum__quantity) / 1000 works the measure out at the model’s grouping, then divides. The result is a new value: an unnamed dimension until you declare it.
• In a SELECT that has HAVING or QUALIFY. These clauses decide which rows count from other rows. So the SELECT cannot pass a measure through, and it evaluates each measure instead.
• When you lock a measure in. In a query, Edit › Lock in on a measure turns its pass-through into EVAL.

Filter by this number

On a measure’s column in a query, Filters opens with Is In The Top and Is In The Bottom. The number conditions follow, such as Is Greater Than. This query shows Orders and Units by region:

1
SELECT
2
  shop.region,
3
  shop.count_distinct__order_id,
4
  shop.sum__quantity
5
FROM workspace.shop AS shop
6
GROUP BY
7
  shop.region

Filters › Is Greater Than on Orders, with 700, writes the condition in HAVING. In the same edit, it evaluates every measure the SELECT passes through, and keeps their names and labels:

1
SELECT
2
  shop.region,
3
  EVAL(shop.count_distinct__order_id),
4
  EVAL(shop.sum__quantity)
5
FROM workspace.shop AS shop
6
GROUP BY
7
  shop.region
8
HAVING
9
  KATER__IS_GREATER_THAN(EVAL(shop.count_distinct__order_id), 700)

APAC, with 671 orders, and the 64 orders with no region drop out. A filter on a measure applies to its own query only.

Top N

Filters › Is In The Top writes a rank condition in QUALIFY. The Top Regions query keeps the 5 region and currency rows with the most revenue:

1
SELECT
2
  shop.region,
3
  shop.currency,
4
  EVAL(shop.sum__amount),
5
  EVAL(shop.count_distinct__order_id)
6
FROM workspace.shop AS shop
7
GROUP BY
8
  shop.region,
9
  shop.currency
10
QUALIFY
11
  KATER__IS_IN_TOP(EVAL(shop.sum__amount), 5)
12
ORDER BY
13
  3 DESC

This ranks euros against dollars. To rank within each currency, partition the condition. OVER (PARTITION BY shop.currency) keeps the top region of each currency:

1
SELECT
2
  shop.region,
3
  shop.currency,
4
  EVAL(shop.sum__amount),
5
  EVAL(shop.count_distinct__order_id)
6
FROM workspace.shop AS shop
7
GROUP BY
8
  shop.region,
9
  shop.currency
10
QUALIFY
11
  KATER__IS_IN_TOP(EVAL(shop.sum__amount), 1) OVER (PARTITION BY shop.currency)
12
ORDER BY
13
  shop.currency

A partition keeps a measure that cannot be added up across currencies from being ranked across them.

Top N and Bottom N keep ties, so they can keep more rows than the count. From June to September 2026, July and September both had 137 orders. The bottom 2 months are three months:

1
SELECT
2
  shop.order_month,
3
  EVAL(shop.count_distinct__order_id)
4
FROM workspace.shop AS shop
5
WHERE
6
  shop.order_month >= DATE '2026-06-01'
7
GROUP BY
8
  shop.order_month
9
QUALIFY
10
  KATER__IS_IN_BOTTOM(EVAL(shop.count_distinct__order_id), 2)
11
ORDER BY
12
  EVAL(shop.count_distinct__order_id) ASC NULLS LAST

A query with no ORDER BY gets one from Top N or Bottom N, so its rows come out in rank order. A query that already sorts keeps its own sort.

A measure the model declares itself

HAVING, QUALIFY and ORDER BY can also read a measure that the same SELECT declares. They apply to the model’s results, so they read the measure at the model’s grouping:

1
SELECT
2
  shop.region,
3
  MEASURE('large_orders', KATER__COUNT_DISTINCT(CASE WHEN shop.order_size = 'large' THEN shop.order_id END)) AS "Large Orders"
4
FROM workspace.shop AS shop
5
GROUP BY
6
  shop.region
7
HAVING
8
  EVAL(large_orders) > 340

Anything else in the same condition must be one of the model’s outputs.

What a reader never sees

A model’s GROUP BY, ORDER BY, LIMIT, OFFSET and DISTINCT shape only its own run. The query top_two_regions keeps the two regions with the most orders:

1
SELECT
2
  shop.region,
3
  shop.count_distinct__order_id
4
FROM workspace.shop AS shop
5
GROUP BY
6
  shop.region
7
ORDER BY
8
  2 DESC
9
LIMIT 2

A reader of it with no grouping:

1
SELECT
2
  q.count_distinct__order_id
3
FROM query.top_two_regions AS q

The reader gets 3,000, not 777 + 760. A passed-through measure is totalled again from the source rows, so the LIMIT does not reach it. To hand readers only the top rows, use Top N. It evaluates the measure, so a reader of the Top Regions query gets its 5 rows and their fixed values.

Renaming a measure

A measure that is passed through keeps its name. * RENAME cannot give it a new one:

1
SELECT
2
  * RENAME (count_distinct__order_id AS orders)
3
FROM workspace.shop AS shop

The compiler refuses it: “RENAME can’t give the measure count_distinct__order_id a new name, because a measure passed through keeps its name.” Declare the new name with MEASURE instead. This query is saved as orders_renamed:

1
SELECT
2
  shop.region,
3
  MEASURE('orders', EVAL(shop.count_distinct__order_id)) AS "Orders"
4
FROM workspace.shop AS shop
5
GROUP BY
6
  shop.region
7
ORDER BY
8
  shop.region

A reader of it with no grouping:

1
SELECT
2
  q.orders
3
FROM query.orders_renamed AS q

orders is a new measure, so readers still work it out again from the order rows. To change only what people see, change the label: shop.count_distinct__order_id AS "Order Count" keeps the name and the pass-through.

Rules

• A pass-through is the default. A tick in the field list, a bare name and * all pass the measure through. Readers can then group it any way.
• EVAL fixes the value. Readers of an EVAL output get a dimension at your grouping. Adding it up again can give a wrong number.
• A new measure needs a new name. MEASURE('count_distinct__order_id', EVAL(shop.count_distinct__order_id)) takes a name that is already in scope, so the compiler refuses it.
• HAVING and QUALIFY show the value at your grouping. A measure beside either shows its value at this grouping, as EVAL does, and readers can’t add it up again. The compiler warns you to write EVAL, so the SQL says so.
• A reader never sees your row shape. Your GROUP BY, ORDER BY, LIMIT, OFFSET and DISTINCT shape only your own run.
• Rules carry through. A pass-through, and a measure built on another, keep its rules, such as one currency per row. See Measures you cannot add up.

Common errors