A complete guide to Tableau Level of Detail expressions — when to use FIXED vs INCLUDE vs EXCLUDE, how LODs interact with filters, common use cases (cohort analysis, running totals, percent of total), and the pitfalls that break calculations silently.
Level of Detail (LOD) expressions are the feature that separates Tableau users who can answer any analytical question from Tableau users who hit a wall. Standard aggregations in Tableau compute at the view's level of detail — whatever dimensions are in the view determine the granularity. LOD expressions let you control the level of detail independently of the view, computing aggregations at a different granularity and bringing the result back to the view level.
When you understand LOD expressions, analyses that were previously impossible or required separate data preparation become straightforward. When you do not, you spend hours building workarounds that break on edge cases.
The Core Concept
In standard Tableau, SUM([Revenue]) computes the sum of revenue at whatever granularity the view specifies. If the view shows by Region and Product Category, SUM([Revenue]) gives revenue by Region+Category. If you add State to the view, it recomputes at Region+Category+State.
LOD expressions break this constraint. They let you specify the level of detail explicitly:
**FIXED**: compute at the specified level, regardless of the view
**INCLUDE**: compute at the view level plus additional specified dimensions
**EXCLUDE**: compute at the view level minus specified dimensions
Each solves a different class of analytical problem.
FIXED LOD: Compute at a Specified Level
FIXED computes an aggregation at exactly the dimensions you specify, ignoring the view's dimensions. The syntax is:
{FIXED [Dimension1], [Dimension2] : AGG([Measure])}
**Classic use case: customer-level metrics in an order-level view.** Suppose you want to show, for each order, the customer's total lifetime value. The view is at order granularity. Customer lifetime value is a customer-level metric. Without LOD, you cannot compute this in Tableau without a separate data source join.
With FIXED:
{FIXED [Customer ID] : SUM([Revenue])}
This computes total revenue per customer, then joins the result back to each order row for that customer. You can now show "this order's revenue" alongside "this customer's lifetime value" in the same view.
**Use case: first purchase date.** Cohort analysis requires knowing when each customer first purchased. The first purchase date is a customer-level attribute.
{FIXED [Customer ID] : MIN([Order Date])}
**Use case: percent of total.** Showing each region's percentage of total company revenue requires the total at a different level than the view.
SUM([Revenue]) / {FIXED : SUM([Revenue])}
FIXED with no dimensions computes at the entire dataset level — the grand total.
**FIXED and filters.** Here is where LOD expressions require careful attention. FIXED LOD expressions are computed before dimension filters are applied, but after context filters (those set to "Use as Context Filter"). This means:
- Dimension filters on the view do NOT affect FIXED LOD calculations
- To make a FIXED LOD respect a filter, add that filter to context
This is the source of most LOD calculation bugs. A FIXED customer LTV showing a customer's all-time LTV even when the view is filtered to a specific date range is not a bug in Tableau — it is FIXED behaving correctly. If you want the LTV restricted to the filtered date range, use FIXED with the date dimension included, or use INCLUDE.
INCLUDE LOD: Add Dimensions to the View Level
INCLUDE computes at the view's current level of detail plus additional dimensions you specify. The result is then aggregated back to the view level.
Use case: average transaction value at a customer level, displayed by region.
Without LOD, AVG([Revenue]) at Region level computes the average revenue per row at region level — not the average customer transaction. With INCLUDE:
AVG({INCLUDE [Customer ID] : AVG([Revenue])})
This first computes average revenue per customer (per Customer ID), then takes the average of those customer averages at the view level. This is the average of averages, which gives a different and often more meaningful result than the flat average.
Use case: standard deviation of daily sales, in a view showing by month.
AVG({INCLUDE [Order Date] : SUM([Revenue])})
This computes daily revenue total (at the day level), then averages those daily totals at the month level. This is the average daily revenue for each month — correct for many analytical comparisons that a flat average would compute incorrectly.
INCLUDE LOD expressions respect dimension filters — because they compute at or below the view level, they are not subject to the filter-order issue that affects FIXED.
EXCLUDE LOD: Remove Dimensions from the View Level
EXCLUDE removes specified dimensions from the view's level of detail for the calculation. It computes at a coarser level than the view and brings the result back.
Use case: regional comparison line in a state-level chart.
A view showing sales by State. You want a reference value showing each state's region average, so you can see whether each state is above or below its regional average.
{EXCLUDE [State] : AVG([Revenue])}
This computes average revenue at Region level (excluding State from the calculation) while the view still shows at State level. Each state row now carries its region's average — perfect for a reference line or a comparison calculated field.
EXCLUDE is less commonly used than FIXED and INCLUDE, but it solves the "show a contextual benchmark at a coarser level" pattern cleanly.
LOD Expressions and Filters: The Complete Order of Operations
Understanding when LODs are computed relative to filters is critical:
1. **Extract filters** (applied to extract data sources)
2. **Data source filters**
3. **Context filters** (dimension filters set to Use as Context Filter)
4. **FIXED LOD expressions** — computed here
5. **Dimension filters**
6. **INCLUDE and EXCLUDE LOD expressions** — computed here
7. **Measure filters** (filters on aggregated measures)
This order means:
- FIXED is affected by context filters and data source filters, but NOT by dimension filters
- INCLUDE and EXCLUDE are affected by all filters above them, including dimension filters
The practical implication: if your FIXED calculation needs to respect a date filter, either include the date dimension in the FIXED expression, or add the date filter to context.
Common Use Cases
**Cohort analysis.** Cohort analysis requires computing metrics for customers defined by a condition at one point in time (first purchase month) and measuring their behaviour across subsequent time periods. FIXED LOD expressions make this tractable in Tableau without pre-building cohort tables in the database:
{FIXED [Customer ID] : MIN(DATETRUNC('month', [Order Date]))}
This gives each customer a cohort (their first purchase month). You can then use this calculated field as a dimension in the view, creating a cohort × time period matrix.
**Running totals.** FIXED LOD can compute running totals partitioned by a dimension — useful when the running total should restart at a specific boundary (fiscal year, product category).
**Ratios against benchmarks.** Any ratio calculation where numerator and denominator are at different levels of detail (revenue vs region total, this product vs category total) requires LOD expressions.
**Deduplication in aggregation.** If your data has duplicate rows and you want to count distinct customers who performed an action, FIXED LOD is often the cleanest approach.
Performance Considerations
LOD expressions execute as subqueries against the data source. Complex LOD expressions in large extracts or against large database tables can be slow. Some guidance:
- FIXED LOD expressions on large datasets can be expensive because they compute across the full dataset (before dimension filters). Use data source filters or context filters to restrict the scope.
- Multiple LOD expressions in a single calculation compound cost. Where possible, compute the LOD once and reference it in downstream calculations.
- For live connections to databases, LOD expressions generate complex SQL with subqueries. Test query performance against the database directly if LOD calculations are slow.
For complex Tableau analytics design including LOD expression architecture and dashboard performance optimisation, our Tableau consulting team builds production analytical environments — contact us to discuss your Tableau development requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →