How to Use Answer Engine

QueryBurst Answer Engine is designed for periodic investigation rather than continuous surveillance. This section covers who should create personas and journeys, the simplest way to start, how to scale to more complex setups, recommended cadence, and how to handle drift over time.

Who should create the personas?

Not necessarily the SEO team.

Persona definition belongs with whoever understands the customer.

Depending on the organisation, that might include:

  • product marketing
  • product
  • brand
  • customer research
  • sales
  • customer success
  • content
  • SEO
  • strategy

SEO can contribute search behaviour, retrieval analysis, content, and evidence.

But "who is our customer?" is not fundamentally an SEO question.

Who should model the buyer journeys?

Again, this may be cross-functional.

Product marketing might understand buying stages and objections.

Sales may understand questions that appear late in the deal.

Customer success may know why customers churn or switch.

Product may know the actual use cases.

SEO can then inspect how AI research behaves through those journeys and identify where the company's web presence helps or fails.

The journey modelling and search diagnosis do not necessarily have to be owned by the same team.

What is the simplest way to use Answer Engine?

Create one persona and ask it questions. QueryBurst is designed to be as simple or as deep as you need it to be.

For example, create a persona representing an environmentally conscious 45-year-old parent and ask:

"What car should I buy?"

The interesting part is not only the final answer.

You can inspect:

  • the model's initial answer
  • what it chose to research
  • which fan-outs were created
  • which sources were retrieved
  • what evidence survived

Then change the persona and run the same question again.

Even at this simplest level, you can see how user context changes the research path.

What is the more advanced way to use Answer Engine?

Model complete buyer journeys.

A practical setup might be:

  • 5–10 important personas
  • several meaningful journeys for each persona
  • branches wherever buyer behaviour could plausibly diverge

Some journeys might begin at discovery.

Others might begin at comparison or purchase.

There is no requirement that every journey starts at the top of the funnel.

The goal is to cover the decisions that matter.

How many personas and journeys should I create?

There is no magic number.

A smaller company might start with five personas and 5–10 journeys for each.

A more complex organisation could model considerably more.

Because journeys can branch, you do not need a separate starting conversation for every possible variation.

Start with the commercially meaningful ones and expand where the investigation reveals useful questions.

Do I need clickstream data to know what multi-turn conversations people have?

No.

Real conversation data would obviously be useful where available.

But you do not need an exhaustive dataset of every real conversation before you can model buyer behaviour.

That would be equivalent to saying businesses could not create buyer journeys until they had observed every possible customer path.

The goal is to build useful models of likely behaviour, not claim exhaustive coverage.

How often should I run buyer journeys?

Probably much less frequently than traditional prompt tracking.

Answer Engine is designed for investigation rather than constant surveillance.

A sensible cadence might be:

  • monthly
  • after meaningful changes to your website
  • after important product or pricing changes
  • following major changes to models or retrieval systems
  • when the competitive environment changes

The question is whether something meaningful in the system is likely to have changed.

Not whether the visibility line moved by 0.8 points on Tuesday.

What happens if I change a persona?

You changed the experiment.

Even if the visible user message remains identical, changing relevant persona context changes the effective input.

That means the old and new result should not automatically be treated as perfectly comparable observations from one unchanged test condition.

This is an important distinction between investigating runs and blindly maintaining one continuous visibility series.

Why does that matter for persona-based prompt tracking?

Suppose a tracker repeatedly runs:

"What car should I buy?"

with Persona A attached.

Then someone edits Persona A from "mother of three" to "mother of four", or changes her budget, location, priorities, or environmental concerns.

The visible prompt has not changed.

But the model input has.

If the same historical visibility chart simply continues across that change, what exactly is the line measuring?

Context improves realism.

But it also makes simplistic longitudinal measurement harder, not easier.

How does Answer Engine handle drift?

Answer Engine gives you several places to look for change.

A rerun may reveal that:

  • the pre-retrieval answer changed
  • the fan-outs changed
  • the retrieval targets changed
  • different sources entered the pool
  • the same sources were scored differently
  • different evidence survived
  • the final recommendation changed
  • an earlier turn changed enough to alter the downstream journey

That is much richer than simply observing that a final visibility score moved.

Does conversation drift compound?

Yes.

If turn three changes materially, a realistic user may ask a different question at turn four.

That means the journey itself can diverge.

This is one of the reasons multi-turn analysis matters.

A collection of independently rerun prompts cannot model that dependency because each prompt has been detached from the answer that supposedly preceded it.