Short answer: share of voice in AI answers is your brand's mentions divided by the mentions of every brand the answers named, computed on a fixed set of buyer questions, separately for each engine. Getting a number you can defend comes down to six steps: fix the question set, record how each engine was run, store the raw answers, extract every brand rather than only the ones on your list, count each engine on its own, and report the denominator next to the share.

This guide walks through those steps with a small worked example. Its companion, brand share in AI answers, covers how to read and audit a share-of-voice figure someone else hands you.

STEPWHAT IT PREVENTS1Fix and version the question setBrand-named echoes; a moving denominator2Log engines and retrieval per runA method change read as brand progress3Store answers and failuresTimeouts counted as non-mentions4Extract every brand, merge variantsList-only detection inflating your share5Count each engine separatelyAn average that describes no engine6Report the denominator beside itA share with no sense of its scale
Figure 1. The six steps for measuring AI share of voice, each paired with the error it prevents. Each step protects the one after it. Source: the measurement rules in this guide.

The order matters because each step protects the one after it. A share computed on a drifting question set cannot be rescued by careful counting, and careful counting cannot be checked without the stored answers. If you are short of time, do fewer questions, not fewer steps.

Step 1: fix the question set before you measure share of voice

Every percentage in this exercise has the question set as its denominator. If the set changes between runs, the number changes even when nothing about your visibility did. Three rules keep the set honest:

  • No brand names in the questions, neither yours nor a competitor's. Ask an assistant whether a named company is any good and it will name that company. That measures nothing about whether the brand surfaces on its own.
  • Full sentences with a situation in them. A question carrying a budget, a constraint or a use case produces a different set of named brands from a bare category term, and buyers ask in sentences.
  • An intent recorded on every question, so a share that is strong in research questions and weak in purchase questions is visible rather than averaged away.

Freeze the set and give it a version. Building a prompt set covers how to write one.

Step 2: record how each engine was run

Write down, for every run, which engines were asked and whether web retrieval was on. These are part of the ruler, not details. Turning retrieval on once moved a site from 3% to 13% while the site did nothing; shown as a trend, that would have been a change to the measurement reported as an improvement in the brand.

Retrieval also changes what an engine can see. With it on, the answer can only draw on your pages if the engine's search and user agents can fetch them: for ChatGPT that is OAI-SearchBot and ChatGPT-User, documented in OpenAI's bot documentation; for Perplexity it is PerplexityBot and Perplexity-User, documented in Perplexity's bot guide. A share-of-voice drop that coincides with a robots.txt or CDN change is an access problem, not a reputation problem.

Not every engine can be checked this way. xAI does not publish a documented crawler user agent, so for Grok you cannot confirm access by name; record that as a known gap in the run notes rather than assuming access is fine. Record the market and language of each run as well, because the same question asked for a different region is a different question, with a different set of brands in the answer.

Step 3: store the raw answers and the failures

Keep the full text of every answer, with the engine, the question, the date and the cited URLs. Without the original answer you cannot tell a counting bug from a real change, and you will meet both.

Keep the failures too. When a model times out or a request fails, no evidence was produced either way. Record that cell as unmeasured rather than as a non-mention, and report attempted and completed counts side by side. Counting a failed request as zero drags the share down and can make a normal month look like a decline. The unmeasured versus zero entry explains the distinction.

Step 4: extract every brand, and resolve variants

Pull every brand each answer names, not only the ones on your competitor list. If you match your own brand loosely and competitors only against a fixed list, every brand outside the list falls out of the denominator and your share rises by construction. Your competitor list is for highlighting rows in the report, not for deciding what counts.

Then resolve spelling variants of one brand into one entity before counting: casing, punctuation, legal suffixes, and a product line named instead of the company. Splitting a competitor into several rows understates it and flatters you; splitting your own brand understates you. Apply the same rules, in the same pass, to every brand. Competitor set design covers the rules in detail.

Keep a mapping table rather than fixing variants by hand each run. One row per variant, pointing to the entity it belongs to, applied before any counting, and versioned with the rest of the method. When a new variant appears, adding a row changes past results too, so restate history when the table changes. The same table is where you decide edge cases once, for example whether a sub-brand counts as its parent, instead of deciding them differently in each report.

Step 5: count share of voice one engine at a time

The calculation itself is short:

share_of_voice(brand, engine) =
    mentions of brand in completed answers on that engine
  / mentions of every brand in completed answers on that engine

mention   = a brand named in an answer, counted at most once per answer
completed = the request returned an answer; failures are excluded, not zeroed

A small worked example on one engine, with five questions:

QuestionBrands namedMentions
Q1Brand X, Brand Y, You3
Q2Brand X, Brand Y2
Q3Nobody0
Q4Brand X, Brand Z, You3
Q5Request timed outUnmeasured

Four of five questions completed, with eight brand mentions between them. You were named twice, so your share is two in eight, a quarter. Brand X holds three in eight. Your mention rate, the share of completed answers that named you, is two in four. Q3 named nobody, which is worth its own line in the report: it is open ground rather than a loss. Q5 is excluded from both numerator and denominator and reported as a gap.

Now the common mistake. If your detector only knew about Brand X and Brand Y, Brand Z would fall out and the total would drop to seven, lifting your share to two in seven without anything changing. That is the whole mechanism behind inflated share-of-voice figures: nothing looks wrong in the output.

One engine, four completed answers, one mention per squareIllustrative worked example from this guide, not measured dataEvery named brand countedYouBrand XBrand YBrand ZYour share: 2 of 8Detector knows only X and YYouBrand XBrand YZ droppedYour share: 2 of 7Nothing about the answers changed between the two rows. Only the denominator did.
Figure 2. The worked example from step 5 drawn as one square per mention. A detector that misses one brand shrinks the denominator and raises your share without any answer changing. Source: illustrative example, not measured data.

Repeat the calculation for each engine and report them separately. In our own benchmark one model named 3.5 providers per answer and another 2.1; an average across the two describes neither.

Step 6: report the denominator next to the AI share of voice

A share is meaningless without its context. Report, next to every figure:

  1. The question set and its version, and the date range.
  2. The engines, and whether retrieval was on.
  3. Attempted and completed answer counts.
  4. The total number of distinct brands named. Being 1% of 117 brands is a completely different situation from 1% of five.
  5. Your rank among all named brands, not only among your chosen competitors.
  6. How many distinct questions named you. Appearing once in each of several questions is a stronger position than appearing repeatedly in one.

When a run has too few completed answers, withhold the share rather than print it. A percentage computed from a handful of answers will swing on the next run, and readers will treat the swing as news.

Share of voice[engine]: [share]one block per engine1Question set, versionand date range2Engines, and whetherretrieval was on3Attempted andcompleted answers4Distinct brandsnamed in total5Your rank amongall named brands6Distinct questionsthat named you
Figure 3. A report block for one engine: the share in the centre and the six context items that should always be printed beside it. Source: the reporting rules in step 6.

A practical layout is one block per engine: the share in large type, and the six context items in small type around it. Readers who only glance at the large number still see that it came from a stated number of answers, among a stated number of brands. Keep share of voice and citation figures in separate blocks, too: your page can be the cited source of an answer that recommends a competitor, and merging the two flatters the report.

Why each rule is there

Each step above corresponds to a mistake we made ourselves. Asymmetric competitor detection once showed a brand at 31% share of voice and rank two; measured symmetrically it was 0% and last. An LLM-generated question set once contained the brand name in 13 of 15 questions, and the score read 13% when the honest value was zero. Neither error was visible in the final number.

Answers also vary between runs when nothing has changed. Treat a movement as real only when it appears in two consecutive runs on the same methodology version; measuring change over time explains how to set that up. If you would rather not build the pipeline yourself, InsightWonder's competitor intelligence applies these rules by default.

Sources