Lakshya

Analytics & BI Tools · Chapter 3 of 18

Tableau, in practice

The strongest visual analysis tool, and the one whose cost model surprises people.

4 min read0 diagramsAll 18 chapters

Tableau's differentiator has always been exploratory visual analysis — the experience of dragging fields and seeing the shape of the data immediately. If your users are genuine analysts who think visually, it is still the best in class at that.

What it genuinely does well

  • Exploratory analysis. The interaction model is designed for asking the next question, not for building a fixed report. Nothing else feels quite the same.
  • Visualisation quality and control. More chart types, finer control, better defaults for perceptual accuracy.
  • Analyst community and craft. A large body of practice and a genuine culture around visual design.
  • Cross-platform — less tied to one vendor's ecosystem than Power BI.

Where it hurts

Cost. Per-creator licensing is materially more expensive than Power BI, and the gap widens with scale. This is the single most common reason organisations move away, and it is rarely a capability judgement.

Governance and semantic modelling are weaker. Extracts and workbook-level calculations make it easy for every workbook to define metrics differently — the exact failure from chapter 1.

Extracts drift. The performance answer is usually an extract, which is a copy with a refresh schedule and therefore a staleness and storage problem.

Enterprise deployment is heavier than the sales conversation implies, particularly around permissions at scale.

When Tableau is the right answer

When your users are analysts doing genuine exploration rather than consuming fixed dashboards, when visual quality matters to the audience, and when you have the budget and a governance plan for the semantic layer.

When it is not: a large population of casual consumers reading fixed reports. That is expensive in Tableau and cheap almost everywhere else.

The order of operations, which explains every surprising number

Almost every ‘why is this number wrong?’ question in this tool is answered by the order in which filters and calculations are applied. The order is fixed, documented, and almost never taught — which is why so many analysts learn it by trial and error.

StageWhat happensWhat it means in practice
1. Extract and data-source filtersApplied before anything elseThe cheapest place to filter, and invisible to everything downstream
2. Context filtersCreate a temporary subset that later steps operate onThis is what makes a top-N filter work with another filter. Without context, the top N is computed against the whole set
3. Fixed-level expressionsComputed at a stated grain, ignoring the visual's dimensionsWhere percentage-of-total and cohort calculations live
4. Dimension filtersThe ordinary filters most people useApplied after fixed expressions, which is why a fixed calculation does not change when you filter
5. Include/exclude expressionsComputed relative to the visual's grainUseful for average-of-an-aggregate, and the source of much confusion
6. Measure filtersFilter on aggregated valuesThis is why filtering on a measure behaves unlike filtering on a dimension
7. Table calculationsComputed on the result set already returnedThey cannot see filtered-out data, which is why a running total changes when you filter

The two rules that resolve most confusion: a fixed-level expression is computed before ordinary dimension filters, so filtering does not change it — which is either exactly what you wanted or exactly your bug. And a table calculation is computed after everything, on the rows that survived — so it is a presentation-layer operation and can never recover data a filter removed.

The practical diagnostic: if a number changes when you filter and you did not expect it to, you are probably using a table calculation where you wanted a fixed expression. If a number stubbornly refuses to change when you filter, you are using a fixed expression where you wanted a table calculation, or you need a context filter.

Check yourself

Why does a top-N filter give the wrong answer alongside another filter?Because the top N is computed against the whole set unless the other filter is promoted to a context filter, which runs earlier.
Why doesn't a fixed-level expression change when I filter?It is computed before ordinary dimension filters. That is either what you wanted or exactly your bug.
Why does a running total change when I filter?Table calculations run last, on the rows that survived. They cannot see data a filter removed.
A number won't change when you filter. What is the likely cause?A fixed expression where you wanted a table calculation, or a filter that needs promoting to context.
← Power BI, in practiceLooker, and the semantic-layer approach →