Tableau / Basic: fields, models and views / Lesson 4

Marks, granularity and aggregation

Explain how dimensions and aggregations define a worksheet’s marks, counts and totals before adding visual detail.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Trace view detail through shelves and the Marks card.
Distinguish row count, distinct count and aggregate amounts.
Interpret ATTR and nonadditive totals.

Define one mark

A mark represents an analytical grouping, not necessarily one source row. With Product in the view and SUM(Sales), the fixture can show Tea 42 and Coffee 18. Adding Region to Detail or Color can split Tea into North 12 and South 30, increasing marks without creating sales. Fields outside Rows and Columns can affect view detail too. Before diagnosing duplication, name every dimension defining one mark and compare underlying fact identities. The same source can legitimately support several mark counts while overall sales remains 60.

Choose count and amount semantics

SUM(Sales) adds line amounts; COUNTD(Order ID) counts distinct orders within the current grouping. O1 appears in Tea and Coffee, so product-level distinct counts can sum to three while the grand distinct count is two. The first snippet shows separate calculated-field expressions, not one complete script. Do not force the total to sum visible counts unless that overlapping-membership question is intended. A displayed total can be reevaluated at broader detail rather than reconstructed by adding marks. Explain that behavior before calling the difference an error.

tableau Unexecuted aggregation expressions

// Separate calculated fields
SUM([Sales])

COUNTD([Order ID])

ATTR([Region])

These need a source and view context. SUM is 60 and grand COUNTD is 2 for the fixture; ATTR depends on regions within each mark.

Read attribute ambiguity

ATTR can display a value when relevant values within a mark agree and an asterisk when multiple values occur. The asterisk signals aggregation ambiguity, not permission to choose the first value. Tea spans North and South, while Coffee has North only. If the question needs one region per mark, add that grouping; if it needs one product mark, explain the multiple regions honestly. Do not relabel the asterisk as missing without checking contributing rows. Null and multi-value semantics deserve separate cases.

Use a distinct-count oracle

The second program groups order identities by product and compares the sum of product distinct counts with the overall count. It exposes overlapping membership without Tableau. This is not an engine-total test; other calculations and total settings need their own interpretation. Keep entity and grouping visible in names: orders per product differs from total unique orders. For ratios and averages, decide whether the total uses underlying observations or equally weighted marks before choosing aggregation. A correct-looking number cannot explain this weighting automatically.

python Synthetic overlapping distinct counts

rows = [("O1", "Tea"), ("O1", "Coffee"), ("O2", "Tea")]
by_product = {product: {order for order, item in rows if item == product} for _, product in rows}
print(sum(len(orders) for orders in by_product.values()))
print(len({order for order, _ in rows}))

Expected output

3
2

3 counts product memberships;2 counts unique orders. No worksheet or source is accessed.

Review detail before formatting

Test no dimensions, Product, Product plus Region and an intentional null case. Record expected marks, sales, distinct orders and attribute meaning. A label or color field becomes a context change when it alters detail, not always decoration. This course executes only set counts; Tableau aggregation, ATTR and totals remain unexecuted. An authorized review should inspect actual configuration and rows, separating correct arithmetic from reader understanding. Formatting cannot repair mistaken grouping or an undefined entity-count contract, and one matching total does not validate every level of detail.

Common errors and fixes

Each mark is assumed to be one fact row

Why it happens: Dimensions and aggregation were not traced.
How to fix it: Define one mark using every contributing shelf and Marks field.
Prevent it next time: Compare mark and fact counts separately.

Distinct totals are forced to sum product rows

Why it happens: Overlapping order membership was ignored.
How to fix it: Use the documented entity population at total detail.
Prevent it next time: Test an order appearing in two products.

ATTR asterisk becomes an arbitrary region

Why it happens: Multiple values were mistaken for a missing lookup.
How to fix it: Inspect regions and choose honest grouping or labeling.
Prevent it next time: Review single, multiple and null cases separately.

Check your understanding

1. Why can product order counts 2 and 1 coexist with grand distinct 2?

Show worked solution

O1 belongs to both products and is counted twice when memberships are added. The grand count asks for unique orders across the population. This is meaningful nonadditivity, not necessarily a defect. Label entity and grouping so readers do not add overlapping counts and infer three different orders.

2. Tea shows an ATTR region asterisk. What two designs are legitimate?