Tableau LOD (Level of Detail) expressions allow you to compute aggregations at a different granularity than the view — letting you answer questions like "what was each customer's first purchase date" or "what is the cohort average" without changing the dashboard's detail level.
Tableau LOD (Level of Detail) expressions are calculated fields that compute aggregations at a specified granularity — independently of the granularity at which the current view is displayed. They solve a class of analytical problems that would otherwise require data preparation outside of Tableau: questions where you need to compute something at one level of detail but display it at another.
Before LOD expressions were introduced in Tableau 9.0, these calculations required either pre-aggregating data in the source, writing complex table calculations that depended on view-level configuration, or exporting and manipulating data in SQL. LOD expressions brought a class of analytical capability directly into Tableau's calculation language.
The Three LOD Types
### FIXED
FIXED computes a value at a specific level of detail, regardless of what dimensions are in the view. The result is anchored to the dimensions you specify — context filters aside, it is not affected by what the view shows.
Example: to compute each customer's total lifetime revenue, regardless of whether the view is showing individual orders or product-level detail:
FIXED [Customer ID] : SUM([Revenue])
This returns the sum of revenue for each Customer ID across all orders, at every row, regardless of what else is in the view. If the view shows individual order rows, each row for Customer A shows the same value: that customer's total lifetime revenue.
FIXED is the most commonly used and most powerful LOD type. It anchors the computation to specified dimensions and is not diluted by context changes.
### INCLUDE
INCLUDE adds dimensions to the view's current level of detail for the computation, then aggregates the result up to the view level.
Example: to compute the average order value per customer in a view that only shows customer segments (where individual customer detail is not visible):
INCLUDE [Customer ID] : AVG([Revenue])
This computes average revenue per Customer ID, then — because the view dimension is Customer Segment — averages those per-customer averages up to the segment level. The result is the average customer's average order value within each segment.
INCLUDE is used when you need a computation that respects a finer-grained dimension than the view currently shows — for cohort metrics, averaging of averages, and similar constructions.
### EXCLUDE
EXCLUDE removes dimensions from the view's level of detail for the computation.
Example: in a view showing revenue by product category and region, to show what percentage of total revenue each category-region combination represents, you need the denominator to be the total for the category across all regions. EXCLUDE removes the region dimension:
SUM([Revenue]) / EXCLUDE [Region] : SUM([Revenue])
This divides each category-region revenue by the total revenue for that category across all regions — rather than dividing by the grand total, which would give a less useful percentage.
EXCLUDE is less commonly used than FIXED but is the right tool for ratio calculations where a subset of view dimensions should be removed from the denominator.
When to Use LOD Expressions
LOD expressions are appropriate when you need to:
**Compute a per-entity aggregate displayed at a higher grain.** "Average customer order frequency" computed at the customer level, displayed in a view aggregated by product category. "Median deal size" computed per deal, displayed in a view aggregated by sales rep. These require computing at a finer grain than the view displays.
**Find first or last events per entity.** "Each customer's first purchase date" requires MIN([Order Date]) per Customer ID — a FIXED calculation that labels each row with the customer's earliest order date, which can then be used in cohort analysis.
**Compute cohort or baseline values.** "What was the baseline revenue for customers acquired in Q1?" requires a FIXED calculation that labels each customer with their acquisition cohort, independent of the current view's date filtering.
**Build ratio calculations with mixed granularity.** "Each region's revenue as a percentage of country total" requires the country-level total (EXCLUDE region) as a denominator while preserving the region dimension for the numerator.
LOD Expressions vs. Table Calculations
Tableau also has table calculations — functions like RUNNING_SUM(), WINDOW_AVG(), LOOKUP() — that operate on the results of the query as already aggregated by the view. Table calculations are computed in Tableau after the data is retrieved; LOD expressions are computed in the SQL query sent to the database.
This distinction matters:
- LOD expressions can be filtered with dimension filters; table calculations are affected by the filtering only if you add them to context
- LOD expressions can be used in conditional logic and other calculated fields; table calculations are more restricted in how they can be composed
- LOD expressions require the database to do additional computation; for very large datasets, this can affect query performance
When should you use table calculations instead of LOD expressions? When the calculation depends on the visual layout of the view — running totals, ranking, percent of total across what is displayed — table calculations are the right tool because they are aware of the visual structure. LOD expressions are the right tool when the calculation is data-level, not view-level.
Performance Considerations
LOD expressions add subqueries to the SQL Tableau generates. FIXED LOD expressions are evaluated as a join between the main query and a subquery at the specified grain. For data sources with good query optimization and indexed join keys, performance impact is minimal. For large tables or complex multi-LOD calculations, query time can increase significantly.
Practical guidance:
- Extract-based data sources (Hyper extracts) handle LOD calculations very efficiently; live connections to transactional databases may perform less well
- Multiple nested LOD expressions compound query complexity; if performance is an issue, evaluate whether pre-aggregating in the data source or dbt model can replace the LOD
- FIXED LODs on high-cardinality dimensions (many distinct values) produce large intermediate results and can slow query execution
Our Tableau consulting practice implements complex Tableau calculations — including LOD expressions for cohort analysis, customer segmentation, and performance ratio metrics — for analytics environments that need analytical depth without data model complexity. 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 →