Share of answer is the operating metric for this practice.

How we count it
Request an audit

Insight · 11 min

Share of answer

Share of answer is the share of a defined query universe where you are the cited source in the answer. Share of search is a familiar idea: of the demand in a market, how much is yours. Share of answer applies the same discipline to extracted and generated answers. It is the operating metric of an AIEOLABS engagement, and it only means something after the universe is defined. Because AI answers change from run to run, it is also an estimate from a sample, so it should always be reported with a margin of error.

In short

  • Share of answer is a proportion: query-runs where you are cited, divided by query-runs. Report it with a 95% confidence interval, not as a bare percentage.
  • One run lies. Published tracking studies find that half or more of an answer’s citations or brand mentions can change from one day to the next.
  • The margin at 100 independent observations is about ±8 points when your share is near 20%, and about ±10 points near 50%.
  • Repeat runs of the same query are correlated. The effective sample is smaller than queries × runs, so more queries help more than more runs.
  • Call a change real only when the intervals do not overlap, or when a two-proportion or paired test says so. Otherwise report no detectable change.
  • “AI share of voice” in Ahrefs and Semrush is a related metric with a different denominator. State which one you report.

Define the universe first

A useful universe is finite and reviewed by someone who sells the thing. We separate it into four intents:

  • Commercial: the buyer is choosing.
  • Definitional: the buyer is learning the category.
  • Procedural: the buyer is trying to do the task.
  • Comparative: the buyer is testing alternatives.

Exporting a keyword tool into a spreadsheet does not do this. The list has to survive a conversation with sales, support, and product. Queries that nobody asks anymore come off. Queries the sales team hears every week go on, even if the tool has never suggested them. The method for building and freezing the set is in measuring AI search visibility.

Score the surfaces apart

Each query gets a score on each surface. The platform keeps them in one record.

  • Classic search: the ranking URL, whether it is yours, and whether it is the right page.
  • Answer engines: snippet, People Also Ask, AI Overview. Present or absent. If present, whether the passage is accurate.
  • Generative engines: a fixed panel of the products your buyers actually open, run on a cadence, with the answer and the sources logged.

Share of answer is the share of the universe where you are the cited source. Do not average it with rankings. A brand can rank fourth and still be cited, or rank first and be ignored because the page has nothing to extract. The surfaces are defined in SEO, AEO, and GEO, defined and compared.

The useful slide is the list of commercial queries where a competitor is cited and you are absent, with the reason beside each one.

Is share of answer the same as AI share of voice?

No. They are related, and the denominators differ. Share of answer, as we use it, divides the query-runs where you are cited by all query-runs in the universe. Your number does not depend on how many competitors you track.

AI share of voice usually divides by competitors. Ahrefs defines it as “the share of AI visibility your brand captures compared with the competitors you track,” with a basic formula of responses that mention your brand divided by responses that mention any tracked brand. Its Brand Radar version weights each prompt by modelled search volume. Semrush’s AI Visibility Toolkit describes its share of voice as the percentage of mentions your brand receives in AI-generated answers compared to competitors. Microsoft’s Bing Webmaster Tools reports a “citation share”: your citations as a percentage of all citations shown for a grounding query.

None of these is an industry standard. Two numbers with the same name from two tools are rarely comparable. Write the definition on the slide.

Why does one run lie?

One run lies because generated answers are sampled, not looked up. The same query on the same engine can cite different sources an hour later, and the web and the model also change week to week. Four published studies measure this in different ways, and all point the same way.

StudyWhat it trackedFindingRead it as
Go Fish Digital, Oct 5, 202673 questions for one client, one ChatGPT response a day for 63 days (4,599 responses)In 60.0% of 4,108 day-over-day comparisons, at least half of the previous day’s brand mentions were missing. Only 10.6% kept every mentionOne client, one engine. The authors say adjacent-day comparisons cannot separate run-to-run noise from real change
Ahrefs, Oct 29, 2026About 37,500 cited websites across AI Mode, ChatGPT, AI Overviews, Gemini, and Copilot, asked daily for 20 days“50–83% of citations are gone the next day.” About 75% of dropped citations returned within the window. Brand mentions were more stable than citationsGemini (64%) and Copilot (53%) often gave no citations at all, which inflates their churn
Profound, Sept 30, 2026883,000 cited pages across seven engines, daily, September 2025 to September 2026The median page loses half its citation share within 11 days of peakingVendor data, a 1-in-128 sample, and a category-relative metric
SISTRIX, May 202682,619 prompts on AI Mode, AI Overviews, and ChatGPT Search, weekly for 17 weeks, six marketsChatGPT replaces up to 74% of cited domains each week, AI Mode 56%. URL-level drift for ChatGPT is about 85%Domain-level, so the author calls the figures conservative

The numbers are not comparable with each other. One counts mentions, others citations; one counts domains, another URLs; the windows run from a day to a week. They agree on the conclusion. A single screenshot tells you what one answer said, once.

They also agree on something useful. Aggregates are steadier than single answers. Go Fish found the same five brands at the top in both halves of its 63 days, while individual answers churned. Ahrefs found brand mentions more stable than links. That is why the metric is a share across many queries and runs, and why it comes with an interval.

How many queries and runs do you need?

You need enough independent observations that the margin of error is smaller than the change you want to detect. What follows is the AIEOLABS method. It is standard statistics for a proportion, applied to answer data. It is not an industry standard, and other trackers use other methods.

Share of answer is a proportion, p. With n independent observations, the 95% confidence interval is approximately:

p ± 1.96 × √( p × (1 − p) / n )

The margin is widest when p is near 50% and narrower near the edges. Here it is for four sample sizes:

Independent observations (n)Margin at p = 20%Margin at p = 50%
50±11.1 points±13.9 points
100±7.8 points±9.8 points
200±5.5 points±6.9 points
400±3.9 points±4.9 points

To get to ±5 points, you need about 246 independent observations at p = 20%, and about 385 at p = 50%. Halving the margin takes four times the sample. When p is under about 10%, or n is small, the simple formula is unreliable; use a Wilson interval, which any statistics package computes.

Why queries × runs overstates n

Repeat runs of the same query are not independent. If a query cites you on Monday, it is more likely to cite you on Tuesday. Five runs of one query carry less information than one run each of five different queries. Statisticians call this clustering. The effective sample size is:

effective n = (queries × runs) / (1 + (runs − 1) × ρ)

where ρ (rho) is the correlation between runs of the same query. If runs were identical, ρ would be 1, and five runs would count as one. If they were unrelated, ρ would be 0, and every run would count in full. Answer data sits in between.

You do not need to estimate ρ directly. Score each query first, as the share of its runs in which you were cited. Then share of answer is the average of the query scores, and its standard error is the standard deviation of the query scores divided by √(number of queries). That treats the query as the unit, which is what it is.

Worked example (illustrative)

The numbers are invented to show the arithmetic. Take 100 commercial queries on one engine, five runs each, 500 query-runs in all.

  • 20 queries cite you in all 5 runs (score 1.0).
  • 10 queries cite you in 3 of 5 runs (score 0.6).
  • 70 queries never cite you (score 0).

Share of answer is (20 × 1.0 + 10 × 0.6) / 100 = 26%.

If you treat the 500 runs as independent, the margin is 1.96 × √(0.26 × 0.74 / 500) = ±3.8 points. That is wrong. Using the query scores, the standard deviation is about 0.41, the standard error is 0.41 / √100 = 0.041, and the margin is ±8.1 points. The effective sample is about 113, not 500. The honest report is 26%, with a 95% interval of 18% to 34%.

What this means for the panel

More queries beat more runs. A second run of each query adds information. A tenth adds little. Profound’s July 2026 test found the same. Running 753 prompts ten times a day instead of once tightened the day-to-day spread of its visibility metric by about 11%. For citation share the gain was about 40%. Profound concluded that which prompts you track matters more than how often you run them.

Spread repeat runs across days rather than stacking them in one session. Runs in the same hour share the same index and model state, so they are more alike than runs a week apart.

The practical rule we use:

  1. Score at the query level: each query’s share of runs, three to five runs per cycle, on more than one day.
  2. Report share of answer with its 95% interval, from the query scores.
  3. Report a segment (engine × intent) as a number only when it has at least 30 queries. Below that, list the queries and their results instead.
  4. For a margin near ±5 points on a headline number, plan on 250 to 400 queries in that segment. A reviewed set of 100 gives about ±8 to ±10 points, which is enough to see large moves only.

How do you tell whether share of answer changed?

A change is real when the two periods’ intervals do not overlap, or when a significance test says the difference is unlikely to be noise. Otherwise, report no detectable change. Non-overlapping intervals are a strict test: two intervals can overlap slightly and the difference can still be significant. When they overlap, run the test.

For two independent samples, the two-proportion z-test is:

z = (p₂ − p₁) / √( p̄ × (1 − p̄) × (1/n₁ + 1/n₂) )

where p̄ is the pooled share across both periods, and each n is the effective sample size, not the raw run count. A |z| above 1.96 is significant at the 5% level.

Illustrative example: share of answer rises from 20% to 28%, each period with an effective n of 150. The pooled share is 24%. The z-score is 0.08 / √(0.24 × 0.76 × (2/150)) = 1.62. That is below 1.96, so an eight-point rise on this sample is not a detectable change. It may be real. The sample cannot tell.

When both periods use the same frozen query set, a paired comparison is sharper. Take each query’s score change between periods, and test whether the average change differs from zero: the mean change divided by its standard error, with the standard error being the standard deviation of the changes divided by √(number of queries). Pairing removes the variation between queries, which is usually the largest source of noise.

Record every concurrent change in the same window. A significant difference tells you the number moved. It does not tell you why.

Report the absences

Reasons worth naming: not indexed, wrong page, no passage, no evidence, blocked crawler, or a third party owns the claim. Each reason implies a different fix. An average hides the fix. When a third party owns the claim, the work is in what others say about you, not on your own pages.

Review accuracy in the same pass. An overview that quotes last year’s price is not a win. The readout flags mismatches between the answer and the current offer.

Cadence matters because generative answers move. Weekly for a small volatile set. Monthly for the full universe. A single screenshot is an anecdote, and we do not put anecdotes in the board version of the report. Connecting the number to visits and pipeline is a separate job, covered in AI search attribution.

Rankings stay in the document. They stop being the document. If you want the practice to run on this number, the engagement model is a diagnostic, then a quarter of engineering against the absences it finds.

Common mistakes

  • Reporting a bare percentage. “22%” means nothing without the interval. Add it.
  • Counting runs as independent. 100 queries × 5 runs is not n = 500. Score by query, then compute the interval.
  • Adding runs instead of queries. Past a few runs, extra runs barely narrow the interval. Add reviewed queries.
  • Calling noise a trend. An eight-point move on 100 queries can be sampling error. Test it before you report it.
  • Changing the query set mid-window. A different set is a different population. Start a new baseline and note the version.
  • Mixing definitions. Share of answer, AI share of voice, and citation share use different denominators. Name the one you report.
  • Reporting tiny segments as numbers. Twelve queries give a margin of more than ±20 points. List them instead.

Sources

Bring us the domain.

We will tell you where you are absent, which page is in the way, and what has to be true before a citation is possible.

Request an audit