AI share of voice: the same 31 answers scored 33.3 percent on one surface and 36.9 on the other

What is AI share of voice a share of?

No search or answer platform publishes a share metric, which is worth establishing before treating any vendor's version as a standard. The Search Analytics API reference documents exactly four metric fields a site owner can read back about its own performance, clicks, impressions, ctr and position, with filter dimensions for country, device, page, query and search appearance. There is no field for how often a rival appeared beside you, and there could not be: the data belongs to one property and a share needs names the property does not own. Google's guidance on its generative surfaces goes further and declines the premise, stating that there are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary, a page carrying a last updated date of 10 December 2025. It names no share figure either, and points owners back at the ordinary performance report.

So share of voice in this category is not a platform metric that vendors read. It is a metric vendors construct, from answers they collected, against a set of names they chose. That construction is the product, and it is the part nobody publishes. The vocabulary of the field has settled on words like presence and share precisely because the ordered list that made search rank meaningful is often absent, a gap this blog has measured before in finding that 15 of 31 brand mentions carried no rank at all. The same looseness runs through answer engine optimization and through generative engine optimization as practices: both name an outcome that the platforms do not instrument, which leaves every number in the category resting on a vendor's own definitions rather than on a reported field.

That is not an argument against measuring it. It is an argument for stating the denominator next to the figure, which is what the rest of this post does for one tool, using the only corpus this repository can replay without asking an engine anything.

Two denominators shipped in one product

The arithmetic itself is one small function. shareOfVoice in core/src/tracker.ts takes a brand mention count and an all-entity mention count, returns the first over the second, clamps to the range zero to one, and returns null when the denominator is zero or less, on the same unmeasured-is-not-zero rule the other rates follow. The function is unit agnostic. It divides whatever two numbers it is handed, which means it cannot enforce a definition and the definition has to live in its callers.

Its comment states one anyway, in capitals, and the reasoning is sound. The denominator is the full auto-detected entity universe and never the tracked competitor roster, because the roster is a highlight set a customer picked, and dividing by a set the customer picked inflates the brand's share by exactly the entities it is losing to. A rival nobody thought to add is a rival the figure then pretends does not exist.

Two call paths ship. The dashboard KPI in site/src/lib/tracker.ts follows that rule: it sums the brand's daily rollup mentions, takes the entity rollup total, subtracts the brand's own entity row so the brand sits in the denominator exactly once, and divides. The presence report in worker/src/reports.ts calls reportedShareOfVoice, which delegates the arithmetic to the same shareOfVoice and adds a sample floor, and it passes owned mentions over owned plus rival mentions. Its rival figure is the competitor_mentions column of tracker_rollup_daily, and the worker binds that column to the length of the reconciled competitors array, which reconcileExtraction has already scoped to the tracked roster. That is the denominator the comment says must never be used, reached through the function that says so. The public tracked prompts behind both surfaces are listed on tracked prompts, and the per-product differences a buyer is weighing are on compare.

Neither surface is reading the other's number, and in production they also cover different windows, the dashboard over a rolling half window and the report grouped by day and engine. Holding the answer set fixed, as the replay does, isolates the denominator as the only moving part.

What was replayed on 26 October 2026, and what was not

The population is every row in the committed golden file, which holds 55. Running them through the shipped pipeline produced 31 rows whose final verdict is brand, 14 absent, 2 a different company sharing the name, 1 a homonym, 1 an engine naming the brand only to disclaim knowledge, and 6 with no verdict at all because the judge reply did not parse into the strict contract. Of the 55, 46 passed the market gate and 9 did not. The deduplication the production consumer applies to entity names is a no-op here, because no row in the file names the same entity twice, so the counts in this post match what the rollup would write.

Five limits bound everything above, and the first is the largest. These 55 answers are hand authored test inputs, not captured engine output, and they were written to exercise a judge rather than to be representative. The file is competitor dense by construction, which matters enormously for this particular finding: 58 of the 62 non-brand entity rows belong to names already on the tracked roster, so the fixture is close to the best case for a roster denominator. On a real brand's corpus, where the whole point of auto-detection is that it surfaces rivals nobody listed, the gap this post measures would be expected to be larger, and this file cannot show how much larger. Nothing here estimates that.

Second, one brand is involved, lantad.co and its aliases, so none of this compares vendors. Third, 31 rows is a small base and several cells below are single observations, reported as counts rather than rates. Fourth, nothing here measures stability across repeated runs, which is a separate and larger source of movement: work reported here found that a tracked prompt needed seven runs before its visibility estimate settled, and the question of how many prompts an AI visibility measurement actually needs sits underneath any share figure quoted once. Fifth, this is arithmetic rather than accuracy: the same fixture set was used to audit the neighbouring column, where a word list graded 3 of these 55 answers non-neutral and all three were wrong. The wider programme these sit inside is indexed on research.

Where the nine missing entity rows went

The dashboard counted 62 non-brand entity and answer pairs across the file. The report counted 53. Those nine split cleanly into two causes, and they are not the same kind of problem.

Four of the nine are entities that are simply not on the roster. Across the whole file they are four distinct names appearing once each: a search console product, and three names a reader would have to look twice at, Lantern Analytics, LantaData and Lentid. All three are near misses planted in the file to test the fuzzy matcher, each sitting at edit distance two or more from every brand alias, which is itself informative. The auto-detected universe catches whatever the answer recommended; the roster catches only what somebody typed in. That is the inflation the shareOfVoice comment describes, and on this file it is worth four rows.

The other five are more awkward, because they are roster members the report still missed. The report's rival count comes from the reconciled competitors array, which is built from the judge's competitors field and then matched against the roster by a folded name key. The dashboard's universe comes from the judge's recommended entities field. On five answer rows the judge listed a tracked rival among the recommended entities and did not repeat it in the competitors field, so the name entered one denominator and not the other. Nothing is wrong with either field. They answer different questions, one asking what the answer recommended and one asking which rivals it named, and a model answering both will not always agree with itself. The consequence is that the report's denominator is smaller than the roster alone would predict, so its share figure is higher than even the roster rule would give.

Put together: 31 over 93 is 33.3 percent and 31 over 84 is 36.9 percent, a gap of 3.6 points on a fixture built to favour the roster. For a buyer the figure to carry away is not 3.6. It is that a 3.6 point gap existed between two surfaces of one product, from one answer set, with no bug in either query and no disagreement about a single mention. The rivals this corpus happens to name are covered on their own terms under comparisons, and what those vendors actually publish about themselves was read directly in finding that 5 of 7 published a price today. How a composite score hides this sort of choice was opened up on the crawl side, where 972 of 1,419 corpus sites were graded and prose parity took 60.7 percent of every point they lost.

The name verdict gates the numerator and the denominator

Before any division happens, something has to decide what the brand name referred to, and in this pipeline that decision gates both halves of the ratio. Presence is deterministic: an alias list plus edit distance one decides whether the string is in the text, which is a question about characters and needs no model. Identity is the judge's alone, because it is a question about meaning, and a matcher cannot tell a company from an adjective. A mention is the conjunction of the two.

Five verdicts exist in core/src/tracker.ts, and only brand counts as a mention. A different company sharing the name is not one. A common word in another language is not one. An engine naming the brand only to say it does not recognise it is explicitly not one, on the stated reasoning that an engine disclaiming knowledge is the opposite of visibility, so counting it inverts the metric. That narrowing is not theoretical tidying: the literal reading of presence produced a 12.6 percent headline against a truth near one percent, measured here in finding that nineteen counted mentions were about two companies.

The denominator inherits the same gate through a separate function. isMarketVerdict admits only brand, brand_unknown and absent, and the absent case is deliberate: a category answer that never names you is exactly where your rivals are, so it belongs in the universe. A homonym answer and a wrong-company answer do not, because their recommended entities belong to a different market. The comment beside it records what that cost once, a dictionary answer putting three Tagalog words into the live share-of-voice denominator. On this file the gate removed one name, Landa, a real-estate product the engine resolved the brand name to. One is a small number and the mechanism is the point rather than the count. An unclassified run with no verdict is excluded from both halves as well, which is why nine of the 55 contributed nothing. How much of this rests on telling one entity from another is the subject of entity confidence, and the related failure of pointing at the wrong company entirely was counted in finding that most AI citations point at other companies.

What to ask any vendor reporting a share figure

The useful output of this exercise is a short list of questions, because none of what moved the number above is visible in a rendered percentage, and all of it is answerable by a vendor willing to say.

Ask what the denominator is. Specifically, ask whether it is the set of competitors you typed in or the set of names the answers actually produced, and note that the first is the flattering one. Ask what the counting unit is, because this is where documentation drifts from code even inside one product: the comment on reportedShareOfVoice in core/src/reports.ts describes counting per mention, so that an answer naming a rival three times counts three, and both shipped paths count per answer instead. On this fixture that choice alone moves the brand numerator from 31 to 36 and the universe share from 33.3 to 36.7 percent. Ask what happens to an answer that produced nothing: here a denominator of zero returns null rather than zero, and the report additionally withholds any figure until 12 mentions have accumulated, a floor set in core/src/config.ts. A tool that prints zero percent for a quiet week and a tool that prints nothing are telling you different things with the same pixels.

Ask what happens when the name is ambiguous, which is the question most worth asking and the least often asked. If your company shares a name with a word, a place or another firm, every figure in the product depends on a classification step you cannot see. On your own side the usable lever is to make the identity assertable: schema.org defines sameAs as a URL of a reference Web page that unambiguously indicates the item's identity, available on any type, and how thinly that is deployed in practice was measured here in finding that 85 of 317 organizations named a reference entry. It is not a fix for a vendor's classifier, and claiming otherwise would be the sort of thing this post is arguing against. It is the one place a site owner gets to state the answer rather than hope.

Finally, the inconvenient part, stated plainly because the alternative is worse. The defect above is this product's, found by reading its own code against its own fixtures, and it is the report path that is wrong: the comment in core/src/tracker.ts names the right denominator and worker/src/reports.ts does not use it. Nothing in this post is a claim about how any other vendor computes its figure, because that would need their source and this has only ours. What our own plan costs to run is on pricing.