Part 3: AI visibility tools aren’t query logs - and that’s fine.

There’s a familiar objection that comes up whenever teams start measuring AI visibility: “If this isn’t based on real user query logs, what’s the point?”

It’s a fair question - and it comes from a sensible place. In search marketing, query logs are the gold standard. They tell you what people actually typed, at scale, with real intent, real wording, real variation.

But AI visibility isn’t traditional search. And trying to force “query log thinking” onto answer engines leads to the wrong conclusions, the wrong feature requests, and the wrong measurement.

You don’t need query logs to get value from AI visibility. In fact, in most B2B categories, you can build a better measurement system without them.

You just need to accept the right premise:

The myth: “No query logs = no truth”

Let’s name the assumption:

• If I don’t have query logs, I’m guessing.
• If I’m guessing, the output is unreliable.
• If the output is unreliable, I can’t make decisions.

That logic holds if you believe AI visibility tools are supposed to behave like SEO platforms. If the only credible dataset is “what users typed” and your job is to rank for it.

But answer engines change the game:

• Users don’t always type one short query.
• They refine, follow up, and ask in context.
• Two people can ask “the same thing” with completely different words.
• The answer isn’t a list of blue links - it’s a synthesis.

So the question isn’t “do we have query logs?”
It’s:

Are we modelling the decisions that matter - with prompts that represent how buyers actually evaluate options?

If you can do that, you can measure AI visibility in a way that’s actionable.

What AI visibility measurement is actually trying to do

At its core, AI visibility measurement isn’t about traffic prediction. It’s about three things:

1. Inclusion - Are you being mentioned at the moment your buyer asks?
2. Positioning - When you are mentioned, do you show up in the right way?
3. Proof - Does the model cite or imply evidence that supports your claims?

Those three are not dependent on query logs. They’re dependent on good prompts and consistent evaluation.

And this is the key shift:

You don’t need to capture every query.
You need to cover the buyer’s journey states.

Synthetic prompts, real answers

“Synthetic prompt” sounds artificial. Like you’re making up scenarios. Like it’s not real.

But in practice, synthetic prompts are simply designed test cases.

And designed test cases are how we validate everything else in modern systems:

• We don’t wait for production incidents to test resilience - we run chaos tests.
• We don’t wait for customers to discover bugs - we write QA test cases.
• We don’t wait for brand perception to drift - we run message testing.

AI visibility is the same.

A well-designed prompt is a test case for:

• whether the model knows your category
• whether it includes you in the shortlist
• whether it understands your differentiators
• whether your proof exists in the places the model draws from

The prompts are synthetic.
The answers are real.

And because the answers are real, changes are meaningful:

• Your competitor starts appearing more often.
• Your product is described inaccurately.
• The model flags missing proof points.
• Your brand is excluded from shortlists you should be in.

None of that requires query logs. It requires a repeatable set of prompts that represent real decisions.

Why “generic top prompts” are a trap

This is where many tools and teams go wrong.

They build a list like:

• “Best [category] software”
• “Top tools for [problem]”
• “Compare [brand] vs [competitor]”
• “Is [brand] good?”

These prompts feel plausible, but they’re blunt instruments. They create false confidence because they don’t model the nuance that drives answers.

In B2B, buyers don’t decide based on “best tools”. They decide based on:

• constraints (regulated vs unregulated, region, security requirements)
• context (new system vs replacement, integration landscape)
• stakeholder priorities (risk vs operations vs IT)
• buying stage (exploring, narrowing, validating, procurement)

Generic prompts flatten all of that. They tell you whether a model can produce a list - not whether you show up in the situations where you actually win deals.

The buyer journey is the measurement framework

If you’re measuring AI visibility in a way that is useful to marketing and revenue teams, your prompt library should mirror how decisions are made.

A simple version:

1) Frame the landscape (unbranded)

Prompts that discover who the model thinks exists in the category.

• “What types of solutions exist for X?”
• “Who are the main suppliers for X in the UK?”
• “What’s the difference between approach A and B?”

Goal: category inclusion and competitor set.

2) Narrow the shortlist (lightly branded)

Prompts that simulate initial vendor filtering.

• “Which tools are best for teams like [ICP] with [constraint]?”
• “What should I look for when evaluating X for [use case]?”

Goal: are you suggested naturally for the right fit?

3) Deepen evaluation (branded, proof-heavy)

Prompts where buyers look for specifics and risks.

• “How does [brand] handle [security/compliance/integration]?”
• “What are the common pitfalls when implementing [brand/category]?”
• “What evidence should I expect from a vendor claiming X?”

Goal: positioning + proof.

4) Compare and validate (branded, competitive)

Prompts that surface trade-offs.

• “[brand] vs [competitor] for [use case]”
• “When should I choose [competitor] instead?”

Goal: competitive differentiation and objection handling.

The point isn’t that every buyer asks exactly these questions. The point is that every buyer goes through these decision states.

And if your prompt library covers those states, you don’t need query logs to know whether you’re winning or losing.

The real reason people ask for query logs

Often it’s not because they truly need them. It’s because they want:

• reassurance that this is “real”
• coverage that feels comprehensive
• a sense of statistical confidence

That’s understandable. But query logs are rarely available in the first place - especially in B2B.

Even if you had them:

• the volume would be too low for most niche categories
• the phrasing would be too variable to build clean reporting
• the real intent would often be hidden behind internal language
• you still wouldn’t know whether the model included you for the right reasons

So instead of chasing an imperfect dataset, you build a better instrument.

Synthetic prompts are that instrument - if you design them properly.

Here’s how to make synthetic prompts realistic

This is the part that separates “a list of prompts” from an AI visibility measurement system.

1) Write prompts as a specific person with constraints

Constraints produce better answers - and better measurement.

2) Use buyer-stage language, not marketer language

Lift this language from sales calls, discovery notes, RFPs, procurement docs, and customer success tickets.

3) Bake in the decision they’re making next

Prompts should end with a clear action:

• “Give me a shortlist.”
• “Tell me what to validate.”
• “Give me questions to ask vendors.”
• “Tell me what would disqualify a vendor.”

This forces answers that mirror real evaluation behaviour.

4) Include the “why now” trigger

Buyers evaluate differently when:

• a contract is expiring
• a regulator is scrutinising evidence
• a breach happened
• a new exec joined
• an acquisition changed systems

Add a trigger. It makes prompts feel real and makes answers more discriminating.

5) Don’t over-index on volume; over-index on coverage

You do not need thousands of prompts. You need the right ICPs, the right themes/problems, and the right stages. A tight library of 40–150 prompts, properly structured, will outperform 1,000 generic prompts every time.

6) Keep prompts stable, iterate deliberately

If you change your prompts constantly, your trend lines become meaningless. Treat your prompt library like a test suite: stable baseline prompts for tracking, an “experiments” area for new prompts, and versioning when you replace prompts.

7) Score what matters: inclusion, positioning, proof gaps

Avoid “URL-in, score-out” thinking. Focus on: Are we included? Are we described correctly? What proof is missing? Which competitor is being recommended instead? At which stage do we drop out? That’s how synthetic prompts become decision tools.

“But what if this isn’t how people ask?”

They won’t ask exactly like your prompts. That’s not the point.

Your prompt library is a model - like any model. It’s useful if it captures the key variables that change the outcome:

• who is asking
• what they care about
• what risks they’re managing
• what decision stage they’re in

If you capture those variables, slight differences in wording don’t matter.

And there’s a hidden benefit: journey-based prompts make your measurement actionable.

• If you lose in “shortlist” prompts, that’s a category visibility problem.
• If you lose in “proof” prompts, that’s a credibility / evidence problem.
• If you lose in “compare” prompts, that’s a differentiation problem.

Query logs don’t give you that structure. They give you noise.

The takeaway

AI visibility tools aren’t query logs. They’re not supposed to be.

They’re test suites for buyer decisions:

• Synthetic prompts designed around real buying journeys
• Real answers that reveal inclusion, positioning, and proof gaps
• Trends you can measure and improve

If you build your prompt library like a journey model - not a generic keyword list - you get something better than query logs:

you get clarity on where you win and lose answers, and what to fix next.