Tableau Quiz: Understanding Granularity
10 questions · exam conditions
0:00
Understanding GranularityQuestion 1 of 10

A published data source contains one row for each month, product, and region. It includes monthly sales but does not contain Order ID, Customer ID, or an order-level date.

A user wants a worksheet with one mark per customer per day. Which statement best describes the limitation?

The requested view can be created by disaggregating measures because Tableau will reconstruct customer-day records from monthly sales.
The requested view can be created by converting Month to an exact date and enabling Show Missing Values for Customer ID.
The requested granularity cannot be recovered from this source because the customer and daily detail was never retained.
The requested granularity requires placing Product and Region on Detail so Tableau can infer Customer ID from their combinations.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Understanding Granularity

Practice Understanding Granularity 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 Understanding Granularity, 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

A published data source contains one row for each month, product, and region. It includes monthly sales but does not contain Order ID, Customer ID, or an order-level date.

A user wants a worksheet with one mark per customer per day. Which statement best describes the limitation?

  1. The requested view can be created by disaggregating measures because Tableau will reconstruct customer-day records from monthly sales.
  2. The requested view can be created by converting Month to an exact date and enabling Show Missing Values for Customer ID.
  3. The requested granularity cannot be recovered from this source because the customer and daily detail was never retained. (correct answer)
  4. The requested granularity requires placing Product and Region on Detail so Tableau can infer Customer ID from their combinations.
Explanation: When a question asks about what a Tableau view "can" or "cannot" show, your first instinct should be to examine the source data's granularity — the finest level of detail the data actually captures. No tool, setting, or workaround can recreate information that was never recorded. This data source is structured at the month-product-region level. That means every row summarizes sales across an entire month for a given product and region. There are no Order IDs, no Customer IDs, and no daily timestamps. The customer-day detail simply does not exist in this dataset — it was aggregated away before the data source was ever created. C is correct because it accurately identifies that the required granularity is irretrievably absent from the source itself. A is wrong because disaggregating measures in Tableau only separates pre-existing rows — it cannot manufacture new records or reconstruct customers and days that were never stored. Disaggregation is a display setting, not a data recovery mechanism. B is wrong on two counts: converting a Month field to an exact date would be an arbitrary assignment (which day of the month?), and "Show Missing Values" fills in gaps along an existing dimension's domain — it cannot conjure Customer IDs that don't exist in the data. D is wrong because no combination of Product and Region dimensions can logically infer a Customer ID; those are independent attributes with no inherent relationship to individual customers. A good study habit here: whenever you see a question about Tableau views that seem impossible, ask yourself "Was this information ever in the data?" If the answer is no, no Tableau feature can help.

Question 2

A worksheet has one mark per State. City is placed in the view as ATTR([City]). Most states display an asterisk instead of a city name. The data has no calculation errors.

What is the most accurate interpretation of the asterisk?

  1. At least one underlying city value is null, so Tableau replaces all city names in that state with an asterisk.
  2. City is being treated as a measure, so Tableau cannot select an aggregation appropriate for text values.
  3. The state's mark contains multiple city values, so no single city value exists at the current level of detail. (correct answer)
  4. The city names conflict with the geographic role assigned to State, so Tableau marks the locations as ambiguous.
Explanation: Whenever you see ATTR() in Tableau, think about what that function is actually doing: it returns the single value shared by all underlying rows in a mark, but if multiple different values exist, it returns an asterisk (*) as a signal that no single representative value can be chosen. This is exactly what's happening in C. Each State mark aggregates many rows of data. Most states contain multiple cities, so when Tableau evaluates ATTR([City]), it finds more than one distinct city value within that mark and displays an asterisk — not an error, but a meaningful indicator that the level of detail in the view is too coarse to display a single city. A is wrong because nulls aren't the culprit here. ATTR() returns an asterisk when values differ, not specifically because one is null. A single null among matching values would still produce a result; only disagreement across non-null values (or a mix) triggers the asterisk in this context. B is wrong because City is a string dimension, not a measure. ATTR() is a dimension aggregation designed precisely for text fields — it's the appropriate function. Tableau isn't confused about the data type. D is wrong because this scenario has nothing to do with geographic roles or spatial ambiguity. The asterisk comes from aggregation behavior, not from a conflict between geographic assignments. Your study tip: memorize the rule — ATTR() = "all values the same? show it. values differ? show *." When you see an asterisk in a view using ATTR(), your first instinct should be level-of-detail mismatch, not nulls or errors.

Question 3

A worksheet has Category in the view and one mark per category. Segment is not currently used. A user is considering either placing Segment on Detail or placing Segment on Filters while keeping all segment values selected.

How do these two actions differ with respect to the worksheet's granularity?

  1. Both actions create one mark per category-segment combination because every dimension used anywhere in a worksheet defines mark granularity.
  2. Neither action changes granularity because only dimensions placed on Rows or Columns can partition marks into finer groups.
  3. The filter creates finer category-segment marks, while Detail only makes Segment available for tooltips and calculations.
  4. Detail creates category-segment marks, while an all-values filter retains category-level marks because it only restricts records. (correct answer)
Explanation: Whenever you see a question about mark granularity in Tableau, ask yourself: which shelf actually partitions data into finer groups? The answer hinges on understanding that granularity — the number of marks in the view — is determined by the dimensions that actively partition your data, not by every dimension referenced anywhere. Placing Segment on Detail tells Tableau to draw one mark per unique Category-Segment combination. Detail is a mark-level shelf that directly increases granularity, so a view with three categories and three segments would jump from 3 marks to 9. That's why D is correct in its first half. However, placing Segment on Filters with all values selected doesn't partition anything — it passes every record through unchanged, leaving Tableau aggregating to the same Category level as before. The filter only restricts rows; with all values included, it restricts nothing, so granularity stays at one mark per category. A is wrong because not every dimension used anywhere defines granularity. Dimensions on Filters (especially all-values filters), in calculated fields, or in tooltips alone do not create finer marks. B is wrong in the opposite direction — it overcorrects by claiming only Rows/Columns affect granularity, ignoring that Detail, Color, Size, and Shape also partition marks. C reverses the logic entirely: it claims the filter creates finer marks and Detail doesn't, which is exactly backwards. A helpful rule of thumb: Detail adds, Filters restrict. If a filter keeps everything, it changes nothing. On the exam, watch for "all values selected" as a signal that a filter has zero net effect on granularity.

Question 4

A data source has two line-item records. The first has sales of 120120 and quantity of 22; the second has sales of 180180 and quantity of 66. The requirement is to calculate overall sales per unit, giving each unit equal weight rather than giving each line item equal weight.

Which calculation satisfies the requirement at the combined level of detail?

  1. AVG([Sales] / [Quantity]), which calculates each line's unit value and weights both line items equally.
  2. SUM([Sales]) / SUM([Quantity]), which divides total sales by total units across the contributing records. (correct answer)
  3. SUM([Sales] / [Quantity]), which adds the line-level unit values before applying the worksheet dimensions.
  4. AVG([Sales]) / SUM([Quantity]), which averages line sales and then normalizes by the combined unit quantity.
Explanation: Whenever you see a question about aggregation in Tableau, ask yourself: what unit of measurement are you actually trying to compute? Here, the goal is overall sales per unit — meaning total revenue divided by total units sold — giving every unit equal weight, not every line item. Working through the numbers confirms this. Total sales are 120+180=300120 + 180 = 300 and total units are 2+6=82 + 6 = 8, giving 300/8=37.50300 / 8 = 37.50 per unit. That's exactly what B computes: SUM([Sales]) / SUM([Quantity]) pools all sales and all units before dividing, so a line item with 6 units influences the result proportionally more than one with 2 units — which is precisely what "equal weight per unit" requires. A is the classic trap. AVG([Sales] / [Quantity]) computes the unit value per line first — 120/2=60120/2 = 60 and 180/6=30180/6 = 30 — then averages those two results: (60+30)/2=45(60 + 30)/2 = 45. This gives each line item equal weight, not each unit, producing a distorted answer. C uses SUM([Sales] / [Quantity]), which adds the line-level unit values (60+30=9060 + 30 = 90) — a meaningless total that doesn't represent price per unit at any scale. D mixes aggregation levels illogically: averaging line-item sales ($150\$150) then dividing by total quantity (88) yields 18.7518.75, which has no coherent business interpretation. The study tip: when a question asks for a rate across combined records, always sum the numerator and denominator separately before dividing — never average the pre-computed rates.

Question 5

Customer A purchased only in the East region, Customer B purchased in both East and West, and Customer C purchased only in the West. A worksheet places Region in the view and displays COUNTD([Customer ID]). Grand totals are enabled.

Which result should be expected, and what does it demonstrate about granularity?

  1. East and West each show two, while the grand total shows three because distinct counts are recomputed at the total level. (correct answer)
  2. East and West each show two, while the grand total shows four because grand totals always add the visible marks.
  3. East shows one and West shows one, while the grand total shows three because shared customers are removed from regional marks.
  4. East and West each show three, while the grand total shows three because distinct customers are calculated before Region is applied.
Explanation: Whenever you see a question combining COUNTD() with grand totals in Tableau, you need to think carefully about at what level of granularity the calculation is being performed — because Tableau recomputes aggregate functions independently at each level, not by simply summing what's already displayed. Here's the setup: Customer A appears only in East, Customer B appears in both East and West, and Customer C appears only in West. When Region is in the view, Tableau evaluates COUNTD([Customer ID]) separately for each region. East contains Customers A and B → 2 distinct customers. West contains Customers B and C → 2 distinct customers. So both regional marks show 2. The grand total, however, doesn't add 2 + 2 = 4. Instead, Tableau recomputes COUNTD across the entire dataset, where all three customers exist exactly once → 3 distinct customers. This is answer A, and it perfectly demonstrates that aggregate calculations respect the granularity of the context they're evaluated in. Answer B is wrong because grand totals do not blindly sum the visible mark values — that would be a SUM of the displayed numbers, not a COUNTD of the underlying data. Answer C is wrong because Tableau doesn't remove Customer B from either regional mark; Customer B legitimately appears in both East and West transactions, so both regions correctly count them. Answer D is wrong because Tableau doesn't pre-aggregate distinct customers before applying the dimension — the calculation always runs within the current view's partition. A good rule of thumb: treat grand totals as a completely fresh query at a higher granularity. COUNTD at the total level asks "how many distinct values exist across everything?" — not "what do the subtotals add up to?"

Question 6

A customer table contains one annual target per customer. It is physically joined to an orders table containing many rows per customer. A regional worksheet uses SUM([Annual Target]), and customers with more orders contribute their target multiple times.

Which diagnosis and redesign most directly address the incorrect result?

  1. The target has been duplicated at order granularity by the join; preserve customer-level granularity by using a relationship or by aggregating orders to one row per customer before joining. (correct answer)
  2. The target is nonadditive across regions; replace SUM([Annual Target]) with AVG([Annual Target]) so each order row contributes an equal fraction of the customer's goal.
  3. The orders table is too coarsely aggregated; join additional line-item detail so Tableau can distribute each customer's target across a greater number of contributing rows.
  4. The regional dimension introduces the repetition; remove Region from the view so each duplicated target value is aggregated only once across the entire data source.
Explanation: Whenever you see unexpected inflation in an aggregated measure, your first instinct should be to ask: at what granularity does this field actually live, and how does the join affect that? This question tests your understanding of join fanout — a classic Tableau data-modeling pitfall. When a one-row-per-customer target field is physically joined to a many-rows-per-customer orders table, each customer's target value gets replicated once per order row. A customer with five orders now contributes their target five times to any SUM([Annual Target]). The result is mathematically wrong, not just imprecise. Answer A correctly diagnoses this as a join-induced duplication and prescribes the right fixes: use a Tableau relationship (which preserves each table's native granularity and handles aggregation correctly before combining results) or pre-aggregate the orders table to one row per customer before joining. Answer B is tempting but wrong — switching to AVG would only produce an accurate result by coincidence if every customer had exactly the same number of orders. It papers over the structural problem rather than solving it. Answer C moves in exactly the opposite direction you need. Adding more granular rows would increase duplication, making the inflation worse, not better. Answer D misidentifies Region as the cause. The duplication exists at the data-source level regardless of which dimensions you place in the view; hiding Region doesn't fix the underlying fanout. Study tip: Anytime you see a one-to-many join in Tableau and a measure that "lives" on the one side, immediately suspect fanout inflation — and reach for relationships or pre-aggregation as your fix.

Question 7

The data source is at line-item granularity. Order A has three line items, each carrying the order-level discount of 10%10\%. Order B has one line item carrying the order-level discount of 30%30\%. A worksheet displays AVG([Discount]) with no dimensions in the view.

Why does the worksheet display 15%15\% rather than the average discount per order of 20%20\%?

  1. Tableau averages the two distinct discount values but gives the lower discount additional weight because it is numerically smaller.
  2. Tableau first sums each order's discounts, then averages the two order totals using Order ID as an implicit dimension.
  3. Tableau averages the four line-item records, so Order A's discount contributes three times at the source granularity. (correct answer)
  4. Tableau converts each discount to a whole number before aggregation, causing rounding at the worksheet's displayed granularity.
Explanation: Whenever you see AVG() in Tableau with no dimensions in the view, ask yourself: what is the granularity of the underlying data? Tableau aggregates at the row level of the data source, not at some logical business level you might expect. Here, the data source has four line-item rows — three rows for Order A (each with 10%10\% discount) and one row for Order B (30%30\% discount). When Tableau computes AVG([Discount]), it treats all four rows equally: 10%+10%+10%+30%4=60%4=15%\frac{10\% + 10\% + 10\% + 30\%}{4} = \frac{60\%}{4} = 15\%. Because Order A appears three times at the source granularity, its discount is weighted three times. That's why C is correct — Order A's discount contributes three observations, not one. The 20%20\% figure you might intuitively expect comes from averaging per order: 10%+30%2=20%\frac{10\% + 30\%}{2} = 20\%. But Tableau has no way to know you want order-level averaging unless you bring Order ID into the view or use a LOD expression like {FIXED [Order ID] : AVG([Discount])}. A is wrong because Tableau doesn't apply numerical weighting based on a value's size — all rows are treated equally regardless of their magnitude. B is wrong because Tableau does not silently introduce Order ID as an implicit dimension; without dimensions in the view, it aggregates across all rows. D is wrong because Tableau performs no rounding or integer conversion on discount fields before aggregation. The key study tip: always identify the data source granularity before predicting what an aggregation returns. When rows repeat an attribute (like a discount), AVG() will weight that attribute by row count — not by the logical entity it belongs to.

Question 8

A data source contains orders dated January 2024, January 2025, and February 2025. A user places the discrete Month date part of Order Date in a view and sees only January and February headers.

Which change would separate the two January periods while retaining monthly granularity?

  1. Convert the Month date part to a measure so Tableau aggregates the numeric month values separately for each record.
  2. Add Order Date to Tooltip because tooltip fields extend the date granularity without changing the visible headers.
  3. Use Weekday as an additional discrete date part so the January records are partitioned by their calendar year.
  4. Use a month-level date value that includes year, such as a continuous month or a month-truncated date. (correct answer)
Explanation: When working with dates in Tableau, the core distinction to understand is date parts vs. date values, and how each handles the year component. A discrete date part (like Month) strips away context outside its own level — it only "sees" the month number, not the year. That's exactly the trap this question describes: both January 2024 and January 2025 collapse into a single "January" header because the year is invisible. To separate the two Januaries while keeping monthly granularity, you need a date that encodes year and month together. D is correct because a continuous month (or a date truncated to the month level) represents each month as a unique point in time — January 2024 and January 2025 become distinct values on the axis, not merged labels. You keep monthly detail without losing the year context. A is wrong because converting a date part to a measure just turns month numbers into aggregated numeric values (averaging 1s and 2s), which has nothing to do with distinguishing years — it destroys meaningful date context entirely. B is wrong because Tooltip fields have no effect on how Tableau groups or partitions the rows behind a view. Adding a field to Tooltip changes what appears on hover, not the view's underlying granularity or header structure. C is wrong because Weekday partitions data by day of the week (Sunday through Saturday), not by year. Stacking a Weekday date part onto Month would fragment data into day-of-week buckets — it wouldn't separate 2024 from 2025. Study tip: Whenever a question involves date headers "collapsing" different years together, immediately ask yourself: does this date field carry year information? Discrete date parts don't — date values do.

Question 9

A line-item data source contains several rows per order, and no order crosses regions. A worksheet is currently at Region granularity. The requirement is to display the average order sales for each region, giving every order equal weight regardless of its number of line items.

Which calculation most directly establishes order-level granularity before computing the regional average?

  1. { FIXED [Region] : AVG([Sales]) }, which averages line-item sales within each region without first constructing per-order totals.
  2. AVG({ INCLUDE [Order ID] : SUM([Sales]) }), which first sums sales per order within each region, then averages those order totals at the Region level. (correct answer)
  3. { EXCLUDE [Region] : SUM([Sales]) }, which removes the Region partition and returns the same overall sales total to every regional mark.
  4. SUM([Sales]) / COUNT([Order ID]), which divides regional sales by the number of line-item rows, giving orders with more lines greater influence.
Explanation: When working with LOD (Level of Detail) expressions in Tableau, the key question to ask is: at what granularity does my calculation need to operate, and in what order? Here, you need order-level totals first, then a regional average of those totals — a two-step aggregation that requires careful LOD nesting. Option B, AVG({ INCLUDE [Order ID] : SUM([Sales]) }), is the correct approach. The inner INCLUDE expression computes total sales per Order ID within the current view context (Region), producing one value per order. The outer AVG() then averages those per-order totals across each region. Every order contributes equally to the regional average, regardless of how many line items it contains — exactly what the requirement specifies. Option A uses { FIXED [Region] : AVG([Sales]) }, which averages individual line-item sales values within each region. This never constructs an order-level subtotal, so orders with more rows are overrepresented — the core problem the question is asking you to solve. Option C, { EXCLUDE [Region] : SUM([Sales]) }, removes the Region dimension from the partition, collapsing everything into a single grand total and returning that same number to every regional mark. This is a misuse of EXCLUDE and doesn't produce regional or order-level insight at all. Option D, SUM([Sales]) / COUNT([Order ID]), counts Order ID occurrences — not distinct orders — so multi-line orders are counted multiple times in the denominator, skewing the result downward for orders with more line items. Remember: when you need to "summarize, then re-aggregate," reach for a nested LOD. The inner LOD handles the first summarization; the outer aggregate handles the second.

Question 10

A worksheet contains four underlying records: Furniture–Consumer sales of 100100, Furniture–Corporate sales of 150150, Office Supplies–Consumer sales of 200200, and Office Supplies–Consumer sales of 5050. The view initially contains Category and SUM([Sales]), producing one mark per category.

What happens when Segment is added to Detail on the Marks card, assuming no filters or other dimensions are present?

  1. The view contains four marks, and the sum across all marks increases because repeated combinations are displayed separately.
  2. The view contains three marks, and the sum across all marks remains 500500 because sales are partitioned by category and segment. (correct answer)
  3. The view contains two marks, and Segment affects tooltip content without changing the level of detail of the marks.
  4. The view contains three marks, and the sum across all marks becomes 350350 because duplicate combinations are collapsed.
Explanation: When you add a dimension to Detail on the Marks card, you're telling Tableau to increase the view's level of detail — meaning Tableau will create a separate mark for each unique combination of all dimensions currently in the view. The key question to ask yourself is: how many distinct combinations exist across all dimensions on the Marks card? Here, the two dimensions are Category and Segment. Looking at the four underlying records, the distinct Category–Segment combinations are: Furniture–Consumer, Furniture–Corporate, and Office Supplies–Consumer. That's three unique combinations. Tableau creates one mark per combination, so the view contains three marks. The total sales across those marks is 100+150+(200+50)=500100 + 150 + (200 + 50) = 500, unchanged — Tableau partitions and aggregates the data differently, but never drops or duplicates sales values. This confirms B is correct. A is wrong because it claims the total increases. Adding Detail never inflates the aggregate total — it only redistributes the same 500500 across more marks. C is wrong because it confuses Detail with Tooltip. Adding a dimension to Tooltip leaves the level of detail unchanged; adding it to Detail explicitly changes it. The view would not remain at two marks. D is wrong on two counts: the total stays at 500500, not 350350, and the claim that "duplicate combinations are collapsed" misrepresents what's happening — Tableau simply aggregates the two Office Supplies–Consumer records into one mark summing to 250250. A helpful rule of thumb: Detail = new marks, Tooltip = no new marks. Memorize this distinction, as Tableau exam questions frequently test whether you know which shelf controls granularity versus display.