An AI visibility report needs two boundaries: the period it describes and the time at which its evidence was closed. Answers can arrive late, failed captures can be recovered, and reviewers can correct a brand classification after a report has been downloaded. Keep the original export, record the revision, and show what changed in both the numerator and denominator. A later report can be more complete without proving that the brand became more visible. The practical task is to distinguish new market observations from changes to the reporting record.
The Monday number that changes on Wednesday
A marketing manager downloads a weekly report before a sales meeting. Two days later, the dashboard shows a different recommendation rate for the same week. Neither number has to be fabricated. The first export may have omitted delayed observations; a reviewer may have identified an unrelated company with the same name; a collector may have delivered an answer after the reporting deadline.
The problem starts when the report contains only a date range and a percentage. The reader cannot tell whether the system observed a change in AI answers or finished processing evidence it already had.
This distinction exists in other reporting products. Google documents preliminary data in its Search Console Performance report and explains that the newest figures may change while collection continues. That is a property of that Google report, not a promise about any AI monitoring vendor's processing schedule. The useful lesson is the explicit status of the data. Google's Performance data guidance.
For AI visibility, define your own reporting contract rather than assuming that every tool means the same thing by “last week.”
Three timestamps answer three different questions
The observation time identifies when the answer was actually produced or observed, using the strongest timestamp available. The ingestion time identifies when the monitoring record entered the reporting system. The report cutoff identifies which records and review decisions were included in a particular export.
They can differ. A response observed on Sunday may be ingested on Monday. A classification made on Tuesday may correct a Sunday observation. Neither event means the platform issued a new Sunday answer on Tuesday.
Do not manufacture observation time from a convenient file name. A file created on Monday can contain a Sunday answer, but the earlier date needs supporting evidence. If the answer's original time is unknown, preserve that uncertainty. An answer newly requested on Tuesday belongs to Tuesday's observation context, even if it repeats Sunday's question.
Timezone also needs an owner. A report using calendar weeks in London and another using UTC can include different observations around midnight. Store precise timestamps with offsets, then state the business timezone used to assign observations to reporting periods.
| Time or status | What it establishes | What it cannot establish alone |
|---|---|---|
| Original answer timestamp or contemporaneous capture | When the recorded observation occurred | When every other user would see that answer |
| Record ingestion time | When the reporting system received the record | The original answer's production time |
| Review timestamp | When a classification was accepted or corrected | A new recommendation by the AI platform |
| Report cutoff | The evidence available to a specific report version | That all scheduled observations completed |
| Export creation time | When a file was generated | That its underlying data was final |
A worked example: improvement in completeness, not visibility
Consider a fictional weekly study with 120 scheduled observations. At the Monday cutoff, 101 ordinary answers are available, two attempts have failed, and 17 remain pending. Eight available answers contain a recommendation that passes the study's entity and reason checks.
The report can show 8 qualifying recommendations in 101 valid answers, or 7.9%, alongside 101 completed answers from 120 scheduled observations. The completion count and recommendation rate answer different questions. Neither missing nor failed observations should silently become negative recommendations.
On Wednesday, the reporting pipeline delivers nine delayed records. Each has evidence that the original observation occurred inside the reporting week; these are not nine fresh Wednesday queries. Two contain qualifying recommendations. There are now 110 valid answers, two failed attempts and eight pending observations.
The revised weekly figure is 10/110, or 9.1%. It is reasonable to publish that more complete result with a revision note. It is unreasonable to describe the movement from 7.9% to 9.1% as a Wednesday improvement in the brand's AI visibility. The underlying observation period has not changed; the evidence available to the report has.
If the nine records lacked a reliable original date, they could not be assigned to that earlier period simply to close the gap. The example depends on traceable event times, not optimistic backdating.
Give late records a defined treatment
A cutoff policy should be short enough for the person preparing the report to apply without interpretation.
- Fix the period and timezone. State the beginning and end of the observation window and whether the end is inclusive. Avoid a bare label such as “October” when the system collects across timezones.
- Declare the cutoff. Record the time through which ingested evidence and accepted reviews were included. Identify preliminary reports explicitly.
- Count the collection states. Show planned observations, valid answers, answers without the expected feature, failures and pending records using the study's agreed categories.
- Preserve the exported version. Keep its underlying rows, classifications and calculation rules. A dashboard screenshot alone cannot explain a later revision.
- Append late evidence with provenance. Record the original observation time, arrival time, raw answer and reason for inclusion in the earlier period.
- Issue a visible revision. State the old and new counts, the affected records, the reason, and whether a business conclusion changes.
The policy can allow one scheduled revision or several. What matters is that readers know which version they have and why another version differs.
Corrections are not the same as late arrivals
A late arrival adds a previously unavailable observation. A correction changes the interpretation or handling of an existing observation. Keep those actions separate.
For example, an answer might name a product whose name resembles your company. A reviewer originally marks it as a recommendation, then discovers that it belongs to another vendor. The correction should retain the original answer and the former classification, with a reason for the new decision. It should not look like the platform withdrew a recommendation at the time of review.
Likewise, a source link may be genuine while failing to support the recommendation's reason. A later source review can change whether the recommendation qualifies under your acceptance rules. The report should identify that as a review correction, rather than replacing the original answer or quietly removing an inconvenient record.
Freeze the definition used for the published period. If the business changes its qualification rules, calculate a separately labeled restatement under the new definition. Otherwise a stricter reviewer can create an apparent decline and a looser reviewer can create an apparent gain.
Missing values need their own meaning
An empty field is easy to turn into zero during export. That can create a false claim.
Suppose a search result did not trigger an AI Overview. That is different from an AI answer that appeared and did not recommend the brand. A login failure is different again. A missing citation panel does not prove that the system used no sources.
Google's Search Console guidance provides a useful, specific warning: some unavailable values displayed with symbols become zeros in downloaded data. Before applying arithmetic to any export, check how its producer encodes missing or unavailable values. Do not assume that another product follows Google's convention. Search Console export behavior.
For your own monitoring, write a data dictionary. A blank recommendation field can mean “not reviewed”; false can mean “reviewed and absent.” If a file format cannot preserve that distinction, include a separate status column.
Ask a vendor to reproduce one report
The strongest procurement exercise is small. Choose a dated export and ask the provider to reconstruct one headline number from its underlying observations. Then ask what would happen if a delayed answer arrived tomorrow or a reviewer corrected one classification.
A satisfactory explanation identifies the included records, their versions and the report's cutoff. It also explains whether the live dashboard changes retrospectively and how the customer can retain the original view. A claim that the dashboard is “real time” does not answer these questions.
This is relevant when evaluating Semvi by Xindar. Its product owner has confirmed full-answer and citation-URL export and retention for at least one year, extended with the agreed service term. Those statements do not establish a particular snapshot, revision-history or cutoff feature. Include those requirements in an actual demonstration and contract discussion rather than inferring them from retention alone.
Retention keeps material available. Reproducibility requires knowing which version of that material produced the reported result.
Close the report without closing the evidence
A closed report is a named version, not a claim that nothing can ever be corrected. Keep a stable copy for business decisions and a visible path to later corrections.
The cover note can be simple: “Observations from Monday 00:00 through Sunday 23:59 in the stated timezone; evidence ingested and reviewed through Tuesday 12:00; version 1; outstanding observations listed separately.” A revision should say which of those facts changed.
For a B2B export marketing programme, connect the report to a decision: maintain a page, correct a claim, investigate a market gap or collect more evidence. If a small reporting revision changes that decision, explain why. If it does not, there is no need to manufacture a success story from the movement of a percentage.
Questions buyers ask
Should a monthly report be permanently frozen?
Preserve the version used for decisions. Allow documented corrections or restatements without overwriting that original. A fixed artifact and an accurate correction record can coexist.
Can a recovered answer be counted in its original week?
Only when its original observation time and identity are supported and it meets the study's rules. A newly generated answer to the same question is a new observation, not a repaired historical one.
Does one year of retention make a report reproducible?
No. You also need the included records, classification version, calculation rules and cutoff. A year of mutable dashboard data may still fail to reproduce an earlier export.
Should pending observations count as brand misses?
Keep pending and failed collection states visible. They do not establish what an unavailable answer said. Report completion separately from the rate calculated on eligible observations.
What should trigger a revised customer report?
Use a policy agreed before seeing the results. Material factual corrections, changed qualification decisions and a scheduled completion update are reasonable candidates. The policy should apply to unfavourable revisions as well as favourable ones.
Sources and scope
The Google source describes its own reporting behavior. The cutoff procedure, fictional arithmetic and vendor acceptance questions are proposed operational methods for AI visibility monitoring. They are not claims that all platforms expose identical timestamps or support identical reporting controls. Related reading: tracing one AI answer from screen to export.