How to measure AI search visibility

What counts as a measurement

You measure AI search visibility by running a fixed set of buyer questions against a named AI answer surface, many times over a period, and counting how often the answers mention, recommend and cite your brand. The result is a set of rates with a sample size, tracked over time, per surface and per market. Anything less is an anecdote.

A screenshot of one answer is not a measurement. It shows what one model produced once, for one person, in one location, with whatever search results it retrieved that minute. Ask the same question again and the brands named can change. OpenAI documents that its APIs are non-deterministic by default, and that even with a fixed seed "determinism is not guaranteed". Web-grounded answers add a second source of variation: the search results behind them move every day.

So the unit of measurement is not an answer. It is a rate over many sampled answers, with the conditions recorded: which surface, which model, which location, which day.

Choose prompts that reflect real buyer questions

The prompts you track decide what you learn. If they are your own product names, you will find that assistants know your product. That is not the question. The question is whether a buyer who does not know you yet gets your name in the answer.

Build the set from questions people actually ask an assistant at each stage: what a category is, which options exist, which one fits a constraint, what it costs, whether it is available in their country. A payroll software company in Mexico would track prompts like "which payroll software complies with CFDI in Mexico" and "best payroll system for a company with 50 employees in Mexico", not "is our product good".

• Write them in the market's language, the way a local buyer would phrase them, not as translations of an English keyword list. Vocabulary, regulations and competitors differ by country; see how AI answers differ by country.
• Group them by intent (category questions, comparison questions, fit questions) so you can read rates per group rather than one blended number.
• Keep the set stable. Changing prompts mid-series breaks the comparison. Add new ones as a new group with its own start date.

Mention rate, recommendation rate, citation coverage

Each prompt is run repeatedly. Each run is one observation. From the observations you compute three rates, and they answer three different questions.

• Mention rate: the share of answers in which your brand is named at all. It tells you whether the assistant knows you exist in this context.
• Recommendation rate: the share of answers in which your brand is presented as an option the buyer should consider, not just named. A mention inside "alternatives you might have heard of" is not a recommendation.
• Citation coverage: the share of answers that link to a page you own as a source. Web-grounded surfaces expose this: Google's documentation says its AI features surface links to sources, and the Gemini API's search grounding returns the cited URLs alongside the answer.

A brand can be mentioned often, recommended rarely and cited never. Each gap points to a different fix, which is why one blended "visibility score" hides more than it shows.

Sample size and uncertainty. A rate from four answers means little. If a prompt was run 40 times and your brand was recommended in 12 of them, report "12 of 40" or "30% on 40 answers", and treat it as an estimate with a range around it. As the count grows the range narrows. Any tool that shows a rate without its sample size is asking you to trust a number you cannot check.

Per surface, per market, and who else is in the answer

Surfaces are not interchangeable. An answer from OpenAI's web-grounded API, one from Gemini with Google Search grounding, one from Perplexity's web-search API and an AI Overview on a Google results page are produced by different models over different retrieval. Report each as its own series, with the provider named. Do not average them, and do not call an API result "ChatGPT": what a person sees in a consumer app is a different thing, and an API measurement does not stand in for it.

Markets are not interchangeable either. The same prompt asked from Mexico and from Colombia, in each country's Spanish, is retrieved from different sources and answers with different brands. Measure each market you sell in as its own series. If you are starting with one, the Mexico market page shows what a single-market baseline looks like.

Track the competitors and the sources, not only yourself. Record every brand that appears in each answer, so you can see who is recommended when you are not, and record every cited domain, so you can see which publications, directories and comparison sites the assistant leans on in this market. Those lists are where most fixes come from: a directory that lists the competitor and not you, a review site with outdated facts about your product, a category page you never wrote in the local language. The guide on how to appear in AI answers covers what to do with them.

Telling a real change from noise

Because rates move on their own, the hardest part of measurement is knowing when something happened. Take a made-up example: a recommendation rate that goes from 25% to 35% between two weekly runs of 40 answers each is inside the range you would expect from sampling alone. A jump on the day a provider swapped its model is a change in the instrument, not in your visibility.

A workable discipline looks like this:

1. Record a baseline before you change anything: several weeks of runs, per surface and market, so you know how much the rates wobble at rest.
2. Log the ship date of each change you make, with what was changed and where.
3. Set an observation window in advance, long enough for the change to be crawled and retrieved, and compare the window against the baseline, not against the single best week.
4. Note provider changes. When a model version or search behaviour changes inside your window, flag the comparison instead of trusting it.
5. Use careful language. "Likely positive", "no clear change" and "inconclusive" are honest results. An improvement after a change is evidence that it helped, not proof, because nobody controls what an assistant answers.

How VozRadar measures

VozRadar is built around the method above. For a chosen market it discovers localized buyer prompts, and after you approve them it runs them weekly on named answer surfaces: OpenAI's web-grounded API, Gemini with Google Search grounding, Perplexity's web-search API, and Google AI Mode and AI Overviews captured from search results. Each answer is stored as one observation, labelled with the surface, model and location that produced it; an API result is labelled as such, not as the consumer app.

Mention rate, recommendation rate and citation coverage are reported as probabilities with their sample size and an uncertainty range, never as a position, and every aggregate links back to the answers behind it. Competitors and cited sources are recorded per market. When a fix ships, the Experiment Ledger holds the baseline, the ship date and the observation window, and reports the outcome as evidence rather than proof. The methodology page gives the model, the thresholds and a worked example. VozRadar is prelaunch with a waitlist; the about page describes what it does and does not claim.