Measures

What Measures Do in a Data Model

Measures are not stored as static values, they are calculations that are recomputed in the context of the current query. That makes them ideal for ratios, totals, averages and other results that need to respond to slicers, row context and report filters rather than remain fixed in the underlying table.

A measure is therefore best understood as a layer of analytical logic, not a data entry field. It sits between the raw model and the visual, turning model relationships and filter context into a result the report can display.

Measures vs Calculated Columns

The key difference is when the value is resolved. A calculated column is materialised with the data, so each row keeps the same value until the model is refreshed. A measure is evaluated at query time, so two visuals can show different answers from the same measure if their filters differ.

That distinction matters because measures are usually better for aggregations that depend on the user’s current view, while calculated columns are better when a value must be attached to each row for sorting, segmentation or relationship logic. Choosing the wrong one can make a model larger, slower or harder to reason about.

Filter Context and Evaluation Logic

Measures depend on filter context, which is the set of filters coming from report visuals, slicers, page filters and model relationships. A measure often returns different results not because the definition changed, but because the context around it changed.

This context-sensitive behaviour is what gives measures their power. The same definition can produce a grand total, a per-category subtotal or a time-based comparison without rewriting the calculation for each visual. In practice, that is why measures are the main building block for interactive analytics.

Why Measures Matter in Reporting

Measures make reports dynamic, but that flexibility also makes them easy to misuse. A formula that works in one visual may appear to be wrong in another if the author has not accounted for context transition, blank handling or division by zero. For a practitioner, the real challenge is not writing a formula, but making sure it behaves predictably across the model.

When measures are designed well, they keep analytical logic centralised and reusable. When they are designed poorly, they can hide complexity inside a report and produce numbers that look authoritative but are sensitive to the viewer’s selection state.

Related resources from NHI Mgmt Group

• What distinct security measures should be implemented for AI agents?
• Why do autonomous agents break traditional IAM confidence measures?
• What breaks when voice agent evaluation only measures transcript quality?
• When should organisations prioritise client-side code protection over simpler hardening measures?