Filters & Aggregation Interaction - Tableau

1. What happens after Sub-Category is added?
   Answer: No marks remain because each Sub-Category aggregate is below $500$. When a filter like SUM([Sales]) >= 500 exists in Tableau, the level of detail at which that aggregation is computed depends entirely on the granularity of the current view. This is the core concept being tested: filters evaluate at the mark level, meaning the aggregation recalculates based on whatever dimensions are currently in the view. When only Category is in the view, each mark represents one Category. Furniture's SUM([Sales]) = $300 + 250 = 550$, and Technology's = $450 + 100 = 550$. Both pass the $\geq 500$ threshold. So far, so good. But once you add Sub-Category, the view now has one mark per Sub-Category within each Category. The filter re-evaluates at this finer grain: Chairs = $300$, Tables = $250$, Phones = $450$, Accessories = $100$. Every single one falls below $500$, so no marks survive the filter — confirming that C is correct. Choice A is the trap most students fall into. It assumes Tableau still uses the Category-level totals after Sub-Category is added, but the view's granularity has changed, so it doesn't. Choice B incorrectly assumes Tableau ranks or compares Sub-Categories against each other rather than applying the threshold filter independently to each mark. Choice D misunderstands the filter entirely — it treats the filter as a "top member" selector rather than an aggregate threshold. The key strategy to remember: whenever a question involves filters and changing dimensions, always ask yourself "at what granularity is this aggregate being computed right now?" The answer changes as the view changes.
2. Which statement correctly describes the filtered worksheet?
   Answer: Customers A and C remain, and all of each customer's sales records contribute to the displayed totals. Whenever you see a question about filters in Tableau, ask yourself: at what level of aggregation does this filter operate? A dimension filter on the view works on individual marks, but a measure filter — one applied to an aggregated expression like SUM([Sales]) — evaluates the aggregation after all underlying records have been rolled up for each mark. Here, each mark represents one customer, so SUM([Sales]) is computed per customer before the filter is checked. Customer A totals $300 + 250 = 550$, Customer B totals $450$, and Customer C totals $200 + 400 = 600$. The filter SUM([Sales]) >= 500 then compares each customer's already-aggregated total against the threshold. Customers A ($550$) and C ($600$) pass; Customer B ($450$) does not. Crucially, all of each qualifying customer's underlying records contributed to that aggregate — none were excluded individually. This makes A correct. B describes a row-level filter behavior, where only records individually meeting $\geq 500$ would count. That's not how aggregate measure filters work — the filter never touches individual rows. C assumes the filter evaluates each sales record separately, which would mean Customer A's records of $300$ and $250$ never reach $500$ alone. Again, this confuses row-level filtering with aggregate filtering. D conflates the filter threshold with a grand total across all customers, which is not how Tableau applies per-mark filters. A useful rule of thumb: if the filter expression contains an aggregate function (like SUM, AVG, or COUNT), it operates on the mark-level aggregate, not on individual data rows.
3. What profit ratios are displayed after the filter?
   Answer: East displays $20\%$ and West displays $5\%$, because the filter removes Furniture records before profit and sales are summed for each region. When a dimension filter is applied in Tableau, it removes rows from the underlying dataset before any aggregations are calculated. This means SUM([Profit]) and SUM([Sales]) only accumulate values from the rows that survive the filter — Tableau doesn't pre-compute category-level ratios and then combine them. With Category filtered to Technology only, East's calculation becomes $20 / 100 = 20\%$, and West's becomes $10 / 200 = 5\%$. That confirms D as the correct answer: Furniture records are excluded entirely, so only Technology profit and sales feed into each region's aggregation. A is wrong because Tableau doesn't average pre-computed ratios across categories. Ratio measures like this are calculated on the aggregated totals, not as averages of sub-group ratios — a classic weighted vs. simple average trap. B is partially right that only Technology is retained, but wrong about the outcome. East has $20/100 = 20\%$ and West has $10/200 = 5\%$ — these are not equal. The distractor tricks you into thinking both regions must share the same margin just because they share the same filtered category. C describes a scenario where the filter doesn't work, as if both Furniture and Technology data remain in the totals. This would only be possible if Context Filters or table calculations were involved — not a standard dimension filter on a worksheet. A useful rule of thumb: in Tableau, dimension filters act like a WHERE clause in SQL — they strip rows first, then aggregations run on what's left. Always trace the data flow in that order.
4. Which marks remain in the worksheet after both filters are applied?
   Answer: Only West remains, displayed with sales of $450$. When a question involves multiple filters in Tableau, the critical concept to understand is filter order of operations: Dimension filters are applied before Measure filters. This means the data is first restricted by dimension, and then the aggregated values are computed and filtered. Here's how the logic unfolds. The Category filter (a dimension filter) runs first, removing all Furniture records. What remains is East's single Technology record of $300$ and West's two Technology records of $200$ and $250$. Tableau then aggregates these filtered records by Region: East shows $SUM = 300$ and West shows $SUM = 200 + 250 = 450$. Next, the measure filter SUM([Sales]) >= 350 is applied to those aggregated values. East's $300$ fails the threshold and is removed; West's $450$ passes. Only West survives, displaying $450$ — confirming B is correct. Answer A is wrong because East's Technology total is only $300$, which fails the >= 350 measure filter. Answer C is wrong on two counts: neither region shows $500$, and including East would require it to pass the measure filter, which it doesn't. Answer D is a common trap — it imagines the dimension filter never applied, as if you'd see the original unfiltered regional totals. That misunderstands how filter order works entirely. Your study tip: memorize Tableau's filter order — Extract → Data Source → Context → Dimension → Measure → Table Calc. Exam questions frequently test whether you know that dimension filters reshape the data before measure filters evaluate aggregations.
5. Which values does the EXCLUDE calculation display after filtering?
   Answer: East displays $100$, and West displays $200$, because the dimension filter removes Technology records before EXCLUDE aggregates the remaining records at the Region level. Whenever you see a Tableau question involving LOD expressions and filters, the key is understanding where each filter type sits in the order of operations. Standard dimension filters are applied before EXCLUDE LOD expressions are evaluated — meaning they restrict the underlying data first, and then the LOD calculation runs on whatever records remain. Here's how that plays out in this scenario. The Category filter is set to Furniture, so Technology records are removed from the dataset entirely before any calculation occurs. With only Furniture records remaining, { EXCLUDE [Category] : SUM([Sales]) } drops Category from the view's level of detail and aggregates Sales at the Region level. East has only $\$100$ in Furniture sales left, so it displays $\$100$. West has only $\$200$, so it displays $\$200$. That confirms D is correct. A is the most tempting trap — it assumes EXCLUDE can "see through" dimension filters the way it can ignore dimensions in the view. It cannot. EXCLUDE only removes view dimensions from its grouping scope; it does not override context filters or standard dimension filters, which have already trimmed the data upstream. B misunderstands what EXCLUDE does altogether — it doesn't surface per-category breakdowns; it collapses them. C invents a behavior where EXCLUDE somehow retrieves only the filtered-out records, which has no basis in how LOD expressions work. A reliable study tip: memorize Tableau's order of operations. Standard dimension filters sit above LOD expressions, so they always restrict data before EXCLUDE, INCLUDE, or FIXED runs. If you need an LOD to override a filter, you must use a context filter or a FIXED expression instead.
6. What distinct-customer counts are displayed after the filter?
   Answer: East displays $2$, and West displays $2$. When you see COUNTD() combined with a dimension filter in Tableau, the key question to ask is: after the filter is applied, which distinct values remain in each partition? Here, the Category filter to Office Supplies removes any rows where Category = Technology. That means only Office Supplies transactions survive. Now evaluate each region independently: - East: Customer A appears in Office Supplies ✓, Customer B appears only in Technology ✗ (filtered out), Customer C appears in Office Supplies ✓. That leaves 2 distinct customers: A and C. - West: Customer A appears in Office Supplies ✓, Customer D appears in Office Supplies ✓. That leaves 2 distinct customers: A and D. So both regions display $2$, making B the correct answer. A is wrong because it credits East with $3$ — that would be the pre-filter count including Customer B, who only purchased Technology and is excluded once the filter is applied. C makes the same category of error for West, inflating it to $3$ with no basis — West never had three customers even before filtering. D would only be correct if COUNTD were counting something else entirely (like a single overlap value), which misunderstands how distinct counts work across separate regions. Study tip: Always mentally "run the filter first, then aggregate." Filters eliminate rows before COUNTD evaluates them, so any customer who exists only in the filtered-out category disappears completely from the count — they don't contribute a partial value.
7. After the filter is applied, what percentages are displayed for the visible regions?
   Answer: East displays $50\%$ and West displays $30\%$. When working with table calculations and filters in Tableau, the critical concept to understand is when each filter type executes. Table calculation filters are applied after the underlying aggregation is complete, but crucially, they hide marks without recalculating the table calculation across only the visible data. Here's the logic: the original Percent of Total values are East $50\%$, West $30\%$, South $20\%$. The filter removes South (since $20\% < 25\%$), but the remaining percentages — East $50\%$ and West $30\%$ — stay exactly as computed from all three regions. The table calculation already "saw" all the data; filtering just hides South's mark from view. So answer A is correct: East shows $50\%$ and West shows $30\%$, which don't sum to $100\%$. Answer B describes what would happen if the percentages recomputed after filtering — $\frac{50}{80} = 62.5\%$ and $\frac{30}{80} = 37.5\%$ — but table calculation filters do not trigger recomputation. That behavior would occur with a regular dimension filter, not a table calculation filter. Answer C is wrong because South is correctly excluded by the filter (its $20\%$ falls below the $25\%$ threshold). Answer D invents behavior that doesn't exist; no normalization to $100\%$ occurs, and East's dominance doesn't collapse the other values. A useful rule of thumb: table calculation filters hide, they don't recompute. On the Tableau exam, whenever you see a question combining table calculations with filters, ask yourself whether the filter type recalculates the underlying math or simply suppresses marks from view.
8. Which products and values will the worksheet display?
   Answer: Alpha at $100$ and Beta at $800$, because the top-two set is determined before the standard Region filter. Whenever you see a question mixing Top N filters with dimension filters in Tableau, the key is understanding filter order of operations. Tableau applies filters in a fixed sequence: context filters → sets/Top N filters → dimension filters → measure filters. This order determines what data each filter "sees." Because the Top N product filter executes before the standard Region dimension filter, it evaluates SUM([Sales]) across all data, not just East. At that stage, Alpha ($1000$) and Beta ($900$) rank highest globally and are locked into the view as the top-two set. Only after that selection does the Region filter narrow the data to East. The result: Alpha and Beta remain in the view, but their displayed values reflect only their East sales — $100$ and $800$ respectively. That makes A correct. Choice B is tempting but wrong — it assumes the Top N filter recalculates within East, which would only happen if Region were added to context first, promoting it above the Top N filter in execution order. Choice C confuses how filters work: the Region filter absolutely affects aggregated values (Alpha drops from $1000$ to $100$), it just doesn't re-rank which products qualify. Choice D invents a behavior where products are re-evaluated after both filters run — Tableau doesn't retroactively swap out set members based on post-filter rankings. Study tip: Anytime a question involves Top N filters plus a dimension filter, ask yourself: Is that dimension in context? If not, the Top N always evaluates globally first, and you'll see unexpected products paired with surprisingly low values.
9. Which customers remain after the filter is applied?
   Answer: Only Customer A remains because all records underlying that mark have the Consumer value. When you see ATTR() in Tableau, think of it as a strict unanimity check. ATTR([Segment]) evaluates all the underlying row-level values for a given mark and returns the value only if every single row agrees. If there's any disagreement, it returns an asterisk (*). This is the key concept being tested here. With that framework, walk through each customer. Customer A has two Consumer records — unanimous, so ATTR([Segment]) returns "Consumer". Customer B has one Consumer and one Corporate record — disagreement, so it returns *. Customer C has two Corporate records — unanimous, so it returns "Corporate". The filter ATTR([Segment]) = "Consumer" then keeps only marks where the result is exactly "Consumer". That's Customer A alone, making C the correct answer. Answer A is wrong because it misidentifies Customer B as the one that "remains" — in reality, mixed values cause ATTR to return *, which fails the filter, so Customer B is excluded, not kept. Answer B is wrong because it assumes ATTR behaves like a CONTAINS or OR check — it doesn't. Having at least one Consumer record is not enough; all records must match. Answer D is entirely fabricated — ATTR has no concept of "last value encountered." It is not a sequential or row-order function. A useful memory device: think of ATTR as "all-or-nothing." If all rows say the same thing, you get that value. If even one row disagrees, you get *. Whenever you see ATTR in a filter question, immediately ask yourself whether every row under that mark is unanimous.
10. What values appear for the customers that remain visible?
    Answer: Customer X displays $400$, and Customer Y displays $200$. Whenever you see a FIXED LOD expression on a Tableau exam, ask yourself one critical question: what level of granularity does this calculation lock onto, and does the active filter respect that lock? FIXED LOD expressions compute before standard dimension filters are applied. That means { FIXED [Customer] : SUM([Sales]) } sums all sales per customer across every region — East, West, or otherwise — before the Region filter ever runs. The filter then removes rows from the view, but the FIXED value is already baked in. For Customer X: $100 + 300 = 400$. For Customer Y: $200 + 0 = 200$. The Region = East filter hides the West row for Customer X from the view, but since FIXED already computed $400$, that's what appears. Customer Y has only East data, so they remain visible with $200$. This confirms B is correct. A is wrong because it reflects what you'd see if the calculation were a regular SUM([Sales]) aggregation — that would respect the filter and show only East sales ($100$ for X, $200$ for Y). The trap here is confusing FIXED with a normal aggregate. C is wrong on both counts: Customer X's FIXED value is $400$, not $300$, and Customer Y isn't removed — they have East sales, so they remain visible. D is wrong because Customer Y has no West sales, so there's nothing extra to add; $200$ is the correct FIXED value, not $300$. Your study tip: memorize the filter order of operations — Context → FIXED → Standard Dimension Filters → INCLUDE/EXCLUDE → Table Calcs. FIXED sitting above standard filters is one of Tableau's most tested concepts.

Start this quiz