Field note · June 20, 2025

Charting revenue_usd by variant

Two facts about the columns decide the chart. Cardinality and skew, in that order.

2 min read ·Visualization ·visualization

Someone wants revenue_usd broken down by variant on ab-test-checkout. Before choosing a chart, two facts decide it.

variant has 3 values, which fits comfortably. revenue_usd has a mean of 6.92 against a median of 0.00 — near enough symmetric that an average is representative.

So: a horizontal bar chart, sorted by value rather than alphabetically. Alphabetical ordering is the default in most libraries and it is almost always the wrong one; sorting is the analysis.

A bar of averages is honest here, which is worth checking rather than assuming.

One y-axis. Colour by variant rather than by rank, so filtering a category does not repaint the others. And a table underneath, because someone will want the exact number and squinting at a bar is not a way to get it.

The thing to decide before any of that: what the chart is for. If the question is "which group is largest", a sorted bar answers it and a pie chart does not — angle is the hardest visual encoding to compare and the one most often reached for. If the question is "how much do groups differ", the bars need to start at zero or the difference is whatever the axis says it is. And if the question is "what does the distribution look like inside each group", bars are the wrong family entirely; that is a box plot or a strip plot, and no amount of styling turns one into the other.

With a roughly symmetric column, the mean-of-each-group bar chart is genuinely the right default. Most of the failures in this shape come from skew, and this column does not have much.

The chart builder enforces the mechanical parts — axis, palette, series cap, table view — which was the point of building it. It cannot enforce the first decision, which is the one that matters. Rules that live in a style guide are rules nobody follows at 6pm; rules in code are the ones that survive.