Skip to content
WaveWise

Frequently asked questions

Questions merchants actually ask, answered in the shortest honest form we have. Open one for the answer; follow it for the mechanism behind it and the limits it comes with.

The AI shopping decision

How does an AI pick one product to name in a buying answer?

When a shopper asks an AI what to buy, the assistant does not return a page of links. It names one product, or a short set, and it gives a reason — and that reason leans on material it could read: your pages, other people's pages, and older versions of both.

The part a merchant can act on is the reason. A position in an answer tells you that something happened; the reason tells you what happened, and it points at the information it came from.

How this works, and what it does not claim

Why can you not see whether AI answers mention your product?

Because each answer is generated for one shopper, inside one private session, and then it is gone. There is no public results page to consult, no referrer trail to read, and no log a merchant can open.

So the honest unit of observation is not how often you are mentioned. It is one real buying question, asked the way a shopper asks it, and one real answer read closely: who got named, for what reason, from which source.

How this works, and what it does not claim

Observing and diagnosing

What does it mean to observe a real AI buying decision?

It means taking one agreed buying question, meeting a real answer to it, and reading the whole of it: the product named, the reason given, the sources that reason leans on, and where they are stale, thin or wrong about you.

It is closer to reading a referee's written decision than to watching a scoreboard.

How this works, and what it does not claim

What makes a diagnosis honest, rather than another conclusion?

A diagnosis is honest when it can lose. It states one reason the answer leaned the way it did, the evidence for that reason, the evidence against it, and what would count as proof that it was wrong.

Anything that cannot lose — a summary, a hunch, a generated list of suggestions — may still be useful, but it cannot be checked, and this loop only ships what can be checked.

How this works, and what it does not claim

One controlled change

What counts as one controlled change to a product page?

One edit to information you already control — a claim on the product page, a spec table, a piece of explanatory content — written out in full before anything moves, approved by you, shipped by you, and undoable afterwards.

Controlled describes your control, not ours. The proposal is ours to write; whether anything happens is yours to decide.

How this works, and what it does not claim

Why change only one thing at a time?

Because afterwards you have to be able to read the result. Ship several edits at once and whatever happens next belongs to all of them and to none of them — the money is spent and the learning is gone.

One change keeps the question answerable: this edit, that asset, that window. Even when the honest answer is that nothing can be attributed yet, you know what the answer is about.

How this works, and what it does not claim

Verifying and learning

Why are shipped and seen two separate questions?

Because they come apart in practice, and they are answered from different evidence. Execution — did the approved action happen, in full, on the asset it named — is answered by looking at your page. Exposure — did the environment we care about have a chance to see it — is answered by observing that environment, and often the answer is unknown.

A change can be live and unseen. Treating live as seen would quietly promote every shipped edit into an observed one, and the whole report would inherit that mistake.

How this works, and what it does not claim

Is an inconclusive result bad news?

No — it is an answer, about attribution. It says the change was made, and the evidence needed to credit it or rule it out has not arrived: often because exposure could not be confirmed either way.

It is deliberately not called a failure, because nothing failed: the mission completed, the verification stayed open, and the report says exactly that.

How this works, and what it does not claim

The four-week pilot

What does the four-week pilot ask of you?

Four things, none of them heavy: agree the one buying question that matters, point us at the public material you control, approve or decline the one proposed change, and afterwards tell us what you saw.

Everything else in the window — observing, diagnosing, writing the mission, verifying, grading — is ours to do and yours to read.

How this works, and what it does not claim

What does the pilot application ask, and what happens to your answers?

Nine questions, and the whole list is readable on the application page before you answer anything. They establish the shape of a workable pilot: what you sell, where the public material lives, which buying question matters, and whether you can share what you saw afterwards.

Handling is deliberately boring: a person reads the answers, nothing is decided about you automatically, nothing is sent until you press submit, and you can ask us to delete an application — we confirm the request came from you first.

How this works, and what it does not claim

What these answers claim

They explain how something works. None of them reports a result, promises one, or carries a number — and each page states its own limits beside its own answer, where they can be read together.