Ask an answer engine to recommend a vendor and it will not always cooperate. It may decline the question. It may answer in general terms and name nobody. It may return an empty response, or one where retrieval never fired and no sources came back at all.
Every tracked-prompt product has to decide what to do with those. The decision is one line of SQL and it changes every number on the dashboard.
Two defensible-sounding rules, one of them wrong
The tempting rule is: count the answers that mentioned somebody. It feels clean. Chats with no brand in them are noise, so drop them, and measure over what is left.
The rule we hold is the other one: every chat that exists counts, including the ones that named nobody.
The difference is not academic. Suppose an engine is asked the same question every day for a month, and on a third of those days it declines to recommend any vendor. Under the first rule your visibility is computed over twenty days. Under the second it is computed over thirty. The first number is larger. It is also describing a market that does not exist — one where the engine always answers.
What a refusal actually tells you
A refusal is not missing data. It is data.
It says this question, on this engine, in this country, does not reliably produce a recommendation. That is a finding about your category, and often a more actionable one than a mention would have been:
- If a prompt refuses consistently, no amount of content work will make you visible on it. It is a dead tracked prompt, and it is costing you a slot.
- If a prompt starts refusing after months of answering, something changed — in the engine's policy, in how the question reads, or in the market.
- If one engine refuses a question that three others answer, that is a real difference in behaviour between them, and it is invisible if you have filtered refusals out.
Delete those rows and all three findings disappear. Worse, they disappear upward: the visibility line goes up, because the denominator went down.
The line we actually draw
There is a real distinction to make here, and it is not between "answered" and "refused". It is between an engine that responded and a job that never got a response at all.
- A request that failed in transport, timed out, or was skipped produces no chat. There was no answer to measure. It is excluded from every denominator, because counting it would penalise you for our infrastructure.
- A request that came back with anything — a full answer, a refusal, an empty body, a response where retrieval never fired — produces exactly one chat, and that chat counts as one response.
So the denominator answers a precise question: of the times we successfully asked and the engine successfully replied, how often were you named? Failures of our pipeline are not your problem. Refusals by the engine are.
Checking your own numbers
If you are evaluating a tool, this is worth asking directly, because it is rarely documented and it is easy to test:
- Ask whether a chat with zero brand mentions is counted in the denominator.
- Ask what happens to a refusal, an empty response, and a response with no citations — three different states that are often collapsed into one.
- Ask whether a transport failure is distinguishable from a refusal in the export. If it is not, the tool cannot compute either policy correctly, whatever it claims.
A vendor who has thought about this will answer in about a sentence. A vendor who has not will tell you about their coverage.
Why we write it down
The denominator is the least visible decision in a visibility product and the one with the widest blast radius. It sits under Share of Voice, under visibility, under every rate on every chart, and unlike a chart it has no pixels of its own. Nobody discovers it by looking.
So it is stated, rather than implied, and it is the same instinct behind refusing to let a brand filter reach the denominator: the numbers are only worth reporting if you can say exactly what they counted. The rest of what this product commits to is summarised on the home page.