A rule applied across analytics: dwell tooltips say 'Based on 45 leads that left this stage'; the days-off-plan tooltip says '+1.8d on 5d plan · n=7'; leaderboard tooltips say 'across 9 quotes'; the stage analytics API attaches a denominator to every aggregate it returns; and crew tables render completed-over-started as '12/17'.
Also called: sample size · how many jobs is this based on · n= · is this average meaningful
- 1Every metric computed server-side carries a parallel sample count in the payload.
- 2Tooltips render the count as a Stat row or a footer line.
- 3Panels whose ranking could mislead carry an (i) warning to read the run count first.
The stage-analytics route states the principle: 'Every aggregate reports its own denominator (n). A crew average over two stages is not the same claim as one over forty, and a leaderboard that hides that invites exactly the wrong decision.' The crews panel's (i) repeats it: 'Read the run count first — a crew with two stages behind it is an anecdote, not a trend.'
- Rankings built on tiny samples drove wrong decisions about people.
- A confident-looking average concealed how thin its evidence was.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →