Tableau Quiz: Row Level Vs Aggregated Data
10 questions · exam conditions
0:00
Row Level Vs Aggregated DataQuestion 1 of 10

An analyst creates the calculation IF [Sales] > AVG([Sales]) THEN "Above" ELSE "Not Above" END. Tableau reports that aggregate and non-aggregate arguments cannot be mixed.

What is the most accurate explanation of the error?

[Sales] refers to an individual row, while AVG([Sales]) refers to a collection of rows at an aggregate level.
[Sales] is a dimension in the calculation, while AVG([Sales]) converts it into a continuous date value.
AVG([Sales]) is evaluated once per data source, while conditional statements can be evaluated only once per worksheet.
[Sales] is already summed by default, while AVG([Sales]) attempts to aggregate that precomputed sum a second time.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Row Level Vs Aggregated Data

Practice Row Level Vs Aggregated Data in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Row Level Vs Aggregated Data, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An analyst creates the calculation IF [Sales] > AVG([Sales]) THEN "Above" ELSE "Not Above" END. Tableau reports that aggregate and non-aggregate arguments cannot be mixed.

What is the most accurate explanation of the error?

  1. [Sales] refers to an individual row, while AVG([Sales]) refers to a collection of rows at an aggregate level. (correct answer)
  2. [Sales] is a dimension in the calculation, while AVG([Sales]) converts it into a continuous date value.
  3. AVG([Sales]) is evaluated once per data source, while conditional statements can be evaluated only once per worksheet.
  4. [Sales] is already summed by default, while AVG([Sales]) attempts to aggregate that precomputed sum a second time.
Explanation: Whenever you see a question about calculation errors in Tableau, the key concept to examine is the level of detail at which each part of the formula is evaluated. Tableau distinguishes between row-level and aggregate-level expressions. A bare field reference like [Sales] is evaluated once per row — it represents a single value from a single record. An aggregate function like AVG([Sales]) collapses many rows into a single summary value across whatever grouping your view defines. When you write IF [Sales] > AVG([Sales]), you're asking Tableau to compare something evaluated at the row level with something evaluated at the aggregate level simultaneously — and Tableau has no consistent way to reconcile those two scopes. That mismatch is exactly the "mixed aggregate and non-aggregate arguments" error. Answer A is correct because it precisely identifies this scope conflict: [Sales] operates on individual rows, while AVG([Sales]) operates on a collection of rows. Answer B is wrong because AVG([Sales]) does not convert anything into a date — it computes a numerical average. Dates are a completely unrelated concept here. Answer C is wrong because aggregates are not evaluated "once per data source." They're computed per the dimensions in your view. Conditional statements also have no restriction on how many times they can be evaluated per worksheet. Answer D is wrong because [Sales] is not pre-summed by default. Raw field references are row-level, not pre-aggregated — this confuses row-level fields with Tableau's automatic SUM behavior in visualizations. Study tip: When writing calculated fields in Tableau, make sure every argument is at the same level — either all row-level or all wrapped in aggregate functions like AVG(), SUM(), etc.

Question 2

A data source has already been summarized to one row per Month and Product Category. It contains monthly SUM(Sales) but no transaction identifiers or transaction-level values.

Which request cannot be answered reliably from this data source alone?

  1. Compare total recorded Sales across product categories for the available months.
  2. Calculate average monthly Sales for each category over the available months.
  3. Identify the largest individual transaction within each category and month. (correct answer)
  4. Display one mark for each available month-category combination in the source.
Explanation: When working with pre-aggregated data in Tableau, the critical skill is recognizing what information has been permanently lost during summarization. If a dataset has already been collapsed to one row per Month-Category combination containing only SUM(Sales), you're working with totals — the underlying transaction-level detail no longer exists in the source. This is exactly what makes C the answer you cannot reliably perform. Identifying the largest individual transaction requires access to row-level records — the original sale amounts before they were summed together. Once those individual values have been rolled up into a single monthly total, there's no mathematical way to reverse-engineer what the biggest single transaction was. Tableau can only work with the data that's actually there. The other three options are entirely achievable with summarized monthly totals. A asks you to compare SUM(Sales) across categories — that's a straightforward aggregation of values already present. B asks for average monthly Sales per category, which you can calculate as ∑Monthly SalesNumber of Months\frac{\sum \text{Monthly Sales}}{\text{Number of Months}} using the rows available — no transaction detail needed. D simply asks Tableau to display one mark per row in the source, which is exactly what a pre-aggregated dataset with one row per Month-Category combination naturally produces. A useful rule of thumb: any question asking for minimum, maximum, median, or count of individual transactions cannot be answered from pre-aggregated data, because aggregation destroys the distribution. Whenever a question describes a summarized data source, immediately ask yourself — "does this request need the original rows, or just the totals?"

Question 3

An Orders table has one row for an order with Sales of 500500. It is joined to a Returns Detail table containing three matching rows for that order. In the resulting row set, the order's Sales value appears on each of the three joined rows. The worksheet displays SUM(Sales) for that order.

Assuming no additional correction, what value should the analyst expect, and why?

  1. 500500, because SUM(Sales) recognizes that the repeated values originated from one order and counts them only once.
  2. 1,5001{,}500, because SUM operates over the three post-join rows, each carrying a Sales value of 500500. (correct answer)
  3. 500500, because adding Order ID to the view collapses all joined rows sharing that ID before aggregation.
  4. 1,0001{,}000, because Tableau counts the original Orders row once and the Returns Detail table once when summing.
Explanation: Whenever you see a question about joins and aggregation in Tableau, the key concept to keep in mind is how joins duplicate rows and how aggregation functions like SUM operate on the resulting row set — not on the original source tables. When a one-to-many join occurs, the value from the "one" side (here, 500500 from Orders) gets copied onto every matching row from the "many" side (here, three rows from Returns Detail). Tableau doesn't know or care that those three 500500 values originated from a single order — SUM simply adds every value it sees in the post-join row set: 500+500+500=1,500500 + 500 + 500 = 1{,}500. That makes B correct. A is wrong because SUM has no built-in logic to detect or de-duplicate values that originated from a single source row. It operates mechanically over whatever rows exist after the join. C is wrong because adding Order ID to the view changes the level of detail for display purposes, but it does not collapse the underlying duplicated rows before aggregation occurs — the inflation is already baked in. D is wrong because Tableau does not count tables; it counts rows. The number 1,0001{,}000 has no logical basis here — it doesn't reflect how joins or SUM actually function. This type of row inflation is called a fanout problem, and it's one of the most common data accuracy pitfalls in Tableau. The standard fix is using a relationship instead of a join, or wrapping the measure in a FIXED LOD expression. Watch for any scenario where a one-to-many join involves an additive measure — that's your signal to check for fanout.

Question 4

A view contains one mark per Region. Segment is not part of the view's level of detail, but the analyst places ATTR(Segment) on Label. All rows contributing to the Central mark have Segment equal to Consumer, while the East mark includes both Consumer and Corporate rows.

What labels should appear for Central and East?

  1. Both show Consumer because ATTR selects the most frequent Segment within each aggregated regional mark.
  2. Central shows an asterisk, while East shows Consumer because it is the first Segment value encountered.
  3. Both show an asterisk because Segment is not included as a dimension in the view's level of detail.
  4. Central shows Consumer, while East shows an asterisk because its contributing rows have multiple Segment values. (correct answer)
Explanation: When you see ATTR() in Tableau, think of it as a "purity check." ATTR(field) returns the field's value if — and only if — every row contributing to that mark shares the same value. The moment multiple distinct values exist within a mark, ATTR returns an asterisk (*) as a signal that the aggregation is ambiguous. For the Central mark, every contributing row has Segment = Consumer. Because all values are identical, ATTR(Segment) successfully resolves to Consumer. For the East mark, rows contain both Consumer and Corporate. Since the values differ, ATTR cannot return a single meaningful value and instead displays an asterisk. That makes D the correct answer. Here's why the other choices miss the mark. A is wrong because ATTR does not apply any frequency or majority logic — it has no mechanism for picking the "most common" value; it's all-or-nothing. B is wrong for a similar reason: ATTR doesn't care about row order or which value appears first; sequence is irrelevant to how aggregation works in Tableau. C is the most tempting distractor — it's true that Segment isn't in the view's level of detail, but that alone doesn't cause an asterisk. Central proves this: Segment is also absent from its LOD, yet ATTR still resolves cleanly because all underlying values agree. The asterisk is triggered by disagreement among values, not merely by a field being absent from the view. A helpful study tip: remember the ATTR rule as "unanimous or asterisk." If you can confirm all rows agree on one value, ATTR returns it; any disagreement and you get *.

Question 5

A worksheet displays one mark per Category using SUM(Sales). The analyst changes the measure pill from SUM(Sales) to AVG(Sales) without adding or removing any dimensions.

Which statement best describes the effect of this change?

  1. The view becomes row-level because AVG requires Tableau to display every Sales value before averaging.
  2. The mark count doubles because Tableau must show both the total and the average for each category.
  3. The view becomes one mark per distinct Sales value because AVG adds Sales to the level of detail.
  4. The mark count stays at one per category, but each mark now summarizes its rows using an average. (correct answer)
Explanation: Whenever you see a question about changing aggregation functions in Tableau, anchor your thinking to one core principle: the level of detail in a view is determined by the dimensions present, not by how you aggregate the measure. Marks are created by the combination of dimension values on your shelves — the measure just controls how the numbers inside each mark are calculated. In this scenario, the only dimension is Category, so Tableau groups all rows belonging to each Category into one mark. When the measure was SUM(Sales), each mark showed the total Sales for that category. Switching to AVG(Sales) tells Tableau to compute the arithmetic mean of those same rows instead — but the grouping doesn't change. You still get exactly one mark per Category. That's precisely what D describes. A is wrong because AVG is still an aggregate function. Tableau never "unrolls" rows to display every individual value just because you chose AVG instead of SUM — row-level detail only appears if you add a dimension or use a row-level calculation like ATTR with a fixed LOD expression that changes granularity. B is wrong because switching aggregation methods doesn't cause Tableau to render additional marks. There's no duplication of marks for totals versus averages; those would require explicitly added reference lines or table calculations. C is wrong because Sales is the measure, not a dimension. Measures don't define granularity on their own, and AVG doesn't secretly promote Sales into the Level of Detail shelf. Study tip: On Tableau exam questions about mark count, always ask "what dimensions are on the shelves?" — the measure type (SUM, AVG, MAX, etc.) never changes how many marks appear.

Question 6

A worksheet initially shows one mark per Region using SUM(Sales). The analyst adds Order ID to Detail. Some orders contain several product-line rows with the same Order ID.

How should the analyst interpret the revised level of detail?

  1. Each mark is necessarily one source row because Order ID is unique for every row in Tableau.
  2. Each mark represents a region-order combination, which may still aggregate several underlying product-line rows. (correct answer)
  3. The marks remain at the Region level because fields on Detail never affect the view's granularity.
  4. Each mark represents a product-line row because adding any identifier automatically disaggregates all measures.
Explanation: When a field is added to the Detail shelf in Tableau, it increases the granularity of the view — meaning Tableau now draws one mark for each unique combination of all dimensions currently in the view, including the new one. This question tests whether you understand how Detail interacts with existing dimensions and with aggregation. Because Order ID is added to Detail alongside Region, the view now plots one mark per Region + Order ID combination. However, a single order can still span multiple product-line rows in the source data (same Order ID, different products). Tableau aggregates those rows into a single mark using SUM(Sales). This makes B correct: each mark represents a region-order pair that may still roll up several underlying rows. A is wrong because "unique per row" confuses row-level uniqueness in the data source with how Tableau handles granularity. Even if Order ID were unique per row, that logic doesn't govern how Tableau plots marks. C describes a common misconception — that Detail is purely cosmetic. In reality, Detail does change the view's granularity, which is its entire purpose. The marks are no longer at the Region level alone. D overcorrects in the opposite direction. Adding an identifier doesn't automatically disaggregate all measures down to the individual source row. Disaggregation only reaches the source-row level if the combination of all view dimensions maps exactly to one row each — which isn't guaranteed here. Study tip: Think of the Detail shelf as a "group-by" clause. Every dimension on any shelf (including Detail) participates in defining mark granularity, but aggregation still applies within each group.

Question 7

A data source contains 120 transaction rows. A worksheet places Region and Category on the view and displays SUM(Sales). There are three regions and four categories, and every region-category combination occurs in the data.

Which statement most accurately describes the resulting view?

  1. The view contains 12 marks, each representing Sales aggregated from rows sharing one region-category combination. (correct answer)
  2. The view contains 120 marks, because selecting SUM(Sales) preserves one mark for every transaction row.
  3. The view contains four marks, because Category determines the aggregation while Region only partitions the data source.
  4. The view contains three marks, because Region determines the aggregation while Category only labels each transaction.
Explanation: Whenever you see a question about marks and aggregation in Tableau, ask yourself: what dimensions are in the view, and how many unique combinations do they create? That mental model is the key to answering correctly. In Tableau, each unique combination of dimension values generates exactly one mark. When you place Region (3 values) and Category (4 values) on a worksheet, Tableau creates 3×4=123 \times 4 = 12 unique dimension combinations. All transaction rows that share the same Region-Category pair get rolled up into a single mark, with SUM(Sales) computed across those rows. That makes A the correct answer — 12 marks, each representing an aggregated slice of the data. B is wrong because it confuses row-level data with marks. SUM(Sales) is an aggregate measure, which means Tableau collapses multiple rows into one value per dimension combination. You only get one mark per row when you're working at the row level of detail (e.g., using a live, disaggregated view), not when dimensions are defining the partitions. C is wrong because it invents a hierarchy where Category "determines" aggregation and Region merely partitions. Both dimensions contribute equally to defining the level of detail — neither one dominates the other. D makes the same structural error as C but with the roles reversed, suggesting Region drives aggregation while Category is just a label. Tableau doesn't work this way; both dimensions jointly define each mark. A useful rule of thumb: count the marks by multiplying the distinct values of each dimension in the view. This formula works consistently across bar charts, crosstabs, and scatter plots alike.

Question 8

Customer X has two transaction rows, each with Sales of 6060. A view displays SUM(Sales) by Customer. The analyst is considering either a row-level condition [Sales] > 100 applied before aggregation or an aggregate condition SUM([Sales]) > 100 applied at the customer level.

What happens to Customer X under the two conditions?

  1. Customer X passes both conditions because its displayed SUM(Sales) is 120120.
  2. Customer X fails both conditions because neither source row individually exceeds 100100.
  3. Customer X fails the row-level condition but passes the aggregate customer-level condition. (correct answer)
  4. Customer X passes the row-level condition but fails the aggregate customer-level condition.
Explanation: Whenever you see a question about filtering in Tableau, ask yourself: at what stage of the data pipeline does this filter operate? Row-level conditions (using IF logic or dimension filters on unaggregated fields) evaluate each individual row before any grouping occurs. Aggregate conditions (like SUM([Sales]) > 100) evaluate the result after rows have been grouped and summed. Customer X has two rows, each with Sales=60Sales = 60. A row-level condition checks each row independently: is 60>10060 > 100? No — both rows fail, so Customer X is excluded entirely before aggregation even happens. But an aggregate condition first computes SUM(Sales)=60+60=120SUM(Sales) = 60 + 60 = 120 for Customer X, then asks: is 120>100120 > 100? Yes — Customer X passes and appears in the view. That's exactly what answer C describes, making it correct. Answer A is wrong because it claims Customer X passes both conditions. The row-level filter never sees 120120 — it sees individual 6060s, which fail the threshold. Answer B goes too far in the other direction, claiming Customer X fails both. It correctly identifies the row-level failure but ignores that the aggregate condition operates on the summed value 120120, not the source rows. Answer D inverts the logic entirely — no individual row reaches 100100, so the row-level condition cannot pass. A useful rule of thumb: if a filter uses a raw field like [Sales], it's row-level; if it wraps the field in an aggregation like SUM(), it's post-aggregation. Keeping this distinction clear will help you on any Tableau question involving LODs, table calculations, or filter order of operations.

Question 9

A worksheet has Region as its only dimension and displays COUNT(Order ID). The East region contains 450 underlying transaction rows but produces a single visible mark labeled 450.

Which interpretation of that East mark is correct?

  1. It is one aggregated mark whose label counts 450 non-null Order ID values in the underlying rows. (correct answer)
  2. It is 450 overlapping row-level marks that Tableau automatically combines into one visible label.
  3. It is one row-level mark because COUNT converts all transaction rows into a single physical record.
  4. It is 450 aggregated marks because every counted Order ID creates a separate mark within Region.
Explanation: When Tableau builds a view, it groups your data by the dimensions in the view and computes aggregations for each group — this is the mark = one aggregated result per dimension combination principle. With Region as the only dimension, Tableau creates exactly one mark per region, and that mark displays the result of whatever aggregate function you've chosen. For East, COUNT(Order ID) scans all 450 underlying transaction rows belonging to that region and returns a single number: 450 non-null Order ID values. That number becomes the label on one aggregated mark. Answer A captures this precisely — one mark, one aggregated count. Answer B is a common misconception: Tableau does not stack or layer 450 invisible row-level marks and then "collapse" them visually. The aggregation happens in the query before marks are rendered. There is no pile of overlapping marks hiding behind that label. Answer C confuses what COUNT does conceptually. COUNT is an aggregation function, not a data-reshaping function — it doesn't convert 450 rows into one physical record in your data source. The underlying rows still exist; COUNT simply summarizes them. Answer D inverts the logic entirely. COUNT produces one result per group, not one mark per counted value. If D were true, you'd see 450 separate marks just within East, which would require an additional dimension (like Order ID itself) to be in the view. A good study rule: in Tableau, the number of marks equals the number of distinct dimension combinations in the view — aggregation summarizes values, not marks.

Question 10

A customer has two transaction rows. The first has Sales of 100100 and Profit of 2020. The second has Sales of 900900 and Profit of 9090. A worksheet contains one mark for the customer.

Which result correctly distinguishes averaging a row-level ratio from calculating a ratio of aggregated values?

  1. AVG(Profit/Sales) is 11%11\%, while SUM(Profit)/SUM(Sales) is 15%15\%.
  2. AVG(Profit/Sales) is 15%15\%, while SUM(Profit)/SUM(Sales) is 11%11\%. (correct answer)
  3. Both calculations return 11%11\% because Tableau aggregates all measures before evaluating calculations.
  4. Both calculations return 15%15\% because each transaction contributes equally to the customer's mark.
Explanation: Whenever you see a question involving ratios and aggregation in Tableau, you need to carefully distinguish when the division happens — before or after aggregation. These two approaches can produce very different results. With AVG(Profit/Sales), Tableau computes the ratio at the row level first, then averages those ratios. Row 1 gives 20/100=20%20/100 = 20\% and Row 2 gives 90/900=10%90/900 = 10\%. Averaging those: (20%+10%)/2=15%(20\% + 10\%) / 2 = 15\%. With SUM(Profit)/SUM(Sales), Tableau aggregates both measures first, then divides: (20+90)/(100+900)=110/1000=11%(20 + 90) / (100 + 900) = 110/1000 = 11\%. This confirms B is correct — AVG(Profit/Sales) yields 15%15\% while SUM(Profit)/SUM(Sales) yields 11%11\%. A has the two values flipped, assigning 11%11\% to AVG(Profit/Sales) and 15%15\% to SUM(Profit)/SUM(Sales) — the math is exactly backwards. C is wrong because Tableau does not always aggregate before evaluating; row-level calculations inside aggregations like AVG operate on individual rows first. D is wrong because the transactions do not contribute equally — SUM(Profit)/SUM(Sales) is weighted by each row's Sales volume, so the larger $900\$900 transaction dominates. As a study tip, remember this pattern: row-level ratio → then aggregate (AVG of a ratio) treats each transaction equally, while aggregate → then divide (ratio of aggregates) weights by volume. On the Tableau exam, questions about aggregation order are common traps — always ask yourself at what point the division is occurring.