Share of Answer — Definition & How to Measure

Share of answer is the share of a buyer’s prompt set on which your software is named when those prompts are put to an AI engine, counted per engine over repeated runs. It takes over the job that share of voice did in paid and organic search, and it is computed differently because an answer carries no impressions and no ranked list of ten links to weight. This guide defines the metric and its variants, works the arithmetic with the definitions the AI Shortlist Index uses, and says what sample makes the result worth reporting.

The definition

Take the 25 prompts a property manager in your category would ask. Send each one to an engine several times in fresh sessions. Share of answer is the fraction of those runs in which your name appears in the answer text, after removing the runs where the prompt itself supplied your name. That is the whole definition, and it is the same quantity the Index methodology calls mention rate.

The base figure is per engine. The denominator is the count of runs on that engine that returned a usable answer, over the prompts where you are not seeded. The numerator is the subset of those runs in which your canonical name or a listed alias appears. A vendor named in the prompt text, as in “alternatives to Latchel”, is recorded but excluded from its own count on that prompt, because otherwise every “alternatives to” prompt would hand the incumbent a free mention on every run.

Four variants are worth knowing, because vendors and tools use the phrase loosely and they do not mean the same thing.

Blended share is the mean of the per-engine shares across the engines that answered. It is a mean of rates, not a pool of runs, so an engine with no usable runs is left out of the average instead of pulling it toward zero.

First-named share is the fraction of usable runs in which you were the first vendor named. A buyer who reads one name and books one demo is measured here and nowhere else.

Position-weighted share gives each run where you appear a weight of one over your position, so first counts 1, second counts 0.5, third counts 0.33, and divides the sum by the usable runs. It folds presence and position into one figure. The Index does not publish it, because a single folded number hides which of the two moved; it publishes mention rate and position score side by side instead.

Prompt coverage is the fraction of prompts on which you appeared at least once across the three runs. It is the most flattering of the four, since one appearance in three attempts counts the same as three in three, and the Index does not use it. The gap between coverage and mention rate is what the consistency metric measures directly.

Share of voice in paid search is impressions divided by the impressions you were eligible for. In organic search it is a rank-weighted sum across a keyword set, with each position on the results page given a click-through weight from a curve. Both formulas rest on quantities that exist only on a results page. An impression is a countable event because an ad server logs it. A position is one of ten slots on a page. A click-through curve exists because people click.

None of those quantities exists inside an answer. There is no impression log for the answers an engine produces to other people’s prompts. Position exists, but as an ordinal among two to five names in a paragraph of prose, and there is no published curve for how often a buyer acts on the second name versus the first. And the buyer does not have to click anything for the answer to have done its work; a property manager with 300 doors reads two names and books two demos.

There is a second difference that matters for anyone who reads the numbers. Share of voice was built on a fixed inventory: every impression in a market belonged to someone, so competitors’ shares summed to one hundred. Shares of answer do not sum to anything. An answer that names three vendors gives all three a mention on that run, so two vendors can both hold a share of 1.0 on the same prompt set. If a dashboard shows your category’s shares of answer adding up to one hundred percent, it has normalized them, and the normalization has thrown away the information about how many names each answer carries.

Computing it from a prompt set

The method has three parts, and the Index publishes all three so that anyone can reproduce a figure.

The prompt set is frozen and versioned. Each Index category has 25 prompts across six types: seven open shortlist questions, five “alternatives to” prompts, four segment prompts, three integration prompts naming a property management system, four problem-led prompts with no product words, and two head-to-head comparisons. The current set is Prompt Set v1.0, approved 2026-09-02, and every prompt is public with its id on the prompt library. Editing a prompt to include your product name or a feature only you have measures nothing.

The runs are repeated and separated. Each prompt goes to each engine three times, each in a fresh session with no shared state, spread across at least two days, at engine default sampling settings. The model identifier the API returns is stored with every run, because the engines change models without notice and a month-to-month move has to be read against that record.

Extraction is deterministic code. A vendor is named when its canonical name or a listed alias appears in the answer, with matching that tolerates a space or hyphen between name tokens and treats names that are also common English words, such as Meld or Latch, case-sensitively. Every cited or consulted URL is stored with the run.

From there the arithmetic is short.

mention_rate[e]  = runs on engine e in which the vendor is named
                   ÷ usable runs on engine e
                   (over prompts where the vendor is not seeded)

blended          = mean of mention_rate[e] over engines with usable runs

position_score   = mean first-mention ordinal over runs where named
                   (1.0 = always first; lower is better)

consistency      = prompt×engine cells where all runs agreed
                   (all named, or none named)
                   ÷ cells with at least two runs

engine_spread    = count of engines with usable runs and mention_rate[e] > 0

Share of answer is the first line. The other four qualify it, and a share reported without them is a share you cannot interpret.

A worked example

Suppose a maintenance coordination vendor, call it Vendor A, is seeded in two of the 25 prompts in its category, the two “alternatives to Vendor A” prompts. That leaves 23 eligible prompts, and at three runs each, 69 usable runs per engine. Google AI Overviews returned nothing that month and ships as degraded, so it is excluded from every denominator.

Engine	Usable runs	Runs with Vendor A	Per-engine share	Where Vendor A appeared
ChatGPT	69	23	0.33	first in all 23
Perplexity	69	46	0.67	second in all 46
Gemini	69	0	0.00	never
Google AI Overviews	degraded	excluded	excluded	excluded

A hypothetical vendor across 23 unseeded prompts and three engines with usable runs. Blended share 0.33, engine spread 2, position score 1.67, first-named share 0.11 across the 207 usable runs, position-weighted share 0.22.

Blended share is the mean of 0.33, 0.67 and 0.00, which is 0.33. Engine spread is 2. Position score is the mean first-mention ordinal over the 69 runs where Vendor A appeared, which is (23 × 1 + 46 × 2) ÷ 69, or 1.67. First-named share is 23 ÷ 207, or 0.11. Position-weighted share is (23 × 1 + 46 × 0.5) ÷ 207, or 0.22.

Now hold every number in that table fixed and change only how the mentions are distributed across prompts. On ChatGPT, the 23 mentions could fall one per prompt across 23 different cells, or three per prompt across seven cells plus two in an eighth. The per-engine share is 0.33 either way. The consistency is not. In the first arrangement, all 23 ChatGPT cells disagree internally and, with a matching spread on Perplexity, the vendor’s consistency lands near 0.33. In the second, roughly 67 of the 69 cells agree and consistency lands near 0.97. The first vendor is one an engine sometimes produces; the second is one it reliably places on about a third of the questions and never on the rest. Same share of answer, different situation, different work to do. This is why the Index displays consistency next to mention rate and never hides it.

What a defensible sample looks like

A sample is defined by four counts multiplied together: prompts, engines, runs per cell, and days. The Index floor is 25 prompts by 4 engines by 3 runs across at least 2 days, which is 300 runs per engine per category and 900 responses per edition across the three launch categories.

Each count is there for a reason. Twenty-five prompts across six intent types keep one phrasing from deciding the result; a vendor that appears on every “best” prompt and no problem-led prompt has a real weakness that a five-prompt set would miss. Three runs per cell is the minimum at which consistency can be computed with a majority; two runs can agree or disagree but cannot outvote each other. Two days separates the runs from whatever the engine’s search index held on a single afternoon. Fresh sessions and engine defaults keep memory and prior conversation out of the answer. Documented APIs with web search or grounding enabled return the citations as data, so nobody is reading domains off a screenshot.

One query is not a measurement for the same reasons in reverse. It has no denominator worth the name, so a share of 1.0 and a share of 0.0 are equally likely to be the run the engine gets right, or wrong, one time in three. It has no consistency value at all. It cannot separate a change in your pages from a change in the model, because there is nothing to compare it to. And if it was run in a logged-in consumer app, it carries personalization from an account that is probably yours, which is the one account whose answers do not matter.

How the Index reports it, and where it does not

The AI Shortlist Index publishes blended mention rate as the basis for shortlist rank, with the per-engine rates alongside it, then position score, consistency, engine spread, source dependency, and movement since the prior edition. The measurement framework defines each of those in the same words the methodology uses. Share of answer does not appear as a separate column, because the blended mention rate already is that number over the 25-prompt set, and two names for one figure invite confusion.

What the Index does not report is as important as what it does. It has no click data. API answers send no traffic anywhere, the Index has no analytics from any vendor, and a share of answer says nothing about sessions or leads. It is not a share of a market. Being named on a third of the prompts says nothing about doors under management or revenue, and a vendor with a small customer base and a well-cited marketplace listing can outscore a larger one. It does not sum to one hundred across vendors, for the reason above. It measures the unpersonalized US baseline. Perplexity, Gemini and Google AI Overviews are read through documented APIs or a licensed provider, which are not identical to those vendors’ consumer apps; ChatGPT is read from its app with memory, custom instructions and chat-history search off, which is the app a buyer uses but not the app a buyer with a history has.

The first edition is the honest illustration of a denominator. The 2026-09 site export records one completed run: ChatGPT, model gpt-5.5, captured through the OpenAI API on 3 September 2026, on prompt mvn-best-01 in the maintenance and vendor network category, a prompt that asks for the best maintenance coordination software for a property management company with around 300 doors. The answer named Property Meld first and Latchel second. Property Meld therefore holds rank 1 with a mention rate of 1.0, a position score of 1.0 and an engine spread of 1; Latchel holds rank 2 with a mention rate of 1.0 and a position score of 2.0; consistency is null for both because a cell needs two runs before agreement can be measured. Read as shares of answer, both vendors sit at 1.0 on ChatGPT with a denominator of one run, not the 75 the category will have when its prompt set is complete, and Property Meld’s first-named share is 1.0 while Latchel’s is 0.0 on the same single run. That is one run of one prompt on one engine, and the maintenance category page says so on the table itself.

The same run cited or consulted 124 URLs, and by domain the top of the list was reddit.com with 38, appfolio.com with 16, buildium.com with 12, ir.appfolioinc.com with 5, then latchel.com and propertymeld.com with 4 each. Even a single run shows the shape of the third part of the method: the pages that carry a mention are mostly not the vendor’s own. A list that long is the API’s doing. ChatGPT runs recorded since the capture moved to the app carry only the links in the answer, so the ChatGPT side of a source map is now a shorter, vendor-heavier list.

What a vendor does with the number

Read the metrics in order. Engine spread first, because a share of 0.5 built from 1.0 on one engine and 0.0 on another is two different problems, and the per-engine table tells you which engine to start with. Position and consistency second, because a low share with high consistency means a fixed set of prompts where you are absent, which you can list by prompt id, while a middling share with low consistency means the engine is unsure about you everywhere. Source dependency third, because it is the only one of the metrics you can act on directly. It names the domains your mentions ride on, and the per-category Source Map ranks the top 20 domains and URLs with their page types. When those pages are a property management system’s marketplace, a review platform, and a forum, the work is on those pages before it is on yours.

Two guides cover the two most common findings. When the engine with the lowest share is ChatGPT, the guide to how ChatGPT picks its sources explains where the links in its answers come from. When your name shows up under an old brand, a parent company, or a spelling the alias list does not cover, the fix is the one in why your profiles must agree with your site, and the markup guide covers the Organization node that ties those profiles together. If you would rather have the measurement run for you every edition, the monitoring retainer delivers a movement report from the same run files the public Index publishes; paying for it never affects placement, because the Index measures what the engines say and the practice sells the work. A comparison of the tools that claim to measure this is in what the monitoring tools measure.

Three things not to do. Do not edit the prompts to include your name; the seeded-mention exclusion exists because engines echo prompts. Do not average across categories; a vendor in two categories has two shares, and the buyer asking about resident benefits is not the buyer asking about maintenance. Do not read a rise as caused by your work until the model record for the edition says the model did not change.

Limits

Extraction is lexical. A vendor referred to only by a nickname not in its alias list is missed until the review queue surfaces it, and no edition publishes with review items pending. Runs are US English and unpersonalized; real buyers get personalized answers, and the Index measures the baseline. Google AI Overviews are captured through a third-party SERP provider and may not appear for a given query, and the methodology records absence as “no AI Overview” rather than as a zero mention. Sentiment is cue-based and is a coarse framing signal, not a review score. Share of answer is a count of presence and says nothing about whether the sentence around your name would make a buyer call you.

The metric also has no causal story attached. It records who was named and which pages were cited. It does not see your markup, your profiles, or your press, so any statement that a specific change moved a share is a hypothesis until it survives more than one edition with the model held constant.

What changes month to month

The model behind each engine, which is why the identifier is stored per run and shown per edition, and why movement should be read against it. The prompt set, which changes only by version, with retired prompts kept in the file and every wording change logged. The engine status, since an engine with a broken API ships as degraded and drops out of the denominators for that edition without being counted as zero. The vendor list, since a name confirmed from the review queue joins the table and can take a rank without changing anyone else’s share. Movement itself, which is null in a first edition and becomes a number only when there is a prior rank to subtract from. Every change that can move a number is logged on the Index changelog with the edition it takes effect.

AI visibility: the measurement framework, the hub above this page, which defines every Index metric.
Index methodology, the source of truth for prompt design, capture, extraction and the metric table.
Entity consistency across LinkedIn, G2, Crunchbase and your site, for the alias and rename problems that lower a share without an engine changing its mind.
Structured data the engines document reading, for the Organization and SoftwareApplication nodes on your own pages.
How ChatGPT picks its web search sources, for the engine most vendors start with.
AI visibility tools compared, for what the commercial trackers do and do not compute.
Monthly monitoring, the practice offer that reports these figures per edition.

Changelog

2026-09-19: ChatGPT capture moved from the OpenAI API to the app at chatgpt.com, so the section on what the Index does not report was rewritten and the 2026-09 figures are labeled as the API capture of 3 September 2026.
2026-09-04: First published.

Share of Answer: The Metric That Replaces Share of Voice