- Which FIXED LOD calculation returns the correct value of 200?
Answer: { FIXED [Customer ID] : SUM([Sales]) / COUNTD([Order ID]) }
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, and distinct orders = 2, so the target is $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 200.
Option A fails because COUNT([Order ID]) counts rows, not distinct orders. Since O2 spans three lines, COUNT returns 4 (four total rows), giving $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, and $100×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. - Assuming no additional deduplication, what result will the FIXED calculation return for this customer?
Answer: It returns 600 because FIXED aggregates the duplicated rows produced by the physical join.
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 order into three separate rows, each carrying $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, and sums them: 200+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 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. - What should the analyst expect after Category is added to the view?
Answer: Each category row for that customer displays 800 because Category does not alter the declared FIXED granularity.
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: 800. When you wrap it in MIN(), Tableau is simply aggregating a field that already holds the same constant value (800) 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 800 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. - Which calculation most directly creates the required metric?
Answer: { FIXED [Customer ID], DATETRUNC('year', [Order Date]) : SUM([Sales]) }
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.
- Which calculation uses the correct entity grain?
Answer: { FIXED [Customer ID], [Region] : SUM([Sales]) }
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.
- What value will
[Customer Lifetime Sales] return for C1, and how can the analyst make it respond to the Furniture filter? Answer: It returns 1,000; add the Category filter to context so it is evaluated before the FIXED calculation.
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 in Furniture and $600 in Technology, the FIXED expression returns $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. 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. This is exactly what A describes, making it correct.
B is wrong on both counts: the value returned without intervention is $1,000, not $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 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." - Which calculation correctly places the category condition inside the customer-level aggregation?
Answer: { FIXED [Customer ID] : SUM(IF [Category] = "Furniture" THEN [Sales] END) }
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.
- What first-purchase year is returned for C1 under the standard filter, and what change would make the calculation consider only 2025 records?
Answer: It returns 2022; convert the Order Date filter to a context filter.
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 2025, the FIXED expression still finds the true minimum Order Date across all years — which is 2022. 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 2025 records — and returns 2025 as the minimum. That confirms D is correct.
A is wrong on both counts: the result is 2022, not 2025, 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 2025 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. - Which approach produces the intended value of approximately 55.56%?
Answer: 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.
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% and C2 has a rate of 91≈11.11%. The unweighted average across those two customers is 2100%+11.11%≈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%. That's why B is correct.
A computes 10 total orders2 converted=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% 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%) and then divides by the number of customers (2), yielding 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. - Which calculation returns the required value of 200 without weighting customers by their number of rows?
Answer: { FIXED : SUM([Sales]) / COUNTD([Customer ID]) }
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 2100+300=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. This is the correct answer.
Option B looks appealing because { FIXED [Customer ID] : SUM([Sales]) } correctly computes per-customer totals — $100 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, so the row-level average is 4100+300+300+300=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 $100 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 — 4100+100+100+100=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.
