A visibility score tells you whether your brand showed up in an AI answer. It never told you why, or what the engine was actually looking at when it decided what to say. That is the gap this update closes: Traceten now shows the web searches ChatGPT and Claude ran on their way to an answer, not just the answer they landed on.
An answer is the end of a research process
When ChatGPT or Claude answers a question with web search turned on, the model does not simply recall a fact. It runs its own searches first, reads what comes back, and writes the answer from that. Two brands can get the identical prompt and the identical final answer, and still have arrived there through completely different research: one surfaced through a review roundup, the other through a head-to-head comparison nobody on the team had thought to check for.
What one visibility run actually does
Illustrative: the shape of the process, not a specific recorded run.
Tracked prompt
The exact question you asked Traceten to watch, run on its normal cadence.
Engine searches
ChatGPT or Claude runs its own web searches, not your prompt verbatim.
Engine reads results
It reads whatever those searches turned up, which may or may not include you.
Answer is written
The final answer is built from that research, visible to the person who asked.
Until now, Traceten reported the last box in that chain and discarded the rest. You could see that a prompt resolved favorably or not, but not the path the engine took to get there. Share of voice without the reasoning behind it is a result with the method stripped out.
What actually shows up now
Three things changed, and each answers a different question.
Before and after
| Question | Before | Now |
|---|---|---|
| What did the engine search for on this run? | Not shown | Listed on the run's detail view, in the order the engine ran them |
| Does this prompt get researched the same way every time? | Not shown | Recurring searches surface on the prompt itself, across every run |
| Which searches are costing us the most, across every prompt? | Not shown | Ranked on a dedicated Searches tab, by type, phrase and gap |
The per-run view and the per-prompt recurrence view answer "what happened here." The Searches tab answers a different question: across everything you track, which searches turn up again and again, and which of them are quietly going to a competitor instead of you.
The gap is the point
A gap is a search the engine ran, on a prompt you are already tracking, where it surfaced a competitor and did not surface you. That is the single most actionable row in the product: it names a real question, a real search, and a real reason you were not the answer.
Say you track a broad, category-level prompt. Buried in the searches behind it is a narrower one, a direct comparison against a specific competitor, that the engine runs every time and that reliably turns up that competitor's page and not yours. On its own, your category-level score might look fine. The gap underneath it is where the actual leak is, and it was invisible until the search itself became visible.
A gap can become its own tracked prompt, but only when you confirm it. Nothing enrolls itself. Click "Track as prompt" on the Searches tab, edit the prefilled text if you want to narrow or widen it, and it starts running on its own cadence alongside everything else on AI visibility. The competitor set you never chose already made the case that an AI engine's own research can surface rivals your pricing page never mentions. Seeing the search that produced that competitor, instead of only the fact of their appearance, is what turns a number on a dashboard into something you can actually act on.
Built to stay honest about what it does not know
Two rules shaped how this surfaces, and both exist to stop a gap in the data from reading as a gap in your visibility.
First, an empty state is driven by what the selected date range actually holds. A range with no scans shows an empty state that says so, never a zero that reads like the engines came back with nothing. Second, an engine that does not report its searches for a given run says exactly that, rather than rendering a zero indistinguishable from "it searched and found nothing." Those two states look nothing alike on screen, because they mean nothing alike.
Why this took a second pass
The underlying searches have been captured since the API started recording them. The harder problem was never storage, it was presenting a phrase an engine generated with care: never logging it anywhere that could leak it, including our own error monitoring. The fix widened the scrubbing on every UI interaction event the product sends, not only this one.
How to use it this week
- Open a tracked prompt that matters and look at its latest run. Read the searches the engine actually ran, not just the answer it gave.
- Switch to the Searches tab and sort by gap. Anything near the top is a search where a competitor is winning a research step you did not know existed.
- Pick the gap that is closest to a prompt you would actually act on, and confirm it as its own tracked prompt rather than leaving it buried inside a broader one.
- Watch it on its own cadence from there. A gap that recurs is worth the content or page you have been putting off; one that was a fluke will say so by not coming back.