When not to run the analysis
Not every question deserves an analysis. Some cannot be answered with the data available, some would not change anything, and a few should be declined because answering them would be wrong.
Recognising each kind early is part of a data function's job, and it is the part that earns the most long-run credibility.
When can the data not answer it?
When the question requires a counterfactual the data does not contain, when the effect is smaller than the measurement noise, or when the required population was never measured. Each of those produces a number if forced, and the number is not evidence.
The honest output is a statement of what would be needed to answer it. That converts a refusal into a proposal.
When would the answer not change anything?
When both plausible results lead to the same action, which happens more often than anybody admits. The test is to ask what would be done under each outcome, in advance.
This is the most common reason to decline and the easiest to establish. It takes one question at the briefing stage.
When is the effect too small to detect?
When the sample or the variation cannot support the precision required. A test that cannot distinguish the effect that would change a decision from zero will produce an inconclusive result read as a negative one.
Saying so before the work, with the detectable effect size attached, is far better than saying it afterwards.
When should a question be declined outright?
When answering it would require inferring characteristics that should not be inferred. Tender type is a payment method, not a persona, and inferring household characteristics from how somebody pays is analytically sloppy and ethically wrong.
A data business in this space is well served by declining the question rather than by finding a technically permissible version of it. That is a position worth holding explicitly rather than case by case.
What about questions that are too small to be worth it?
Analyst time is a real cost and an analysis that takes a week to inform a decision worth a fraction of that is a poor trade. It is legitimate to say so and to offer a rough answer instead.
Rough answers are underrated. A defensible estimate produced in an hour frequently serves a decision better than a precise answer produced in a fortnight.
How should a decline be communicated?
With the reason and an alternative. "This cannot be answered with our data; here is what could be answered, and here is what would be required for the original question" is a useful response.
A flat refusal damages a relationship; a redirected one builds it, and the redirect is usually available.
What does saying no cost?
Less than saying yes badly. The credibility of a data function rests on its outputs being reliable, and an output produced under protest to a question the data could not answer is the fastest way to lose that.
Frequently asked questions
Who should be able to decline?
The analyst, with a route to escalate. A function where nobody can decline produces work regardless of feasibility, and the quality of everything else degrades to fund it.
How do I explain that the data cannot answer it?
Concretely: name what is missing and what it would take. "We do not observe promotional support, so a price effect cannot be separated from a display effect" is understood by a commercial audience.
What if leadership insists?
Produce the best available answer with the limitations stated prominently, and make sure the limitations travel with the number. A caveat that stops at the analyst has not been communicated.
Is a rough answer better than none?
Frequently, provided it is labelled as rough. What is dangerous is a rough answer presented with the confidence of a precise one, which is how an estimate becomes a fact in a later deck.
How do I handle a question that presumes its answer?
Reframe it neutrally and check the reframing with the requester. "Why did the promotion work" becomes "did the promotion work, and if so by how much," which is a different and answerable question.
Should ethical declines be documented?
Yes, with the reasoning, because they establish a precedent and they protect the person declining. A documented position is easier to hold the second time.
What about a question a competitor would answer?
That is not a reason to answer it. A data company's credibility rests partly on where it declines to look, and matching a competitor's willingness is a poor standard to adopt.
How do I avoid seeming obstructive?
By offering the alternative every time. The pattern to establish is that a no always comes with a what-instead, which makes the function a partner rather than a gate.
What is the practical test for all of this?
Ask what decision depends on it and what result would change that decision. Most questions that should not be run fail one of those two, and both are answerable in a short conversation.
### How should a data function track what it declines?
A short log of declined requests with the reason. It establishes consistency, it protects the person declining, and it reveals patterns — a stream of requests the data cannot answer is a signal about what the business needs and does not have.
That last use is the most valuable. A log of unanswerable questions is the best available specification for the next data investment. Industry context is collected by trade bodies such as FMI.
Working with retail data? See NRS Insights data solutions or contact NRS Insights.