Design Approximate Numbers Honestly

Data & Dashboards · metrics, dashboards, trust

Updated 2026-08-04

Know which numbers on the screen are estimates. Counting unique visitors, unique terms, or trending items exactly is expensive at scale, so cardinality is usually estimated with a structure such as HyperLogLog and carries a small error.
Format an estimate so it does not read as exact. 1,247,853 unique visitors invites arithmetic the number cannot support, and About 1.25M sets the right expectation with the same information.
State the error where the decision depends on it. A few percent is invisible in a traffic chart and unacceptable in an invoice.
Never use an approximate number in a place that must reconcile:

Explain why two numbers disagree, because someone will notice. The same metric estimated in a dashboard and counted exactly in an export will not match, and without a note that reads as a bug.
Keep the estimate stable across refreshes. A count that jitters by thousands between two views of the same period destroys confidence even when both values are within tolerance.
Say when small numbers are exact. Most systems count precisely below a threshold and estimate above it, and telling the user where that line is answers most of their questions at once.
Offer an exact count on request where it is possible. Calculate exact total as an explicit, slower action is better than either silently estimating or making everyone wait.

An estimate presented as an exact figure is a small lie that costs a large amount of trust the first time someone checks it.