How task success rate is calculated
Take the number of people who completed the task and divide it by the number who attempted it. The arithmetic is trivial; the definition is where all the work sits. “Find the price” has to become something a note-taker can mark without arguing — the participant states the correct price, or reaches the pricing page and reads the figure aloud, or does not.
Most teams score it as pass or fail, which is blunt but honest. Some add a partial category for people who got there by an unintended route, or who eventually succeeded after asking for help. Partial scoring is more informative, but only if the rule is written down before testing starts, otherwise it becomes a way of promoting failures into successes after the fact.
The measure can also be taken from live traffic rather than a test session, by defining the task as a sequence of events and reading completions against entries in a funnel report. That gives volume but no explanation, so the two approaches usually run together.
Why task success rate matters
It is the plainest evidence a site works. Nobody has to interpret it, argue about design taste or understand analytics to grasp that most people asked to book an appointment could not manage it. That makes it unusually persuasive when you need a budget for fixes, and unusually hard for anyone to explain away.
It also covers ground conversion rate misses. Plenty of important journeys have no commercial event at the end: checking whether you deliver to a district, finding an opening time, downloading a specification. Those tasks decide whether a visitor trusts you enough to come back, and they are invisible in a conversion report.
Where task success rate goes wrong
Vague tasks produce meaningless scores. “Explore the site” cannot be passed or failed. So can tasks that hand over the answer: telling someone to click the enquiry button and then recording that they clicked it tests nothing.
Over-reading small samples is the second problem. A moderated round involves a handful of people, so the result is a signal about where the walls are, not a statistic you should quote to the third decimal. Reporting it as a precise figure gives it an authority it has not earned, and invites comparison between rounds that were not run the same way.
The third is scoring generously. If the participant found the price only after the moderator pointed at the menu, that is a fail, and recording it as anything else defeats the purpose of testing.
How to act on it
Write the task and the success rule together, before recruiting anyone, and keep both stable so later rounds are comparable. Use realistic goals phrased in the customer’s language rather than instructions that name your buttons.
Read it beside time on task and beside what you observed. A task that everyone completes slowly and with visible irritation is not fixed, it is merely survivable, and the pattern usually shows up later as complaints or abandoned enquiries. Then act on the failures rather than the score: fix the specific wall people hit, run the same tasks again, and check whether the live funnel moved in the same direction. That loop is the useful part of conversion rate optimisation.