In Tableau, what is the difference between a dimension and a measure?
answer
- one field role slices, the other rolls up
- think granularity versus aggregation
- Tableau guesses the role from data type alone
- numeric IDs arrive on the wrong side
- the role is separate from the pill colour
basics
~20 sIn Tableau, dimensions are categorical fields that slice a view and set its granularity; measures are numeric fields that get aggregated inside each slice, SUM by default. Any field can be converted between the two roles.
solid answer
~50 sTableau classifies every field in the Data pane as a **dimension** or a **measure**. A dimension slices the view: each distinct value of the dimensions you place in the view produces its own row, column or mark, so dimensions define the view's granularity. A measure is a numeric value that Tableau aggregates within whatever granularity the dimensions created — drop `Sales` on Rows and you get `SUM(Sales)`, not raw values. Tableau guesses the role when you connect, based on data type: numeric columns land in measures, text, date and boolean columns in dimensions. That guess is only a default. Numeric keys such as an order ID or a year stored as a number arrive as measures and must be converted to dimensions, otherwise you silently sum identifiers. The role is separate from the discrete/continuous (blue/green) distinction, even though dimensions default to discrete and measures to continuous.
code
text · 7 lines-- Order ID left as a MEASURE (Tableau's default for a numeric column)
Rows: (empty)
Text: SUM(Order ID) -> 1 mark: 4,812,993,110 (meaningless)
-- Order ID converted to a DIMENSION
Rows: Order ID
Text: SUM(Sales) -> 1 mark per order, each summing that order's rowsgo deeper
Be ready to define both roles in one sentence each and give an example field for each. Know that Tableau assigns the role from data type on connect and that you can drag a field across to change it.
Explain the mechanism: dimensions in the view define the granularity, and every measure is aggregated at exactly that granularity. Be able to show why adding a field to Color changes the per-mark numbers without changing the total.
Expect to diagnose a misclassified field in someone else's workbook — summed keys, averaged pre-computed ratios, years treated as quantities — and to explain the correct fix rather than patching the chart around it.
Own the convention rather than the click: which fields are published as dimensions in a certified data source, how default aggregations and field naming are set once upstream so every analyst inherits them, and when a metric belongs in the model instead of each workbook.
## The two roles Tableau gives every field When you connect to a data source, Tableau puts each column into the Data pane and assigns it one of two roles: **dimension** or **measure**. This is the first decision the tool makes on your behalf, and almost everything else about a worksheet follows from it. A **dimension** is a field whose values are used to *divide* the data. Product category, region, customer name, order date, a boolean flag — each distinct value carves the data into a group. Put a dimension on the Rows shelf and Tableau draws one row header per distinct value it finds in the data. A **measure** is a field whose values are *aggregated*. Sales, quantity, profit, discount — numbers you want summed, averaged, counted or ranged. Put a measure on a shelf and Tableau does not show the raw values; it shows an aggregate of them, written on the pill as `SUM(Sales)`, `AVG(Discount)` and so on. ## How the two combine The combination is the whole mental model of a worksheet: **dimensions determine how many marks there are, measures determine how big each one is.** A bar chart of `SUM(Sales)` by `Category` has as many bars as there are categories, and each bar's length is the sum of every underlying row belonging to that category. Add `Region` to Color and you now have one mark per Category-Region pair, each one summing fewer rows. Nothing about `Sales` changed; the granularity it is summed at changed. This is also why a measure alone gives you one number. With no dimension in the view, there is exactly one group — all the data — so `SUM(Sales)` renders as a single mark. ## How Tableau assigns the roles The assignment is heuristic and purely type-driven: numeric columns (integers, decimals) become measures; text, date, date-time and boolean columns become dimensions. Tableau has no knowledge of which numeric columns are keys, codes, years or ratios, so the heuristic misfires in predictable ways. In Tableau Desktop 2020.2 and later the Data pane groups fields by table under the current data model, with dimensions listed above a dividing line and measures below it inside each table. Older versions showed two flat Dimensions/Measures sections. The role itself means the same thing in both. ## Converting between them The role is a property of the field in the workbook, not of the source column, and you change it freely: drag the field across the dividing line, or use its menu to convert to dimension or to measure. Typical conversions: - A numeric **ID** (order ID, store number, postal code) is a label, not a quantity — convert to dimension. - A **year** or **month number** stored as an integer — convert to dimension so it slices instead of summing. - A **rating** or **score** you want to bucket by rather than average — convert to dimension. - A text column holding numbers you genuinely want to sum — change the data type first, then convert to measure. You can also override the role for a single use without changing the field: drag a dimension onto a shelf and pick an aggregation such as `COUNTD`, or right-click-drag a measure onto Rows and choose to place it as a dimension (attribute or dimension), which disaggregates it into distinct values. ## Where this goes wrong in practice The two failure modes an interviewer looks for: 1. **Summing an identifier.** `SUM(Order ID)` renders happily and means nothing. The chart looks plausible until someone checks the number. 2. **Assuming the number is wrong when the granularity changed.** A total that "shrinks" after adding a field to Color did not change; it was split across more marks. The measure is always aggregated at the view's current level of detail. A related trap is the *aggregate of an aggregate*. If your source already holds a pre-computed ratio per row, `AVG(that ratio)` weights every row equally and is usually not the ratio you want — you want the aggregate of the numerator over the aggregate of the denominator. ## Role versus discrete/continuous Candidates frequently merge two separate ideas. Dimension-versus-measure decides whether a field **slices or aggregates**. Discrete-versus-continuous (the blue/green pill colour) decides whether the field draws **headers or an axis**. The defaults line up — dimensions are usually discrete, measures usually continuous — but all four combinations exist: a continuous date dimension draws an axis, and a discrete measure draws a header. Saying "blue means dimension" is the answer that gets probed. ## What an interviewer is listening for A crisp statement that dimensions set granularity and measures are aggregated *at that granularity*, an example of the numeric-ID misclassification, and the awareness that the role is editable and independent of the pill colour.
- Your Year column is stored as an integer and Tableau put it in measures. What breaks, and how do you fix it?Dropped on a shelf it becomes SUM(Year), which adds year numbers together — a large nonsense value, and a single mark instead of one per year. Convert the field to a dimension so each year becomes its own header. If you also want date behaviour such as continuous trend axes, change the data type to date rather than leaving it an integer dimension.
- Does a dimension always have to be discrete in Tableau?No. Role and discrete/continuous are independent properties. A numeric or date dimension can be made continuous, in which case it draws an axis rather than headers — a continuous date dimension is the normal way to build a trend line. Likewise a measure can be made discrete, which turns its aggregated values into headers or text labels instead of an axis.
- Why does the same measure show a smaller number after you drag a field onto Color?Because the field on Color is a dimension and it added to the view's level of detail. The measure is still summing every underlying row, but those rows are now split across more marks, so each individual mark covers fewer of them. Nothing was filtered; the granularity changed. The grand total across all marks is unchanged.
Think of a spreadsheet PivotTable: dimensions are the fields you drag into Rows and Columns to define the groups, measures are the fields in the Values area that get summed inside each group.
saying these in an interview costs you the question
- Says blue always means dimension and green always means measure
- Claims the dimension/measure split is fixed by the source schema
- Sums a numeric ID or year without noticing it is a key
- Thinks a measure holds raw row values in the view rather than an aggregate
- Explains a shrinking number as filtering rather than finer granularity