Show What Your Traction Actually Measures

A slide that says "120 customers activated" is rarely a lie. More often it is a number nobody defined wearing a label that sounded better than what was recorded. And the label tends to get chosen last, once the deck is nearly finished and the headline still needs a verb.

Reverse that order. Before you write a headline or pick a chart, settle four things in ordinary language:

• Unit. What is being counted — people, accounts, tasks, sessions, transactions, or event rows.
• Qualifying event. What has to happen for a record to enter the count, including where the event begins and where it ends.
• Period. A cumulative total through a date, or activity inside an interval.
• Denominator, if the number is a rate. Who was eligible, and for what.

Then ask what the resulting measurement can honestly support. That question is usually the one that rewrites the slide.

Decide which business question the number answers

Interest, activation, task completion, repeat use, and a transaction actually recorded are five different questions with five different records behind them. Which one the slide is about comes before how the slide looks.

"Twelve thousand signups" answers a real question — has anyone shown interest? — and it is a complete answer to that question. It is not an answer to "does the product work for people?" A signup marks one moment: an address entered, a form submitted. If the slide is about whether the product does something for someone, signups are context, not evidence.

The pull toward the largest available total is understandable. Large numbers are easy to verify and easy to repeat. But size and relevance are different properties, and a quantity can be perfectly accurate while answering a question the slide never asked. The usual failure in a traction deck is not invention. It is substitution — a true number standing in for a claim it does not cover.

So read the headline and name the event it implies. People are interested. People finish onboarding. People come back. People pay. Each implies a specific record, and you either have it or you do not.

Adjacency is where labels slip. A click on a purchase button is a product event. Revenue is an accounting fact, recognized under the applicable accounting rules, which may be before or after money moves, and it carries refunds, chargebacks, taxes and timing that a click never sees. If the slide says revenue, the figure has to come from the system that records money. Two smaller distinctions matter as much. A completed task is not a lasting outcome: someone who finishes setup this week may have abandoned the product by next month, and the completion count cannot tell you which happened. And an interface action is not a transaction, however deliberately the user pressed the button.

Specify the unit and qualifying event

Start with the unit, because "users" is almost always a compression of something more specific. Users who did what? Accounts that exist? People who reached a particular screen? Rows an event fired?

Here is an invented fixture, small enough to check by hand. It contains no company data and no observed customer behavior.

• 100 valid task starts. These are the eligible tasks.
• 80 distinct tasks completed by a common observation cutoff.
• 50 distinct people performed those completions.
• 120 recorded completion event rows in the export, because 40 of them are repeats attached to tasks already counted among the 80.

Three quantities, three units, one export. The gap between 80 and 120 is 40 repeat rows. The gap between 50 and 80 is the 30 extra task completions recorded for people who completed more than one task. Nothing is wrong with the export. It records rows, and a row is not a person.

Now try the headline "120 customers activated." It goes wrong twice. The unit has changed — 120 counts completion event rows, not people. And the qualifying behavior has changed — a row saying a task was marked complete is not an activation, which is a term you would have to define separately, probably around something a person chose to do more than once.

The same export supports a smaller, checkable sentence: 80 of 100 eligible tasks were completed by the observation cutoff. Every word of that is doing work, including the words that sound like throat-clearing.

"Valid" implies some starts were not valid. In your own deck you have to say which and why — internal accounts, test traffic, automated requests, a double submission — because a stated exclusion is part of the definition, while an unstated one is a number nobody else can reproduce.

"Completed" implies a boundary. A task might be complete when the final screen is submitted, when a confirmation appears, or when a downstream system acknowledges the work. Those can be three different counts on the same afternoon. "Started" is just as slippery: the first screen loading, or a record being created. Each is a defensible definition. None is the default, and all of them move the number.

Make the period and denominator travel together

There are two ways to be vague about time. A cumulative total through a date counts everything since launch: 2,400 tasks completed to date. A period figure counts only what happened inside an interval: 310 tasks completed in March. Both can be true on the same afternoon, and a slide can move between them without ever changing the word "completed."

Growth percentages hide the same seam. Up 40% is a claim about two baselines, so a changed definition of completion — or a second product surface starting to report into the same event — turns the comparison into two measurements wearing one label. A missing or shifting baseline should stay visible rather than disappear into a percentage point.

For any rate, the denominator has to be the population that could have completed. In the fixture, that population is the 100 valid starts: 80 ÷ 100 = 0.80, so 80% of eligible tasks were completed by the cutoff.

Notice what the sentence does not say. It does not say that 80% of users activated. It cannot, because the fixture never establishes how many distinct people started a task. Fifty people completed something; the number who tried is not in this export. A rate is only as meaningful as the population it was divided by, and reusing a task denominator for a claim about people is a unit error dressed up as a percentage.

The cutoff is doing work too. "80 of 100" is 80% by that observation date. Extend the date and the numerator can grow — but it should grow by linking later completions back to the starts they belong to, not by dividing one month's completions by a different month's starts. That linking is what the Government Digital Service's guidance on measuring completion rate describes, in a government-service setting: define where a transaction starts, know when the service ends, and count users who save and return rather than treating a return as a fresh attempt. It is a bounded example of a general point, not a startup benchmark and not an analytics implementation to copy. The page speaks to UK digital services and carries a February 2021 update date, and no company instrumentation was examined for this article. What transfers is the shape of the discipline: a rate means something only after its start, its ending, and its exclusions have been named.

One caution before moving on. A common cutoff gives every task the same observation date, not the same amount of time. Tasks started in the fixture's first week had longer to finish than tasks started the day before the cutoff, so a single 80% blends generous windows and tight ones. That problem has its own remedy — comparing groups at compatible ages — and it comes after the definitions are settled, not instead of them.

Reconcile repeats before designing the slide

The fixture's 120 rows against its 80 tasks need an explanation before anything gets charted. The stipulated reason is narrow: 40 extra rows are attached to tasks already represented among the 80.

In a real export, the mechanism behind extra rows is worth finding, because different causes deserve different handling. A completion event might fire each time a finished task is reopened. A retry after an error might log two attempts. A resumed session might re-emit a completion. A backfill might add historical rows from another system, and a duplicated instrument across two environments can double everything quietly for weeks.

Do not assume the analytics tool has already dealt with this. Some products deduplicate by default, some do not, defaults change between versions, and a dashboard someone else built may carry a filter you have never seen. What matters for the slide is the rule you can state. One completion per task, earliest recorded is a rule. Every completion row is a different rule, and it answers a different question — how often completion happens, not how many tasks were completed. Either can be right. Leaving it unstated is what makes the number unusable.

Two more things belong in the definition, because they change what the number can establish.

Internal activity: employee accounts, test accounts, demo environments, bot traffic. Whether you exclude them is your call; whether they were excluded is a fact you should be able to state.

Coverage: a completion recorded only while a user is signed in will miss completions that happen signed out or through an integration. A new instrument switched on in March makes March and February non-comparable, and it makes February incomplete rather than empty. Incomplete is the word that matters — missing observations are not measured non-use. If the export cannot see a behavior, the rate you compute is a rate among the visible, and the slide should say so in a few words rather than a paragraph.

Only now does display become a question. A single large number forces 50, 80 and 120 into one figure, and whichever you pick inherits the units of the others in the reader's mind. Two workable options: show the quantity that answers the stated question and move the rest into a line of text with their units attached, or show the two or three figures that genuinely matter as separate quantities. What a chart must not do is reunite what the definition took apart.

The sentence the slide has to survive

Once the definitions are settled, everything compresses into one sentence a skeptical reader could check. For the invented fixture:

80 of 100 valid task starts were completed by the observation cutoff, counted once per task and excluding internal and test accounts; the 50 distinct people who completed them are not an activation rate, because the number of distinct people who started was never counted.

That is what was counted, among whom, over what interval, and with what material limit. It fits in a caption, and nothing on the slide should claim more than it supports. The headline above it can be shorter, plainer, or louder. It just cannot say more than this sentence does.

Frequently asked questions

What four definitions belong before a traction headline?

Unit: what is counted, such as people, accounts, tasks, sessions, transactions, or event rows. Qualifying event: what puts a record in the count and where it starts and ends. Period: cumulative through a date or activity inside an interval. Denominator if it is a rate: who was eligible and for what.

Why is 120 customers activated wrong in the article's fixture?

The fixture has 120 recorded completion event rows, 80 distinct tasks completed, and 50 distinct people who completed at least one task. The headline changes the unit from event rows to people and changes the behavior from a completion row to activation, which would need its own definition.

What does the 80% figure in the fixture actually measure?

It measures 80 of 100 valid task starts completed by the observation cutoff. It is not 80% of users or an activation rate, because the fixture never counts how many distinct people started a task. The cutoff also gives early tasks more time to finish than later ones.

How should cumulative totals and period figures be handled?

They are different claims: a cumulative total counts everything through a date, while a period figure counts only what happened inside an interval. Both can be true the same afternoon. Growth percentages compare two baselines, so a changed completion definition or a new reporting surface can turn the comparison into two measurements under one label.

What must be stated about repeat rows, exclusions, and coverage?

Find why extra rows exist, such as reopened tasks, retries, resumed sessions, backfills, or duplicate instruments, and state a rule like one completion per task, earliest recorded, or every completion row. State whether internal and test accounts were excluded. Coverage limits matter too: a signed-in-only instrument misses signed-out or integration completions, and incomplete observations are not measured non-use.

Further reading

• Choose Evidence That Answers the Claim on the Slide — Read this when a slide's headline sounds stronger than the screenshot beside it, to decide whether to change the claim or change the evidence.
• Sales, Product, and Finance Use the Same Metric Name for Different Things — Read this when two teams quote different totals for the same metric name and you need each owner's unit, event, period and exclusions before reconciling.