You receive an offer.
A website-analytics provider is pitching a tool that identifies where your website traffic comes from and enables direct outreach and retargeting.
The immediate response is straightforward: Your website currently receives too little traffic for that information to be particularly useful.
Rather than simply declining, you ask a different question:
How will I (or any other new business owner) know when website traffic warrants what you have built?
More specifically:
What are the signs that I am missing useful information from my website traffic?
The provider responds:
“Typically for a tool like ours to work effectively, we’d recommend minimum 5k visitors to your website a month. That gives you plenty of traffic to retarget and make the data work effectively!”
That answer is technically responsive.
But it answers a different question than the one you asked.
Observation
The provider supplied a product-performance threshold:
At approximately 5,000 monthly visitors, the tool can operate effectively enough to generate useful retargeting data.
The question you were asking was a decision threshold:
Under what conditions should I (or any business) recognize that it is missing information from its website traffic that is sufficiently valuable to justify acquiring this capability?
Those are not the same threshold.
You might have fewer than 5,000 visitors and still have highly decision-relevant traffic.
Imagine your business receives only a few hundred visitors a month, but those visitors are concentrated almost entirely within your intended market.
You are trying to determine whether your positioning is reaching the right people.
In that environment, knowing who is arriving might materially change what you do next.
Conversely, you might have substantially more than 5,000 visitors without the additional information changing any decision currently facing you.
The number of visitors has not changed the decision.
The decision has changed the significance of the number.
Structural Tension
This creates a small but important distinction.
A vendor knows when its product becomes useful. That is a legitimate product question.
You need to know when the information produced by that product becomes valuable enough to change a decision. That is a different question.
The second depends on more than traffic volume.
It may depend on:
- your field
- your stage of development
- your business model
- your target customer
- your acquisition model
- the volume and relevance of your traffic
- the uncertainty currently facing you
- the alternatives available
- and, critically, the decision the information is intended to improve
A threshold can therefore be perfectly accurate and still answer the wrong question.
Contrast
Consider a medical diagnostic test.
A manufacturer might say that its test performs reliably when there is a sufficient concentration of a particular biomarker.
That tells the clinician something about the performance conditions of the test.
It does not, by itself, tell the clinician when ordering the test is warranted.
That depends on the patient, the suspected condition, the consequences of missing it, the alternatives available, and what decision the result would change.
Now consider aviation.
An instrument might have a minimum operating condition below which its readings become unreliable.
That is an instrument threshold.
It is not necessarily the threshold at which a pilot should decide to alter course.
The pilot’s decision depends on what is happening in the aircraft and what options remain available.
The two thresholds may be related, but they are not interchangeable.
Structural Principle
Perhaps the hidden variable is decision relevance.
A technical threshold describes the conditions under which a capability produces useful output.
A decision threshold describes the conditions under which that output is sufficiently valuable to justify changing what you do.
Confusing the two produces a subtle form of reasoning drift:
“Our tool works effectively above X.”
quietly becomes:
“X is the point at which you need our tool.”
The first proposition may be supported by evidence about the product.
The second requires an additional inference about your environment.
That inference may be entirely reasonable. But it is still just an inference.
And that distinction matters because you are constantly presented with thresholds:
minimum volumes, recommended headcounts, utilisation rates, maturity levels, risk scores, conversion rates, compliance percentages…
The number often looks objective because it is precise. But precision in the threshold does not necessarily make the decision rule objective.
The relevant question remains:
What decision becomes better because this information exists?
This is also where the observation touches a broader concern with what might be called assurance laundering.
The problem does not require false information.
The underlying number can be completely genuine.
The laundering occurs when a valid piece of information acquires the appearance of establishing a broader proposition that it does not, by itself, establish.
The product really may work better above 5,000 visitors.
That does NOT establish that 5,000 visitors is the point at which you need it.
Closing Observation
Perhaps the more useful question for you is therefore not:
“How much traffic do I need before this tool works?”
but:
“What decision am I currently unable to make confidently because I cannot see something my website traffic could reveal?”
That question changes the analysis.
Traffic volume becomes one variable rather than the answer.
The value of the information depends on what uncertainty exists, what decision is being made, and what happens if the decision is made without it.
The interesting thing about thresholds is that they often look as though they belong to the thing being measured.
But sometimes the threshold belongs somewhere else entirely. A product can have a threshold for when it works. You have a different threshold for when you need to know.
And the distance between those two thresholds may be where the real decision lives.
