Why can AI visibility not be ranked?
An AI answer is generated, not listed. Two people asking the same question minutes apart can receive different sources, the answer varies with account, location, and session, and no system publishes a position for a cited source. There is no ordinal to track, so a report that shows a rank for an AI answer has inferred it. ftes.ai treats that inference as the point where AI visibility reporting usually stops being honest.
What does exist is an observation: on a given date, for a given prompt, in a given assistant, a brand was mentioned or it was not. That observation is real, repeatable, and the only durable unit available.
Step one: fix the prompt set before measuring anything
A prompt set is the list of questions a buyer would actually type, written once and then frozen. The Search Visibility FTE builds one per property from the questions its targets are about, and the manager approves it. Freezing matters more than choosing well: a set that gains and loses prompts between runs produces a series where every movement is explained by the set rather than by the site. Any prompt added later starts its own series rather than joining the existing one.
A workable set is small and specific. Twenty to forty prompts that name the category, the problem, and the nearest alternatives will tell a manager more than several hundred paraphrases of the same question.
Step two: count observed mentions, with their date
A run asks every prompt in the set, records the answer, and marks each prompt as a mention or not a mention for the brand, with the date and the assistant recorded alongside. The result is a count out of a known denominator: mentioned in some number of the fixed prompts, on that date, in that assistant. That count is comparable to the previous run because the denominator did not move, and it is honest because every part of it was observed.
The count is reported per assistant rather than blended. Assistants differ in their sources and their willingness to name brands, so one combined figure hides the only comparison worth making.
Step three: mark everything else unmeasured
Anything not observed in a run is reported as unmeasured, and unmeasured is a visible state in the workspace rather than a blank that gets filled in later with a guess. A prompt that could not be run is unmeasured. An assistant the property has no connector for is unmeasured. A period before the prompt set existed is unmeasured, not zero. The rule in the product is that if the backend cannot measure it, the interface does not show a number for it.
This is the step most reporting skips, and skipping it is what turns a measurement into a claim. A dashboard with visible gaps is more useful than a complete one that is partly invented.
What does the resulting series actually show?
It shows presence over time against a stable question set: whether the brand is being named on the questions it decided matter, and whether that is moving. Compared against the content the site published between two runs, it supports a narrow, useful claim — the pages published in that window were followed by mentions appearing on these prompts — and refuses a wider one. The Search Visibility FTE reports it that way in the Performance tab, with the runs and their dates attached as evidence.
That narrow claim is enough to decide what to write next, which is the decision the measurement exists to support.
What the method refuses to claim
It refuses four things. It does not report a rank, because none exists. It does not report a share of voice, because the denominator would be every possible question rather than the fixed set. It does not attribute revenue to a mention, because the path from an assistant answer to a purchase is not observable from the publisher side. And it does not promise that a mention will persist, because the answer is regenerated each time and the sources move.
Each refusal costs a chart that a buyer might want to see. Each one is also a claim that would fail the moment someone checked it, which is the more expensive outcome.
How often should a prompt set be run?
Often enough that a change in the site can be related to a change in the series, and rarely enough that each run is worth its cost in tokens. A weekly or fortnightly cadence suits most properties, with the cadence itself held constant because changing it changes the shape of the series. The runs are scheduled work in ftes.ai and are metered like any other AI work, so the cadence is a budget decision the manager makes explicitly rather than a default that quietly accumulates spend.
One discipline matters more than the cadence: never re-run only the prompts that did well. A partial re-run produces a number that looks like the full one and is not.