How to add AI observations to your coverage report
A coverage report shows what has been published. It does not show how ChatGPT, Gemini or Perplexity answer the target group’s questions. Here you will learn how to develop a separate, transparent evaluation module for this, one that sits alongside the clipping and openly states its limits.
pr-geo.com editorial team · 7 min read · As of 9 November 2026
Key points at a glance
- AI observations belong in a separate module, kept apart from clipping and usage data.
- The basis is a fixed set of real customer questions that is tested repeatedly under documented conditions.
- You count brand mentions and source links separately, and the mention rate always comes with the absolute numbers.
- Changes are described without automatically deriving a cause from them.
Why AI observations need a separate module
A clipping documents facts: an article has been published, in this medium, on this day, at this address. An AI answer, by contrast, is a snapshot. The same question may be answered differently the next day, in a different mode or in a different language. If you mix the two on one page, it is easy to give the impression that one caused the other.
A clear separation protects you from this. The secondary study on pr-geo.com divides measurement into three levels, which you can adopt directly as the structure for your reporting:
| Level | What you record | What the level does not show |
|---|---|---|
| Output | agreed articles, dates, topic, format, labelling | whether anyone has read the articles |
| Usage | article views, link clicks, qualified enquiries with data source | whether AI systems use the content |
| AI visibility | answers to a fixed question set under documented conditions | why an answer has changed |
The coverage report covers the first level, web analytics and enquiry tracking the second. The new module deals exclusively with the third. In the report, it therefore gets its own section with its own description of the method.
Step 1: Define the question set
The study suggests defining around 20 real customer questions as a fixed set and testing them repeatedly in each system. “Real” is the key word here. Good sources are conversation notes from sales, messages via the contact form, questions at the trade fair stand and the search terms people already use to land on the website.
Mix three kinds of questions:
- Category questions without brand names, for example asking for a provider of a particular service in a region.
- Problem questions that describe a specific need without suggesting a solution.
- Brand questions that name the company directly and show which facts a system reproduces.
Give each question a fixed ID and save the wording. If you change a phrasing later, it becomes a new question with a new ID. That is the only way to keep runs comparable over months.
Step 2: Document the test conditions
An observation is only as reliable as its documentation. Every run comes with seven details: date, system, search mode, language, region, the verbatim prompt and the sources the system shows. Also decide in advance how often each question will be asked, and stick to that number.
A few practical rules keep interference to a minimum:
- Test with an account that has not been shaped by earlier conversations about the client.
- Start a new conversation for each question.
- Save each answer as an export or screenshot with a timestamp.
- Note whether the system searched the web and which sources it shows.
- Use the same settings and the same device for repetitions.
For your module, this means: before you interpret a missing mention, clarify with the client’s website team whether their pages are accessible to search crawlers. Note the status in the method section of the report.
Step 3: The log fields
The heart of the module is a simple table, and a spreadsheet is entirely sufficient. The only important thing is that each row describes exactly one answer.
| Field | Content |
|---|---|
| Run | ID of the run, for example baseline or repetition 1 |
| Date and time | time of the query |
| System and mode | for example ChatGPT with web search or AI Overviews in Google Search |
| Language and region | language setting and location of the query |
| Question ID and prompt | ID from the question set and exact wording |
| Valid | yes or no, if no with the reason, such as an error message or the answer breaking off |
| Brand mentioned | yes or no |
| Source link to the brand | yes or no, recorded independently of the mention |
| Sources cited | addresses of all sources shown |
| Factual accuracy | correct, partly correct, wrong or not verifiable |
| Evidence | where the export or screenshot is stored |
| Comment | anything unusual, such as outdated details |
The factual accuracy field deserves special attention. It shows whether a system reproduces outdated opening hours, wrong locations or discontinued products. This immediately gives rise to tasks for fact management and editorial work, regardless of how often the brand is mentioned.
The mention rate as a sample metric
Once the log is filled in, you can calculate a sample metric that the study describes as follows:
Mention rate = answers with a brand mention divided by all valid answers in the defined test set.
Three rules keep the figure honest:
- Always state the absolute numbers too: how many valid answers there were and in how many of them the brand appeared.
- State how many repetitions per question went into the calculation.
- Show source links separately, because a mention without a link is something different from a linked reference.
A phrasing template for the report, with placeholders instead of values: “In the run on [date], [number] out of [number of valid answers] answers mentioned the brand. [Number] contained a source link to the website. Each of the [number] questions was asked [number] times.” That way, the client can immediately see what the rate is based on.
With small question sets, a rate fluctuates quickly, and even a single additional mention shifts the value noticeably. That is another reason why the raw figures always belong right next to it.
A monthly report in two parts
State the limits of what it can tell you openly
A good module says just as clearly what it cannot do. These limits belong in every method section:
- AI systems change. A different answer may be due to a new system version and not to the PR work.
- Other activities run in parallel. A website relaunch, ads or the season influence the picture and should be logged as well.
- Small samples only provide indications. Even a comparison with topics that have had no new PR activity is of limited value with a small number of questions that were not randomly selected.
- A publication is not proof of an AI mention. Conversely, a mention does not prove that a particular article triggered it.
According to Google, even a technically flawless page will not necessarily end up in the index or in the AI features of Search1. That too argues for reporting observations as observations.
How to present the module to the client
Present the module as a transparency service and not as proof of success. The client learns how systems answer their target group’s questions, where facts are reproduced incorrectly and which topics are still missing. That is useful even if the mention rate does not change.
The 90-day plan from the study provides a suitable rhythm: a baseline measurement before the first publications and a repetition under the same conditions after around three months. It is best to clarify which customer questions belong in the set as early as the first meeting; the article GEO for PR agencies: the questions that now belong in your consulting offers ideas. A simplified version for businesses that want to start without an agency is the AI visibility self-check.
Frequently asked questions
How often should I repeat the AI observation?
To start with, a baseline measurement and a repetition after about three months under identical conditions are a good choice. More frequent runs increase the effort without solving the basic problem of small samples. More important than the frequency is that the questions and conditions stay the same.
Can I automate the observation with a tool?
Tools can make recurring queries easier. But check whether they record language, region, mode and sources the way your log requires. Without transparent conditions, even a neatly calculated rate loses its value.
What do I do if a system states incorrect facts about the client?
Record the answer with evidence and look for a public source that contains the incorrect detail, such as an old directory entry. Correct what the client can correct themselves, and add missing information on the website or in expert articles. Only the next run will show whether the answer changes as a result.
Does the mention rate belong in the coverage report?
Better not. The coverage report documents publications, while the mention rate describes the answers of AI systems. If both appear in the same section, it can easily look as if one caused the other.
Sources
- Google Search Central: AI features and your websiteaccessed 9 November 2026
- OpenAI: Overview of OpenAI Crawlersaccessed 9 November 2026
Next step
For your client account
The three pr4geo packages compared: PR articles, placements, promo videos and prices for your clients.
Provider disclosure: pr-geo.com is a knowledge portal of NexTao GmbH. pr4geo belongs to our group, which is why we expressly recommend it here. No package guarantees a mention in AI answers. Our principles
