How we observe AI answers.
FwdLink observes how the OpenAI and Google Gemini search APIs answer selected questions. This page explains what those observations record, what they can tell you and where their limits are. Each protocol keeps its own date; results from different protocols are not merged.
What a result shows · Sample report · Done-for-you delivery details
AI visibility check protocol (from October 20, 2026).
This protocol applies to checks requested in the FwdLink workspace. Each check records its conditions with its results.
- Questions. A first check uses up to 10 questions, in two groups: category questions, where a buyer is choosing and your brand is not named, and brand questions, which name you. Each question records its source: your own, or a draft from a template or a model. Drafts stay labelled until you confirm them and are never counted as search demand. Editing a question creates a new version, so answers to the old wording are not compared with answers to the new one.
- Collection. Each question is asked three times on each engine: the OpenAI Responses API with the web search tool, and the Gemini API with Grounding with Google Search. Each answer records its date, engine, the model requested and the model the provider reported, the market and language, the search settings, whether a search actually ran, the URLs the answer cited, the full answer text and its collection status.
- Market and language. OpenAI accepts an approximate user location; Gemini’s search tool takes none, so for Gemini the market is stated only in the question context. A market or language that a measurement does not support is reported as unsupported. It is never silently replaced with another one.
- Collection status. Each planned answer is waiting, succeeded, failed or not collected. Retries are limited and do not add answers. Failed answers are excluded from rates, shown in coverage and never counted as “not mentioned”.
- Signals. Mentions, citations of your domain, competitor appearances and cited sources are counted separately. A recommendation is judged by a person from the exact sentence. A possible description error is an answer that differs from a fact your team confirmed, shown side by side for review.
- Comparisons. Two checks are compared only when the questions, engines, requested models, repeats, market, language and search settings match. Otherwise the comparison is marked not comparable and the differing conditions are listed. A change in the model build reported by the provider is flagged.
- Usage. Each check records its planned answers, calls, failed attempts and estimated API cost.
Principles 3 and 5 below apply to these checks as well. Comparisons of checks follow the rule above.
Done-for-you improvement pilot protocol (October 19, 2026).
The numbered principles below were written for the human-delivered improvement pilot and still apply to it.
1. Source the questions before observing.
A pilot uses up to 20 questions for one product, in one language. They come first from your real sales objections, enquiries and FAQ. Each question records its source type, a reference, the date it was checked and whether your team confirmed it. Anything drafted by a model or from a template is labelled a hypothesis rather than measured usage or search demand. Private material and personal data are not sent to an AI service.
Questions that name your brand are kept separate from questions where buyers are choosing a vendor. We do not replace questions simply because their answers look better. Changes to the question set or settings mean the before and after are not compared.
2. Repeat the API observations and keep the answers.
The pilot protocol asks each question three times on each of two search APIs, OpenAI and Google Gemini, on three dates: two separate baseline dates and one agreed date after release. For 20 questions that is at most 20 × 3 repeats × 2 engines × 3 dates = 360 planned answers. Search is enabled in the API requests; the archive records the citations actually returned. Search availability does not guarantee that every answer searches or cites a page.
Gemini runs with the Google Search tool enabled. The model decides whether to search for each answer. We retain the answer text and the citations actually returned. These are API observations; they are not the consumer ChatGPT or Gemini apps, and they are not Google AI Overviews or AI Mode.
Our scanner supports a limited set of buyer countries and a fixed buyer role. Where your market or role is not supported, we do not silently substitute another one: we agree an explicit manual observation protocol in the scope and report it separately from the API results.
- Each run records its date, buyer region, question set, requested settings and reported model names, together with the original answers and citations.
- Each report shows successful answers against planned answers. Failed or empty answers are excluded from mention and citation rates and remain visible in coverage.
- Baseline collection uses two different dates. Reusing a cached answer is not counted as a fresh independent observation.
Three repeats help expose variation; they do not establish statistical significance. Model and search behaviour can also change without a visible change in the model name.
3. Keep different signals separate.
- Brand mention rate: successful discovery/alternatives answers that name your brand or an agreed alias, divided by all successful answers in that group. Results are reported per engine. A mention can be neutral or negative.
- Positive recommendations: manually reviewed answers with an explicit positive recommendation. We retain the reviewer and exact supporting quote and show how much of the answer set was reviewed.
- Own-domain citations: answers citing your agreed domain or its subdomains, using the same discovery/alternatives denominator. Competitor mentions and domain citations are recorded separately. A citation does not establish a visit.
- Visits and pipeline: optional customer-supplied GA4/CRM aggregates, with source definitions and reporting periods. Missing data is labelled as not supplied, not zero.
- Enquiries: a valid enquiry is one your system actually received that meets the criteria you approved, excluding spam, duplicates and tests. A click on an email link is not an enquiry. Analytics events, ad figures and received enquiries are never added together.
These are observations from a fixed question set. They are not market share, search volume or a count of actual buyers.
4. Compare only compatible runs.
We compare against an earlier date with the same questions, buyer region, settings and reported models. At least 95% of planned discovery/alternatives observations must have successful matching answers in both runs. Otherwise, the report withholds the change and explains why.
Changes use the matched observations and are expressed in percentage points. The 95% rule is a coverage check, not a 95% confidence level or a significance test. Even a compatible before-and-after change does not prove that a page edit caused it.
5. Label actual ChatGPT and Gemini app checks separately.
The pilot’s observations use APIs. Where the written scope includes a consumer-app check, it captures the first answer to a preselected question in a fresh conversation, with its date, exact prompt, displayed model or mode, search setting and citations where available. If the app does not display a detail, we record it as not shown.
App answers can differ with conversation history, personalisation, account settings, location and search behaviour. A US buying question entered from Korea is not a measurement of a US-located user's session. One missing mention does not establish that your brand is invisible to buyers.
We retain the full answer alongside representative screenshots and record appearances as well as absences. We do not repeat a query until it produces a more useful sales claim. App checks are not added to the API denominator.
6. Use the evidence to choose the work.
A missing AI mention alone does not prove a defect on your website. We check the relevant public page before proposing a change. The work is chosen by setting three things side by side: the buyer’s question, your confirmed product facts, and what the page leaves out or gets wrong. A page is picked because answers point at it and it is missing a fact that was asked for, not because it is weak in general. The change adds facts your team has confirmed; where we cannot source a fact, we ask for it instead of writing one.
Each work item records the URL, evidence, proposed change, approver and the exact version approved. Completion means the published version matches the approved one and the agreed functional tests pass. After release we observe the same questions once more on the agreed date. A before-and-after difference does not establish that the change caused it, and business effects are reported as not assessed unless there is enough data to say more. Ranking, traffic, revenue and AI recommendation increases are not guaranteed.
About the historical research.
The September 2026 exploratory sample used a different protocol from the current protocols. Its archived answers do not retain all model and request settings, and questions were repeated across vendors and engines. Its published rates use only answers to choosing questions (discovery and alternatives); questions about a company’s own facts and head-to-head comparisons are left out.
The done-for-you delivery details page shows what each work item of the human-delivered service includes, from issue to handoff.
Legacy weekly protocol.
Existing analysis orders were written against a weekly protocol of 50 questions on the OpenAI, Google Gemini and Perplexity APIs, three repeats each (450 planned answers). That protocol applies only to those written orders. Perplexity collection is currently unverified and is not part of the improvement pilot.