Tableau Quiz: Fixed Lod
10 questions · exam conditions
0:00
Fixed LodQuestion 1 of 10

An analyst defines [Lifetime Sales] = { FIXED [Customer ID] : SUM([Sales]) }. The worksheet places Customer ID and Category on Rows and displays MIN([Lifetime Sales]). A customer has 800800 of lifetime sales across three categories.

What should the analyst expect after Category is added to the view?

Each category row for that customer displays 800800 because Category does not alter the declared FIXED granularity.
Each category row displays only its category sales because view dimensions are automatically appended to FIXED.
The three category rows divide the lifetime value equally, so each displays approximately 266.67266.67.
The calculation becomes invalid because a FIXED measure cannot appear below its declared level of detail.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Fixed Lod

Practice Fixed Lod 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 Fixed Lod, 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 defines [Lifetime Sales] = { FIXED [Customer ID] : SUM([Sales]) }. The worksheet places Customer ID and Category on Rows and displays MIN([Lifetime Sales]). A customer has 800800 of lifetime sales across three categories.

What should the analyst expect after Category is added to the view?

  1. Each category row for that customer displays 800800 because Category does not alter the declared FIXED granularity. (correct answer)
  2. Each category row displays only its category sales because view dimensions are automatically appended to FIXED.
  3. The three category rows divide the lifetime value equally, so each displays approximately 266.67266.67.
  4. The calculation becomes invalid because a FIXED measure cannot appear below its declared level of detail.
Explanation: Whenever you see a question involving FIXED LOD expressions, the most important thing to remember is that FIXED ignores view dimensions entirely — it computes at exactly the level you declare, nothing more, nothing less. Here, { FIXED [Customer ID] : SUM([Sales]) } is locked to the Customer ID grain. That means for every row belonging to a given customer — regardless of how many dimensions you add to the view — the expression always returns that customer's total lifetime sales: 800800. When you wrap it in MIN(), Tableau is simply aggregating a field that already holds the same constant value (800800) for every row of that customer, so MIN(800) = 800. Adding Category to the view creates three separate rows for that customer, but each row still sees the full 800800 lifetime value. That makes A correct. B is wrong because it describes how a regular SUM([Sales]) would behave — view dimensions do affect normal aggregations, but FIXED explicitly bypasses them. C describes a division that never happens; Tableau does not redistribute or prorate a FIXED value across the categories it appears in. D is a fabricated rule — there is no concept in Tableau that invalidates a FIXED calculation simply because the view drills below its declared level. FIXED expressions are perfectly valid at any view granularity; they just always return their declared-grain result. A useful rule of thumb: mentally label FIXED as "view-blind." No matter what rows or columns you add to the worksheet, a FIXED field answers only the question you asked it at declaration time.

Question 2

An analyst creates [First Purchase] = { FIXED [Customer ID] : MIN([Order Date]) }. Customer C1 first purchased in 20222022 and purchased again in 20252025. A standard Order Date dimension filter limits the worksheet to 20252025.

What first-purchase year is returned for C1 under the standard filter, and what change would make the calculation consider only 20252025 records?

  1. It returns 20252025; remove Customer ID from the FIXED declaration.
  2. It returns 20252025; convert the Order Date filter to a measure filter.
  3. It returns 20222022; add Order Date to the worksheet's Detail shelf.
  4. It returns 20222022; convert the Order Date filter to a context filter. (correct answer)
Explanation: Whenever you see a question involving FIXED LOD expressions and filters, your first instinct should be to ask: where does this calculation sit in Tableau's order of operations? FIXED LOD expressions are computed before dimension filters, meaning a standard drag-and-drop dimension filter on Order Date has no effect on what the LOD expression sees. It scans the entire underlying dataset regardless of what the view is showing. So for Customer C1, even though the worksheet is filtered to 20252025, the FIXED expression still finds the true minimum Order Date across all years — which is 20222022. That makes the first half of the correct answer clear. To force the LOD expression to respect the filter, you need to promote the Order Date filter to a context filter. Context filters run before FIXED LOD expressions in the order of operations, so the LOD calculation only sees the records that survive the context filter — in this case, only 20252025 records — and returns 20252025 as the minimum. That confirms D is correct. A is wrong on both counts: the result is 20222022, not 20252025, and removing Customer ID from the FIXED declaration would change what is being fixed, not how the filter interacts with it. B correctly identifies that the result is 20252025 only if you fix the filter issue, but measure filters run after LOD expressions — they can't restrict what the LOD sees. C is wrong because adding Order Date to Detail doesn't change filter precedence at all. A reliable study tip: memorize Tableau's order of operations as Extract → Data Source Filters → Context Filters → FIXED LODs → Dimension Filters → Measure Filters. Many exam questions hinge on knowing exactly where FIXED sits in that chain.

Question 3

Customer C1 converts its only order, giving a conversion rate of 100%100\%. Customer C2 converts one of nine orders, giving a conversion rate of approximately 11.11%11.11\%. The analyst wants an unweighted average of customer conversion rates, not the overall order-level conversion rate.

Which approach produces the intended value of approximately 55.56%55.56\%?

  1. Divide the total number of converted orders by the total number of orders, producing an overall order-weighted conversion rate of 20%20\%.
  2. Calculate each customer's conversion rate with a FIXED LOD expression, surface one mark per customer in the view, and average those customer-level rates. (correct answer)
  3. Calculate each customer's conversion rate with a FIXED LOD expression, then sum those rates across all underlying order rows to get a combined total.
  4. Compute the average of the row-level conversion flag across all order rows, then divide that result by the number of distinct customers.
Explanation: Whenever you see a question about averaging rates in Tableau, ask yourself: what is the unit of analysis? If the analyst wants one rate per customer — not one rate per order — the aggregation must happen at the customer level before any final average is computed. Here, C1 has a conversion rate of 100%100\% and C2 has a rate of 19≈11.11%\frac{1}{9} \approx 11.11\%. The unweighted average across those two customers is 100%+11.11%2≈55.56%.\frac{100\% + 11.11\%}{2} \approx 55.56\%. To produce this in Tableau, you need each customer's rate locked at the customer grain regardless of how many order rows exist — that's exactly what a FIXED LOD expression does. Once each customer's rate is computed at the customer level, surfacing one mark per customer and averaging those marks gives you 55.56%55.56\%. That's why B is correct. A computes 2 converted10 total orders=20%\frac{2 \text{ converted}}{10 \text{ total orders}} = 20\%, which is an order-weighted rate — it treats C2's nine orders as nine votes, drowning out C1's single conversion. This is precisely the measure the analyst wants to avoid. C uses a FIXED LOD correctly to calculate each customer's rate, but then sums those rates across all underlying order rows. C2's rate of 11.11%11.11\% gets repeated nine times in the sum, reintroducing the row-level weighting problem rather than eliminating it. D averages the row-level conversion flag (still 20%20\%) and then divides by the number of customers (2), yielding 10%10\% — a mathematically arbitrary result with no meaningful interpretation. The key study tip: a FIXED LOD alone doesn't solve an aggregation problem — how you then aggregate it matters just as much. Always trace what the final average is actually iterating over.

Question 4

Orders is physically joined to Support Cases on Customer ID. A customer has one order worth 200200 and three support-case rows. The join therefore produces three copies of the order row. The analyst creates { FIXED [Customer ID] : SUM([Sales]) }.

Assuming no additional deduplication, what result will the FIXED calculation return for this customer?

  1. It returns approximately 66.6766.67 because the customer total is divided among the three case rows.
  2. It returns 200200 because FIXED automatically deduplicates measures at the customer level.
  3. It returns 600600 because FIXED aggregates the duplicated rows produced by the physical join. (correct answer)
  4. It returns null because Sales and Support Cases originate from different physical tables.
Explanation: Whenever you see a question combining physical joins with LOD expressions, your first instinct should be to ask: what does the underlying row-level data actually look like before aggregation happens? Here, Orders joins to Support Cases on Customer ID. Because one order row matches three support-case rows, the physical join fans out that single $200\$200 order into three separate rows, each carrying $200\$200 in Sales. This multiplication happens at the data-source level, before any Tableau calculation runs. When { FIXED [Customer ID] : SUM([Sales]) } executes, it sees three rows for this customer, each with $200\$200, and sums them: 200+200+200=$600200 + 200 + 200 = \$600. FIXED anchors the aggregation to the Customer ID dimension, but it does not inspect or correct the row structure — it simply aggregates whatever rows exist at that grain. So C is correct. A is wrong because FIXED performs a sum, not an average or allocation. Nothing divides the total across rows — that $66.67\$66.67 logic has no basis in how LOD expressions work. B is the most tempting distractor. Many students assume FIXED is "smart" enough to deduplicate, but FIXED only controls the dimension of aggregation, not the integrity of the underlying row count. Deduplication requires explicit techniques like COUNTD or a relationship instead of a join. D is wrong because FIXED does not return null simply because measures originate from different tables — null would only arise if the field itself contained null values. Study tip: Remember that join fanout is a pre-calculation problem. LOD expressions operate on the fanned-out rows, so always audit your join cardinality before trusting aggregated results.

Question 5

A worksheet uses [Customer Lifetime Sales] = { FIXED [Customer ID] : SUM([Sales]) }. Customer C1 has 400400 in Furniture sales and 600600 in Technology sales. The worksheet contains a standard dimension filter that keeps only Furniture.

What value will [Customer Lifetime Sales] return for C1, and how can the analyst make it respond to the Furniture filter?

  1. It returns 1,0001{,}000; add the Category filter to context so it is evaluated before the FIXED calculation. (correct answer)
  2. It returns 400400; add the Category filter to context so the FIXED calculation ignores that filter.
  3. It returns 1,0001{,}000; replace FIXED with INCLUDE because context filters cannot affect LOD calculations.
  4. It returns 400400; remove Customer ID from the view so the FIXED calculation uses only visible rows.
Explanation: Whenever you see a question involving FIXED LOD expressions and filters, your first instinct should be to think about Tableau's order of operations: context filters fire first, then FIXED LODs are computed, then dimension filters are applied. This hierarchy is everything. { FIXED [Customer ID] : SUM([Sales]) } aggregates all of C1's sales across every category before any dimension filter touches the data. Since C1 has $400\$400 in Furniture and $600\$600 in Technology, the FIXED expression returns $1,000\$1{,}000 — the Furniture-only dimension filter arrives too late in the pipeline to shrink that result. So the field ignores your Category filter entirely, and every row for C1 displays $1,000\$1{,}000. To make the calculation respond to the Category filter, you promote that filter to a context filter, which moves it upstream — now it runs before the FIXED LOD is evaluated, so only Furniture rows exist when the aggregation happens. That makes [Customer Lifetime Sales] return $400\$400. This is exactly what A describes, making it correct. B is wrong on both counts: the value returned without intervention is $1,000\$1{,}000, not $400\$400, and adding a filter to context makes the FIXED calculation respect that filter, not ignore it — the opposite of what B claims. C correctly identifies the $1,000\$1{,}000 result, but the fix is wrong. Context filters absolutely can affect FIXED calculations — that's precisely their purpose. Switching to INCLUDE would introduce a different behavior tied to view dimensions, not solve the filter-scope problem. D is wrong because removing Customer ID from the view changes the visualization structure, not the LOD scope. FIXED expressions ignore view dimensions by definition regardless of what's on the canvas. Study tip: Memorize Tableau's filter order — Context → Sets → LOD (FIXED) → Dimension filters → Measure filters. When a FIXED LOD seems to ignore a filter, your solution is almost always "add that filter to context."

Question 6

A customer can place orders in multiple calendar years. The analyst needs annual sales per customer, and the result must remain at that customer-year grain even if Month is later added to the worksheet.

Which calculation most directly creates the required metric?

  1. { FIXED [Customer ID], DATETRUNC('year', [Order Date]) : SUM([Sales]) } (correct answer)
  2. { FIXED [Customer ID] : SUM([Sales]) } / COUNTD(YEAR([Order Date]))
  3. { FIXED DATETRUNC('year', [Order Date]) : SUM([Sales]) }
  4. { INCLUDE [Customer ID], DATETRUNC('month', [Order Date]) : SUM([Sales]) }
Explanation: When working with LOD (Level of Detail) expressions in Tableau, the key question to ask is: what dimensions should define the grain of my calculation, and will it stay stable regardless of what's on the view? A FIXED LOD ignores the view's context entirely, computing at exactly the dimensions you specify — making it ideal when you need a locked grain. The requirement here is annual sales per customer, anchored to the customer-year level no matter what filters or dimensions (like Month) get added to the sheet. Option A — { FIXED [Customer ID], DATETRUNC('year', [Order Date]) : SUM([Sales]) } — does exactly this. By fixing on both Customer ID and the year-truncated date, Tableau aggregates sales at that precise intersection and holds it there regardless of view granularity. This is the correct answer. Option B attempts to divide total customer sales by a count of distinct years, which is both fragile and imprecise — COUNTD inside a regular expression is tricky, and the formula doesn't cleanly produce a stable per-year figure. Option C fixes only on the year, dropping Customer ID entirely, so you'd get annual sales across all customers — wrong grain. Option D uses INCLUDE, which adds dimensions to the view's existing context. If Month is on the view, the calculation would compute at the customer-month-year level, breaking the required customer-year grain. Study tip: On Tableau LOD questions, match the LOD type to the stability requirement. FIXED = grain is locked regardless of the view; INCLUDE = grain expands with the view; EXCLUDE = grain contracts from the view. When a question says "must remain at this grain even if fields are added," FIXED is almost always your answer.

Question 7

A data source contains one row for customer C1 with sales of 100100 and three rows for customer C2, each with sales of 100100. An analyst needs a single value representing average lifetime sales per customer.

Which calculation returns the required value of 200200 without weighting customers by their number of rows?

  1. { FIXED : SUM([Sales]) / COUNTD([Customer ID]) } (correct answer)
  2. AVG({ FIXED [Customer ID] : SUM([Sales]) })
  3. { FIXED [Customer ID] : AVG([Sales]) }
  4. { FIXED : AVG([Sales]) }
Explanation: When working with LOD (Level of Detail) expressions in Tableau, the key question to ask is: at what granularity do I want to aggregate, and how do I combine those aggregates correctly? Here, the goal is a true per-customer average — C1 contributes $100 and C2 contributes $300, so the average across two customers is $100+3002=200.\frac{100 + 300}{2} = 200. $ Option A achieves this exactly. The inner expression { FIXED : SUM([Sales]) } computes total sales across all rows ($400), and COUNTD([Customer ID]) counts distinct customers (2), giving 400/2=200.400 / 2 = 200. This is the correct answer. Option B looks appealing because { FIXED [Customer ID] : SUM([Sales]) } correctly computes per-customer totals — 100forC1and100 for C1 and 300 for C2 — but wrapping it in AVG() means Tableau averages across rows, not customers. C2 has three rows each showing 300,sotherow−levelaverageis300, so the row-level average is 100+300+300+3004=250,\frac{100 + 300 + 300 + 300}{4} = 250, $ not 200. You're still weighting by row count. Option C uses AVG inside the LOD, which averages within each customer's rows. C2's three rows of 100averageto100 average to 100, making C2 look identical to C1. You lose the true total for C2 entirely. Option D computes a grand AVG([Sales]) across all rows — \frac{100+100+100+100}{4} = 100 — which ignores customer boundaries completely. The study tip: whenever you need an unweighted average over groups, compute the group-level aggregate first, then divide by COUNTD. Don't rely on AVG applied to an LOD result, because it re-aggregates at row granularity.

Question 8

The Orders data contains one row per order line. Customer C1 has two orders: order O1 totals 100100 on one line, while order O2 totals 300300 across three lines. The analyst needs C1's average order value as a customer-level metric.

Which FIXED LOD calculation returns the correct value of 200200?

  1. { FIXED [Customer ID] : SUM([Sales]) / COUNT([Order ID]) }
  2. { FIXED [Customer ID] : AVG([Sales]) * COUNTD([Order ID]) }
  3. { FIXED [Customer ID], [Order ID] : AVG([Sales]) }
  4. { FIXED [Customer ID] : SUM([Sales]) / COUNTD([Order ID]) } (correct answer)
Explanation: When working with LOD expressions, the key challenge is identifying the correct level of granularity for your calculation. Here, you need a customer-level average order value — meaning total sales divided by the number of distinct orders, not order lines. For customer C1: total sales = $100+$300=$400\$100 + \$300 = \$400, and distinct orders = 22, so the target is $400/2=$200\$400 / 2 = \$200. Option D, { FIXED [Customer ID] : SUM([Sales]) / COUNTD([Order ID]) }, does exactly this — it sums all sales for the customer and divides by the count of distinct order IDs, correctly returning 200200. Option A fails because COUNT([Order ID]) counts rows, not distinct orders. Since O2 spans three lines, COUNT returns 44 (four total rows), giving $400/4=$100\$400 / 4 = \$100 — wrong. Option B uses AVG([Sales]), which averages across individual lines (not orders), then multiplies by distinct order count. AVG here gives $400/4=$100\$400/4 = \$100, and $100×2=$200\$100 \times 2 = \$200 happens to produce the right number in this specific example, but the logic breaks down with unequal line distributions — it's not a reliable formula. Option C computes an average per customer-order combination, not a single customer-level metric, so it returns multiple values rather than one consolidated average order value. The key study tip: whenever you see aggregation questions in Tableau, ask yourself whether you need COUNT (rows) vs. COUNTD (distinct values). Confusing the two is one of the most common LOD traps on the exam.

Question 9

An analyst wants each customer's Furniture sales, regardless of whether the worksheet currently displays Category. Customers with no Furniture rows should have a null or zero result that can be handled separately.

Which calculation correctly places the category condition inside the customer-level aggregation?

  1. { FIXED [Customer ID], [Category] : SUM([Sales]) }
  2. IF [Category] = "Furniture" THEN { FIXED [Customer ID] : SUM([Sales]) } END
  3. { FIXED [Customer ID] : SUM(IF [Category] = "Furniture" THEN [Sales] END) } (correct answer)
  4. { FIXED [Category] : SUM(IF [Customer ID] THEN [Sales] END) }
Explanation: When working with LOD (Level of Detail) expressions in Tableau, the key question is always: where does the filter logic live? If you want to aggregate at a specific granularity while restricting which rows contribute, the condition must sit inside the aggregation, not outside it. Option C achieves exactly this. { FIXED [Customer ID] : SUM(IF [Category] = "Furniture" THEN [Sales] END) } locks the computation to the customer level, then within that fixed scope, only sums Sales rows where Category equals "Furniture." Customers with no Furniture purchases contribute null (since no rows pass the IF condition), which can be handled downstream with ZN() or IFNULL(). This is the correct answer. Option A includes [Category] in the FIXED dimensions, meaning it computes a separate total per customer per category — you'd get a row for Furniture, a row for Technology, etc. That's a different granularity entirely, not a single Furniture figure per customer. Option B wraps the entire FIXED expression inside an IF, which means the LOD first computes all sales per customer (no category filter inside), then filters the result at the view level. The condition is outside the aggregation, so non-Furniture rows still feed the sum. Option D reverses the dimensions — FIXED on Category rather than Customer ID — and misuses IF [Customer ID] as a boolean, which is not a valid filter on a dimension field. Study tip: When building LOD expressions, ask yourself: "Should the filter shape what gets summed, or hide the result after?" If it shapes the sum, it belongs inside the aggregation — as in option C.

Question 10

Customer IDs are globally unique, but a customer may purchase in multiple regions. The business defines a per-entity metric as each customer's total sales within each region. The metric must remain customer-region specific when Product is added to the view.

Which calculation uses the correct entity grain?

  1. { FIXED [Customer ID] : SUM([Sales]) }
  2. { FIXED [Customer ID], [Region] : SUM([Sales]) } (correct answer)
  3. { FIXED [Region] : SUM([Sales]) }
  4. { FIXED [Customer ID], [Product] : SUM([Sales]) }
Explanation: When working with LOD (Level of Detail) expressions in Tableau, your first job is to identify the grain — the exact combination of dimensions that defines one "unit" of the metric. The business here defines the metric as each customer's total sales within each region, so the grain is Customer + Region. That means your FIXED expression must anchor to both dimensions simultaneously. Option B, { FIXED [Customer ID], [Region] : SUM([Sales]) }, does exactly this. It computes one sales total per customer-region pair, and because it's FIXED, adding Product to the view won't disaggregate it — the value stays locked to that customer-region grain. This is precisely what the business requirement demands. Option A anchors only to [Customer ID], collapsing all regions together into a single customer-level total. This loses the per-region specificity the business requires. Option C anchors only to [Region], aggregating across all customers in that region — the customer dimension is completely dropped, making it a region-level metric, not a customer-region metric. Option D anchors to [Customer ID] and [Product], which introduces product into the grain. When Product is added to the view, this expression would vary by product, violating the requirement that the metric remain customer-region specific regardless of what else is in the view. A useful rule of thumb: the dimensions inside your FIXED clause should match the business definition of the entity, nothing more and nothing less. Extra dimensions over-partition; missing dimensions under-partition. Read the metric definition carefully, list the required grain dimensions, and map them directly into FIXED.