INCLUDE/EXCLUDE LOD - Tableau

1. How will [Excluded Sales] compare with SUM([Sales]) for each region, assuming no other view dimensions?
   Answer: It will equal regional SUM([Sales]) because Category is not part of the view granularity When you see a question about EXCLUDE LOD expressions, the key question to ask yourself is: what dimensions are actually in the view? EXCLUDE tells Tableau to compute an aggregate while ignoring a specified dimension — but you can only exclude something that exists. If the dimension isn't contributing to the view's granularity in the first place, EXCLUDE has nothing to remove. Here, the view contains only Region, not Category. The expression { EXCLUDE [Category] : SUM([Sales]) } asks Tableau to sum Sales while stripping Category out of the granularity. But since Category was never in the view to begin with, the computation already happens at the Region level — exactly where SUM([Sales]) operates. The EXCLUDE expression therefore produces the same regional total as a plain SUM([Sales]), making C the correct answer. A is wrong because EXCLUDE doesn't collapse the entire dataset into one grand total — it only removes the named dimension from the current view granularity. Region remains, so results are still partitioned by Region. B is a fabricated behavior; EXCLUDE never implicitly averages anything. The aggregation used is whatever you write inside the expression — here, SUM. D misrepresents how EXCLUDE works. It does not return null when the excluded dimension is absent from the view; it simply computes as if the dimension were never there, which in this case matches the view's existing granularity. A useful rule of thumb: if the dimension named in EXCLUDE is already absent from the view, the LOD result will mirror the equivalent non-LOD aggregate at the current view level. Always trace what's actually driving granularity before predicting LOD behavior.
2. What value does the calculation return on the Chairs mark?
   Answer: $100$, because Sub-Category remains in the LOD even after Category is excluded Whenever you see an EXCLUDE LOD expression, the key question to ask is: which dimensions remain in scope after the exclusion? EXCLUDE removes a specified dimension from the view's level of detail — it does not aggregate up to that dimension or strip away other dimensions still present. In this view, both Category and Sub-Category are in the viz. The expression { EXCLUDE [Category] : SUM([Sales]) } removes only Category from the LOD, leaving Sub-Category fully intact. Because Sub-Category names are unique across the entire data source, each Sub-Category already maps to exactly one group of rows. Removing Category changes nothing about how those rows are partitioned — the calculation still resolves at the Sub-Category level. For the Chairs mark, that means $SUM([Sales]) = \$100$, the same value you'd get from a plain SUM([Sales]). Answer A is correct. Answer B is wrong because EXCLUDE does not roll values up to the excluded dimension — that's a misreading of how the keyword works. Excluding Category doesn't cause Chairs to inherit Furniture's $\$300$ total. Answer C confuses EXCLUDE with a fixed-to-nothing expression like { SUM([Sales]) }, which truly ignores all view dimensions and returns the grand total of $\$500$. Answer D describes a "sum of others" logic that doesn't exist in any standard LOD syntax — no exclusion mechanism skips the current mark. A useful rule of thumb: when a Sub-Category is unique across the data source, any EXCLUDE [Category] expression evaluated on a Sub-Category mark will behave identically to the plain aggregation, because Sub-Category alone already fully partitions the data.
3. What value is displayed for East when [Customer Sales] is placed in the view as AVG([Customer Sales])?
   Answer: $225$, because Tableau averages customer totals of $150$ and $300$ within the region When you see an INCLUDE LOD expression combined with an aggregate like AVG in the view, you need to think in two distinct steps: what the LOD computes per customer, and then how the view aggregates those results at the region level. Here's how it works. The expression { INCLUDE [Customer] : SUM([Sales]) } forces Tableau to compute a sum at the Customer level, even though the view only shows Region. For Customer C1, the two sales records ($100$ and $50$) sum to $150$. For Customer C2, the single record of $300$ produces $150 + 300$ a customer total of $300$. Now the view applies AVG([Customer Sales]) across those two customer-level values: $\frac{150 + 300}{2} = 225$. That confirms C is correct. Choice A is wrong because it averages the three raw sales records — $\frac{100 + 50 + 300}{3} = 150$ — as if the INCLUDE expression never ran. The whole point of INCLUDE is to aggregate before the view-level aggregation, so you should never be averaging raw rows after the fact. Choice B incorrectly sums the customer totals ($150 + 300 = 450$) rather than averaging them. Placing a measure as AVG in the view means Tableau averages, not sums, the LOD results. Choice D introduces a "largest sale per customer" logic ($\frac{100 + 300}{2} = 200$) that has no basis in SUM or AVG — it confuses this scenario with a MAX-based calculation. A useful rule of thumb: with LOD expressions, always resolve the inner computation first, then apply the outer view-level aggregation. That two-step discipline will protect you from every distractor here.
4. What value does this calculation display for both product marks?
   Answer: $53.33$, because excluding Product leaves Region as the granularity, and AVG is applied to the three underlying sales records in that region When you see an LOD expression using EXCLUDE, your first job is to identify what granularity remains after the listed dimension is removed. In a Region–Product view, excluding [Product] leaves only [Region] — so Tableau computes AVG([Sales]) across all underlying records that belong to that region, regardless of which product mark is being displayed. Here, the region contains three raw sales records: $10$, $90$, and $60$. The average across all three is $\frac{10 + 90 + 60}{3} = \frac{160}{3} \approx 53.33$. Because this result lives at the Region level, Tableau stamps the same value — $53.33$ — onto every product mark in that region. That makes B correct. A is wrong because it confuses an EXCLUDE LOD with a table calculation or a view-level average of product subtotals. Tableau does not first roll up P1 to $100$ and P2 to $60$ and then average those two numbers to get $80$; the LOD goes straight to the underlying records at the excluded granularity. C is wrong on two counts: AVG is not a median function, and even if it were, the median of $\{10, 60, 90\}$ happens to be $60$ — a coincidence that makes this distractor especially tricky. The calculation uses arithmetic mean, not median. D is wrong because removing a dimension from the LOD scope never converts AVG into a SUM. The aggregation function you write is the aggregation function Tableau uses. As a study habit, always trace an LOD expression in two steps: (1) determine the resulting granularity after INCLUDE/EXCLUDE is applied, then (2) apply the stated aggregation to the records at that granularity.
5. Assuming no other filters or calculations, what percentage does the remaining Technology mark display?
   Answer: $100\%$, because standard dimension filters are applied before INCLUDE and EXCLUDE LOD expressions, so only Technology records remain when the denominator is evaluated When you see a question involving LOD expressions and filters in Tableau, the most important concept to recall is the order of operations: standard dimension filters are applied before EXCLUDE and INCLUDE LOD expressions are evaluated. This means that by the time an EXCLUDE expression calculates, the dataset has already been restricted by any active dimension filter. In this scenario, the Category filter retains only Technology records. When Tableau evaluates { EXCLUDE [Category] : SUM([Sales]) }, it operates on the already-filtered dataset — which contains only Technology data. Excluding Category from a single-category dataset simply aggregates that same data, giving a denominator of $80$. The numerator is also $80$, so the mark displays $80 / 80 = 100\%$. That makes A the correct answer. B describes the behavior of context filters and fixed LOD expressions, not standard dimension filters. EXCLUDE is only immune to filters that are below it in the order of operations — standard dimension filters rank above it, so they do affect EXCLUDE calculations. C arrives at $80/120$ by incorrectly assuming Furniture remains in the denominator after the filter, which would only be true if a context filter were used instead of a standard dimension filter. D misunderstands what EXCLUDE does — removing a dimension from the grouping level does not delete records; it simply aggregates across that dimension within the remaining data. Your study tip: memorize Tableau's filter order — Extract → Data Source → Context → Sets/Conditions → Fixed LOD → Dimension Filters → Include/Exclude LOD → Measure Filters. Standard dimension filters sit above INCLUDE/EXCLUDE, which is the key distinction this question tests.
6. What value is returned for each of the three monthly marks in that quarter?
   Answer: Each month displays $60$ because Year and Quarter remain as the calculation granularity When you see an EXCLUDE LOD expression in Tableau, ask yourself: which dimensions remain after the exclusion, and what level of aggregation do those remaining dimensions define? That's the granularity the calculation will use. Here, the view contains Year, Quarter, and Month. The expression { EXCLUDE [Month] : SUM([Sales]) } tells Tableau to compute the sum of Sales at every dimension level except Month. That leaves Year and Quarter as the controlling dimensions. For the first quarter of the year in question, the three months contribute $10 + 20 + 30 = 60$. Since Month is excluded, all three monthly marks share the same Year + Quarter context, so each one displays $60$. That confirms C is correct. A is wrong because it describes a constraint that doesn't exist — EXCLUDE expressions can remove any dimension currently in the view, including Month, regardless of whether other date parts like Quarter are present. B misunderstands what "excluding Month" means; it doesn't collapse the entire date hierarchy down to the year level. Year and Quarter are still active dimensions, so the calculation anchors to the quarter, not the full year. D introduces averaging, which is simply not what EXCLUDE does — it computes SUM([Sales]) at the remaining grain, not an average across the removed dimension. A useful study habit: whenever you evaluate an LOD expression, mentally redraw the view without the excluded field and ask what aggregation you'd get at that new grain. That single step will guide you to the right answer on virtually any LOD question.
7. What happens when the analyst changes the view from State only to State and Segment?
   Answer: The values become $150$ for Consumer and $200$ for Corporate because Segment joins the INCLUDE granularity When you see a question involving LOD expressions like INCLUDE, the critical concept to master is granularity interaction: an INCLUDE expression adds dimensions to the view's granularity, meaning if the view gains new dimensions, the INCLUDE computation adjusts accordingly. Here's the logic for answer B. The expression { INCLUDE [City] : SUM([Sales]) } computes sales at the City level, or finer, depending on the view. When the view shows only State, Tableau computes city-level sums — City A = $400$, City B = $300$ — and AVG across two cities gives $350$. When you add Segment to the view, the granularity becomes City × Segment. Now Tableau computes sales per City per Segment: City A Consumer = $100$, City A Corporate = $300$, City B Consumer = $200$, City B Corporate = $100$. The AVG across two city values within Consumer is $\frac{100 + 200}{2} = 150$, and within Corporate is $\frac{300 + 100}{2} = 200$. That confirms B is correct. Answer A is wrong because INCLUDE is not permanently locked — it responds to finer view granularity, which is the whole point of INCLUDE versus FIXED. Answer C is wrong because it misapplies summation instead of averaging; the AVG aggregation is what the analyst chose, not SUM. Answer D is wrong because it assumes the state average of $350$ is simply split equally, which ignores how segment-level values are actually computed from the underlying data. The key study tip: INCLUDE = "at least these dimensions." Adding dimensions to the view always refines an INCLUDE calculation, whereas FIXED ignores the view entirely.
8. Which calculation returns the required share for each category while retaining Category in the view?
   Answer: SUM([Sales]) / { EXCLUDE [Category] : SUM([Sales]) } When working with Level of Detail (LOD) expressions in Tableau, the key question is always: what granularity does each part of the calculation operate at? Here, you need a denominator that represents total sales per region — ignoring Category — while keeping Category visible in the view. EXCLUDE [Category] does exactly that. It forces the calculation to aggregate as if Category weren't in the view, producing the regional total. So { EXCLUDE [Category] : SUM([Sales]) } returns $200$ for East ($120 + 80$) on every row, regardless of which Category you're looking at. Dividing row-level sales by that regional total gives you $120/200 = 60\%$ for Furniture and $80/200 = 40\%$ for Technology — precisely what the analyst needs. That's why D is correct. A uses INCLUDE [Category], which forces Category into the LOD expression's scope. Since Category is already in the view, this simply returns each category's own sales value — making the ratio $1.0$ for every row. Useless as a share calculation. B uses EXCLUDE [Region], which removes Region from scope and aggregates across all regions, not just East. The denominator becomes a company-wide total, not a regional one — wrong level of aggregation. C uses INCLUDE [Region], which locks Region into the calculation but doesn't remove Category. The result still varies by Category, so you're dividing a number by itself again — same trap as A. A helpful rule of thumb: when you need "share of parent group," EXCLUDE the dimension that defines the child level (the one breaking things into smaller pieces), so the denominator collapses up to the parent.
9. What value is displayed when the analyst uses MEDIAN([Order Sales]) at the Category level?
   Answer: $60$, because Tableau first computes order totals of $100$, $60$, and $60$, then applies MEDIAN to those three values When you see an INCLUDE LOD expression combined with a higher-level aggregation in Tableau, your job is to track two separate computation steps: what INCLUDE produces per grain, and what the outer aggregation does with those results. Here, { INCLUDE [Order ID] : SUM([Sales]) } tells Tableau to compute a SUM of Sales for each Order ID, regardless of what level the view is at. That produces three order-level totals: O1 = $10 + 90 = 100$, O2 = $60$, and O3 = $30 + 30 = 60$. Now you have three values — $100, 60, 60$ — one per order. When MEDIAN([Order Sales]) is evaluated at the Category level, Tableau applies MEDIAN across those three order totals. Sorting them gives $60, 60, 100$, and the middle value is $\mathbf{60}$. That confirms D is correct. A is wrong because INCLUDE already collapsed the row-level detail into order totals before MEDIAN runs — Tableau is not taking the median of five raw line items ($10, 90, 60, 30, 30$). B describes an AVERAGE operation ($\frac{100+60+60}{3} \approx 73.33$), not MEDIAN, so it misidentifies the aggregation function entirely. C would result from summing the three totals ($100+60+60=220$), which would happen with SUM, not MEDIAN — it conflates the outer aggregation type. Study tip: Always mentally separate LOD expressions into two phases — what the LOD computes and what the outer aggregate does to those results. Getting the grain right for each phase eliminates nearly every LOD trap question.
10. What does SUM([Sales]) / { EXCLUDE [Category], [Segment] : SUM([Sales]) } return for this mark?
    Answer: $10\%$, because both dimensions are removed and the denominator is $500$ When you see an EXCLUDE LOD expression, the key question to ask is: which dimensions remain in the calculation's scope after the listed ones are removed? The view has three dimensions: Region, Category, and Segment. The expression { EXCLUDE [Category], [Segment] : SUM([Sales]) } strips out both Category and Segment, leaving only Region in the aggregation context. That means the denominator aggregates sales across the entire region — all categories and all segments combined — which gives $500$. The numerator is the mark's own sales of $50$, so the result is $50 / 500 = 10\%$, confirming B is correct. A is wrong because it assumes only one dimension is excluded, leaving Category as the denominator level ($200$). But both Category and Segment are explicitly excluded — you can't partially apply the expression. C makes the same type of error in the opposite direction, imagining that only Category is excluded so Segment drives the denominator ($150$). Again, both dimensions are removed simultaneously. D reflects a fundamental misunderstanding: excluding dimensions broadens the aggregation scope rather than narrowing it. Removing Category and Segment doesn't isolate a single mark — it rolls sales up to the regional total. A useful mental model: think of EXCLUDE as "zoom out." Every dimension you list gets dropped from the grouping, so the calculation rises to a coarser level of detail. The more dimensions you exclude, the larger the denominator tends to be. On exam questions, always count which dimensions remain after exclusion — that tells you exactly what level the LOD computes at.

Start this quiz