Tableau Quiz: Include Exclude Lod

10 questions · exam conditions

0:00

Include Exclude LodQuestion 1 of 10

A worksheet contains the following East region records: Customer C1 has sales records of $100$ and $50$ , while Customer C2 has one sales record of $300$ . The view contains only Region, and the analyst creates [Customer Sales] = { INCLUDE [Customer] : SUM([Sales]) }.

What value is displayed for East when [Customer Sales] is placed in the view as AVG([Customer Sales])?

150

, because Tableau averages the three underlying sales records before displaying the region

450

, because Tableau sums the two customer-level values before displaying the region

225

, because Tableau averages customer totals of

150

and

300

within the region

200

, because Tableau averages the largest sale associated with each customer in the region

← Back to quizzes

Tableau Quiz

Tableau Quiz: Include Exclude Lod

Practice Include Exclude 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 Include Exclude 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

What value is displayed for East when [Customer Sales] is placed in the view as AVG([Customer Sales])?

$150$ , because Tableau averages the three underlying sales records before displaying the region
$450$ , because Tableau sums the two customer-level values before displaying the region
$225$ , because Tableau averages customer totals of $150$ and $300$ within the region (correct answer)
$200$ , because Tableau averages the largest sale associated with each customer in the region

Explanation: 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.

Question 2

A Region–Category view uses SUM([Sales]) / { EXCLUDE [Category] : SUM([Sales]) }. East has Furniture sales of $120$ and Technology sales of $80$ . A standard dimension filter on Category is then set to retain only Technology.

Assuming no other filters or calculations, what percentage does the remaining Technology mark display?

$100\%$ , because standard dimension filters are applied before INCLUDE and EXCLUDE LOD expressions, so only Technology records remain when the denominator is evaluated (correct answer)
$40\%$ , because EXCLUDE is evaluated before dimension filters, so the denominator always reflects all original categories regardless of the filter
$66.7\%$ , because the EXCLUDE expression retains Furniture in the denominator while the view filter removes it from the numerator, producing $80/120$
$0\%$ , because removing Category from the denominator's grouping also removes the filtered Technology record, leaving a zero in the denominator

Explanation: 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.

Question 3

A view contains Category and Sub-Category. Sub-category names are unique across the entire data source. The Chairs mark has sales of $100$ , the Furniture category has sales of $300$ , and total sales across all categories are $500$ . The analyst uses { EXCLUDE [Category] : SUM([Sales]) }.

What value does the calculation return on the Chairs mark?

$100$ , because Sub-Category remains in the LOD even after Category is excluded (correct answer)
$300$ , because excluding Category automatically rolls each sub-category up to its category total
$500$ , because removing Category forces the calculation to use the complete data-source total
$400$ , because the calculation sums every sub-category other than the current Chairs mark

Explanation: 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.

Question 4

A date view contains discrete Year, Quarter, and Month. For one year's first quarter, January sales are $10$ , February sales are $20$ , and March sales are $30$ . The analyst adds { EXCLUDE [Month] : SUM([Sales]) } to the monthly marks.

What value is returned for each of the three monthly marks in that quarter?

Each month retains its own value because Month cannot be excluded while Quarter is present
Each month displays the annual total because removing Month also removes the date hierarchy
Each month displays $60$ because Year and Quarter remain as the calculation granularity (correct answer)
Each month displays $20$ because Tableau averages the three months after excluding Month

Explanation: 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.

Question 5

A state contains two cities and two segments. City A has Consumer sales of $100$ and Corporate sales of $300$ . City B has Consumer sales of $200$ and Corporate sales of $100$ . An analyst defines [City Sales] = { INCLUDE [City] : SUM([Sales]) } and displays it using AVG([City Sales]).

What happens when the analyst changes the view from State only to State and Segment?

The State value remains $350$ for both segments because the INCLUDE expression is permanently fixed at City
The values become $150$ for Consumer and $200$ for Corporate because Segment joins the INCLUDE granularity (correct answer)
The values become $300$ for Consumer and $400$ for Corporate because Tableau sums city values within each segment
The values become $175$ for Consumer and $175$ for Corporate because the original state average is divided equally

Explanation: 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.

Question 6

A worksheet contains Region but not Category. The analyst adds [Excluded Sales] = { EXCLUDE [Category] : SUM([Sales]) } to the view alongside SUM([Sales]).

How will [Excluded Sales] compare with SUM([Sales]) for each region, assuming no other view dimensions?

It will return one total for the entire data source because Category is removed from all records
It will return category averages within each region because the excluded field is implicitly averaged
It will equal regional SUM([Sales]) because Category is not part of the view granularity (correct answer)
It will return null because EXCLUDE can remove only dimensions currently displayed in the view

Explanation: 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.

Question 7

A category contains three orders represented by five line-item sales records. Order O1 has lines of $10$ and $90$ , Order O2 has one line of $60$ , and Order O3 has lines of $30$ and $30$ . The analyst defines [Order Sales] = { INCLUDE [Order ID] : SUM([Sales]) }.

What value is displayed when the analyst uses MEDIAN([Order Sales]) at the Category level?

$30$ , because Tableau computes the median of the five individual line-item values rather than the three order-level totals
$73.33$ , because Tableau averages the three order totals of $100$ , $60$ , and $60$ instead of taking the median
$220$ , because Tableau sums all three order-level totals when a higher-level aggregation is applied to the INCLUDE result
$60$ , because Tableau first computes order totals of $100$ , $60$ , and $60$ , then applies MEDIAN to those three values (correct answer)

Explanation: 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.

Question 8

A Region–Product view contains three underlying sales records in one region. Product P1 has records of $10$ and $90$ , while Product P2 has one record of $60$ . The analyst creates { EXCLUDE [Product] : AVG([Sales]) }.

What value does this calculation display for both product marks?

$80$ , because Tableau first aggregates each product to a total and then averages the two resulting product-level values
$53.33$ , because excluding Product leaves Region as the granularity, and AVG is applied to the three underlying sales records in that region (correct answer)
$60$ , because Tableau takes the median of the three regional records once the Product dimension has been removed from the calculation
$160$ , because removing the Product dimension causes Tableau to sum all records within the region instead of averaging them

Explanation: 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.

Question 9

A view contains Region, Category, and Segment. For one mark, sales are $50$ . Within the same region, its Category has total sales of $200$ , its Segment has total sales of $150$ , and all regional sales total $500$ .

What does SUM([Sales]) / { EXCLUDE [Category], [Segment] : SUM([Sales]) } return for this mark?

$25\%$ , because the denominator is the mark's category total of $200$
$10\%$ , because both dimensions are removed and the denominator is $500$ (correct answer)
$33.3\%$ , because the denominator is the mark's segment total of $150$
$100\%$ , because excluding both dimensions leaves only the current mark's sales

Explanation: 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.

Question 10

A view contains Region and Category. In the East region, Furniture sales are $120$ and Technology sales are $80$ . The analyst needs each category's share of its regional sales total.

Which calculation returns the required share for each category while retaining Category in the view?

{ INCLUDE [Category] : SUM([Sales]) } / SUM([Sales])
{ EXCLUDE [Region] : SUM([Sales]) } / SUM([Sales])
{ INCLUDE [Region] : SUM([Sales]) } / SUM([Sales])
SUM([Sales]) / { EXCLUDE [Category] : SUM([Sales]) } (correct answer)

Explanation: 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.