Reading the numbers
Every rate here carries a confidence interval and a sample size, and a rate we couldn't measure says unavailable rather than 0%. This page explains all three, because if you only read one page of these docs, this is the one that matters.
AI answers vary run to run. Ask the same question five times and you can get your brand named twice. A single confident-looking percentage hides that, and hiding it is how this category earned its credibility problem. So the rate type in this product has no bare rate field — the point estimate cannot travel without its uncertainty:
{
"estimate": 0.42, // point estimate, 0..1 — meaningless on its own
"low": 0.28, // Wilson 95% lower bound
"high": 0.57, // Wilson 95% upper bound
"n": 48, // SUCCESSFUL observations behind the estimate
"unavailable": false // true = we could not measure this at all
}
// rendered: "42% (95% CI 28-57%, n=48)"
The sample size (n)
n is the number of successful observations behind the estimate — answers we actually got back and could classify. It is not the number of times we tried. A run that attempted 60 answers and got 48 usable ones reports n=48, and the 12 failures are not silently folded in as evidence of anything.
n is what makes an interval readable: 42% from 48 answers and 42% from 4 answers are not the same claim, and the number alone can't tell you which one you're looking at.
The confidence interval
The band is a Wilson 95% interval — the standard choice for proportions, and specifically the one that doesn't fall apart at small n or near 0% and 100%, which is exactly where AI-visibility numbers live.
How to read it:
- The band is the finding. "42%" is shorthand; "28–57%" is what we actually know.
- Overlapping bands are the same number as far as the sample can tell. If your rate moved from 38% to 45% and the intervals overlap, nothing has been shown. A difference is only real when the two bands miss each other entirely.
- A wide band means we haven't asked enough times yet. The fix for a wide band is more samples — not a bolder number.
Each rate also carries a reliability tag, computed from n and the width of the band:
| Tag | Meaning |
|---|---|
| measured | At least 15 observations and a margin of ±15 points or better. Trust it. |
| indicative | At least 6 observations and a margin of ±30 points or better. Directional. |
| sampled | Anything else. It's a first look. Widen the run count before you act on it. |
Why an engine reads "unavailable" instead of 0%
Every observation is stamped with a status, and only one of them counts:
| Status | Counted? |
|---|---|
| success | Yes. We got an answer and classified it. This is the only status that enters a rate. |
| unavailable | No. The call errored — timeout, quota, outage. Excluded from the numerator and the denominator. |
| parse_error | No. An answer came back but couldn't be classified. Also not evidence of absence. |
Two consequences worth internalising:
- Zero usable observations is
unavailable: true, not 0%. The formatter physically refuses to print a percentage for it — it prints "unavailable — no successful observations". You cannot accidentally screenshot a zero we never measured. - An engine whose calls all failed is not reported at all that week, rather than appearing at the bottom of your chart at 0%.
A measured zero is a real finding
Now the mirror image, and it matters just as much: a genuine 0% is not "unavailable". If we asked 40 times, got 40 usable answers, and you were named in none of them, that's estimate: 0, n: 40, unavailable: false — and it prints as 0% with its band. That's not a measurement failure. That's the answer, and it's the most actionable number in the product.
Checking us
You don't have to take the aggregate on faith. Your export includes the raw per-answer observations — each with its engine, its status and what we found — not just our weekly summary. The summary is our conclusion; the observations are your evidence. Recompute the interval yourself if you want to.