In Tableau, how does TOTAL(COUNTD([Customer])) differ from WINDOW_SUM(COUNTD([Customer]))?

## Both are table calculations `TOTAL` and `WINDOW_SUM` are both table calculation functions: they run in Tableau after the query returns, over a partition of the aggregated result. Neither can see data that the view's filters removed, and both are affected by addressing and partitioning settings. What separates them is *what they aggregate*. ## WINDOW_SUM adds the marks `WINDOW_SUM(expr)` takes the value of `expr` as already computed for each mark in the window and adds those values together. With `SUM([Sales])` inside, that is exactly right: sales are additive, so adding monthly totals produces the yearly total. With `COUNTD([Customer])` inside, it is arithmetic on the wrong inputs. Each mark's value is the number of distinct customers *in that mark*. Adding twelve monthly distinct counts produces the number of customer-months with activity, not the number of distinct customers in the year. A loyal customer who buys every month contributes twelve. The result is always greater than or equal to the true distinct count, and it looks entirely plausible. ## TOTAL re-aggregates the partition `TOTAL(expr)` re-applies the aggregation in `expr` to the underlying rows of the whole partition rather than combining the mark-level results. With `COUNTD([Customer])` that means the distinct count is computed once across the partition, so each customer counts once no matter how many marks they appear in. The same distinction shows up with averages. `WINDOW_AVG(AVG([Score]))` averages the per-mark averages, giving every mark equal weight regardless of how many rows sit under it. `TOTAL(AVG([Score]))` averages the partition's underlying rows, weighting by row count. Neither is wrong in general; they answer different questions, and the one you get by accident is rarely the one you meant. ## Where they agree For additive aggregations — SUM, and COUNT in most situations — combining mark-level results and re-aggregating the rows give the same answer. That agreement is why the distinction is a differentiator question rather than a daily concern: most dashboards use SUM, the two functions match, and people conclude they are interchangeable. They are not, and the first non-additive measure exposes it. The useful shorthand: aggregations that survive being combined are safe with WINDOW functions; aggregations that require seeing the raw rows — distinct counts, averages, medians, percentiles — need TOTAL, or a different tool entirely. ## The level of detail alternative A table calculation can only work with what the view returned. When you need a de-duplicated count at a grain the view does not display, or a number that should not shift as the shelves change, use a level of detail expression instead: `{FIXED [Region] : COUNTD([Customer])}` is computed by the data source at region grain and does not depend on the table's shape. The trade-off is the usual one — LOD expressions are computed pre-filter for FIXED and add work to the generated query, while table calculations are free but myopic. ## Verify before you publish This is a family of bugs that produces confident, wrong numbers rather than errors. Before shipping a distinct-count total, check it against a figure you can confirm independently: a small filtered subset, a direct query against the source, or a crosstab exported and counted. The habit costs a few minutes and catches a class of defect that otherwise survives to the board deck. ## What interviewers listen for They want the crisp distinction — combining mark values versus re-aggregating the rows — and the recognition that it only matters for non-additive aggregations. A strong answer names distinct counts, averages and medians as the cases at risk, offers the level of detail alternative when the required grain is not in the view, and admits that the safe move is to verify against a known number rather than trust the function name.