How we measure AI visibility

A tracked prompt is a question a buyer might actually type. We ask it, then read the answer for seven things. Every metric below is a count over answers — never an estimate, never a model scoring another model on a 1–10 scale.

Prompts that do not name your brand are the ones that matter most: they measure whether an engine reaches for you unprompted. We label every prompt branded or unbranded and lead with the unbranded set.

A poll asks up to 12 active prompts against every configured engine, 5 times each. Five is the sample behind a single engine's daily rate — small enough to be affordable, large enough that the interval around it is honest rather than decorative.

answers per poll = prompts (≤12) × engines × runs per prompt (5)
hard cap        = 360 answers per cycle
                  (over the cap, runs per prompt drop, never the prompts)

The engine roster is the model configured for your workspace, called directly — that one is always polled — plus a fusion roster reached over OpenRouter, plus Perplexity when a key is present. As of 20 July 2026, the roster is Anthropic Claude Sonnet 4.5 (called with web search enabled, which is why its answers carry queries and citations), OpenAI GPT-4o, Google Gemini 2.5 Flash, DeepSeek Chat, Meta Llama 3.3 70B and xAI Grok 4.3. The roster is configuration, not doctrine: it changes as models ship and retire, and each engine's identity is stamped on every answer we store.

Adaptive stopping. When a prompt/engine pair has been pinned at 0% or 100% mention for 14 days across at least 10 answers, we drop it to 2 answers per poll. More samples cannot move a rate that has never moved, and the budget is better spent on contested prompts.

Degradation is graceful and recorded. A provider that errors produces an error answer that still counts in the denominator; two consecutive failures and that engine sits out the rest of the poll. Your other engines finish.

“3 out of 5 answers mentioned you” is not 60%. It is a small sample whose true rate plausibly sits anywhere from about 23% to 88%. We attach a Wilson score interval to every rate and draw it as the shaded band on the trend chart.

p = k / n

center    = (p + z²/(2n)) / (1 + z²/n)

halfwidth = z · sqrt( p(1-p)/n + z²/(4n²) ) / (1 + z²/n)

interval  = (center - halfwidth, center + halfwidth)

We use Wilson rather than the textbook normal approximation for two reasons: it never produces an interval that leaves 0–100%, and it behaves sensibly at the edges — 0 out of 5 mentions gives you a real upper bound instead of a meaningless zero-width band. With no answers at all (n = 0) the interval is the full 0–100% range: no data means no information, and we draw it that way.

Every KPI on the Overview compares today against roughly seven days ago. Most of those differences are sampling noise. A delta only earns an arrow — up or down, green or red — when it passes a two-proportion test at 95% confidence against the actual answer counts on both days. Everything else renders as no significant change, with no direction implied.

p₁ = k₁ / n₁        p₂ = k₂ / n₂

p̂  = (k₁ + k₂) / (n₁ + n₂)

significant  ⟺  |p₁ - p₂| > 2 · sqrt( p̂(1 - p̂) · (1/n₁ + 1/n₂) )

This is the rule most visibility dashboards skip, and it is the one that makes the rest trustworthy. A tool that draws a green arrow on a 4-point move across 25 answers is selling you a feeling, not a measurement.

Polls run daily. A background scheduler picks up any tracked brand whose newest snapshot is more than a day old and polls it; you can also run one on demand from the Visibility page at any time.

Results roll up into one snapshot row per engine per day, storing the rates together with the raw counts behind them (k mentions out of n answers) and the Wilson interval for each. Re-running a poll on the same day updates that day's row rather than appending a second one, so the trend line stays one point per day. Individual answers are kept in full — the Engines tab shows the text, the citations and the model version behind every single one.

Engines do not all answer on the same days. Optional engines are toggled on mid-week, providers go down, adaptive stopping trims a settled prompt, and a poll that ran at 23:50 lands on a different calendar day than the one before it. The result is a staggered series: on any given day, some engines have a row and some do not.

Plotted raw, that scallops. The line for an engine drops out on the days nobody asked it anything, which reads as a visibility crash caused entirely by the polling schedule. The Smooth toggle on the trend chart switches to a last-value-carried-forward (LVCF) series instead.

for each engine, for each day d in the window:

  actual(d) = the measurement taken on d, or null

  lvcf(d)   = actual(d)                 if d was measured
            = lvcf(d - 1)               otherwise (carry forward)
            = first observation         if nothing measured yet (back-seed)

Smoothing never rewrites a number. The API returns both values on every row — actual_*, which is null on a day with no poll, and lvcf_*, the carried value — plus a filledflag naming which days are fills. Confidence bands are drawn only on real days: a carried value has no sample size of its own, and painting yesterday's interval over today would claim evidence nobody collected.

The claim LVCF makes is modest and, we think, the honest one: the last thing we actually measured is still our best estimate of today — until a new answer replaces it. Back-seeding runs the same logic backwards to avoid opening a chart at a fictional zero, and is the one step that reads information from the future, which is why those days stay flagged as fills.

The headline figure follows from this.The number printed beside a trend chart is read as “where do we stand now”, so it is the last non-null point of the smoothed series— not an average over the window, and not the raw newest day. Each engine contributes its most recent measurement. A window average answers a different question, and silently over-weights whichever engines happened to poll most often; reading only the newest day quietly redefines the metric as “the rate among the engines that ran today”, so the KPI lurches whenever a different subset polls. The 7-day comparison is computed the same way at both ends.

One 0–100 number, four equally weighted parts, computed over the last 28 days of successful answers. We publish the components and their inputs next to the score so you can always reconstruct it.

score = 25% visibility + 25% position + 25% sentiment + 25% recommendation

visibility     = 100 × mentioned answers / answers

position       = mean over ranked answers of max(0, (5 - rank) / 4) × 100
                 (rank 1 → 100, rank 5 or worse → 0; unranked answers excluded)

sentiment      = (mean sentiment + 1) / 2 × 100
                 (positive = +1, neutral = 0, negative = -1)

recommendation = mean of  top pick 100 | strong alternative 75 |
                          conditional 50 | mentioned only 25 |
                          discouraged 0 | not mentioned 0

The weighting is a judgement call and we make it in the open: an engine that mentions you constantly but never recommends you is not a win, so recommendation carries the same weight as raw visibility. When a component has no data — no ranked answers yet, say — it contributes 0 rather than being quietly dropped, which keeps the score honest about thin evidence.

None of the following is fixable with better engineering. They are properties of measuring a probabilistic system from the outside, and you should hold our numbers with them in mind.

Measurement changes break comparability, so we record them. When a change alters how a historical number would have been computed, it is listed here rather than applied silently.

Found something here that does not match what the product shows you? Tell us — a methodology page that drifts from the code is worse than none.