Can a merchandiser pin or boost a product?

Not today. There is no merchandiser override in the ranking path, and we are not going to describe one in the present tense because it is on a roadmap. The engine has internal boosts for persona and price fit, but those are how it scores rather than controls anybody can reach. If pinning is a requirement for you, this is the honest moment to say so.

Then what is the point of the console today?

It holds the things the engine depends on: the catalogue and attribute schema it ranks against, the persona tags, the holdback percentage, and the decision record. Those are upstream of every ranking. It is a smaller surface than the name suggests, which is why the name is followed by this list rather than a feature grid.

Why is the holdback on by default?

Because a runtime with no control arm produces numbers nobody should act on, and that includes anything we would report to you. Making it opt-in would mean most deployments could never be evaluated, which is the situation we built this company to argue against.

When will overrides ship?

We are not going to give you a date, for the same reason we will not give you an uplift figure: we would be guessing, and a guess in a sales conversation becomes a commitment. What we will do is tell you what exists when you ask, which is what this page is.

Can we still control what shoppers see?

Yes, upstream rather than at ranking time. Persona tags, the attribute schema and what is in the catalogue at all are all under your control and all feed the ranking. What you cannot do yet is reach into an individual result and move one product.

Merchandising Studio

The console, and an honest list of what it cannot do yet.

Where you manage the catalogue the engine reads, set how much traffic is held back, and pull the record behind any ranking decision. Overrides are not built yet, and this page says which ones and why rather than leaving you to find out in a pilot.

01
Open a shelf
the catalogue the engine actually reads
02
Inspect a ranking
any result, any session, any time
03
Read the record
the factors behind that exact position
04
Set the holdback
how much traffic never sees the engine
05
Override a position
not built, and dated below

Four of these exist today. The fifth is the one every merchandiser asks about first, which is why it is on the screen rather than left out of it.

Where you are

A control surface is the first thing a merchandiser asks for and the last thing most vendors are straight about.

4
Built and in the console
catalogue, persona tags, holdback, decision record
2
Named here, not built
position overrides and scheduled merchandising
5%
Held back by default
switching measurement off has to be deliberate

Counted from the codebase rather than the roadmap. The second figure is the one most console pages leave out.

The question always arrives in the same shape. If the engine ranks the catalogue, what happens when a buyer needs a product up for a reason the engine cannot see: a supplier commitment, an overstock, a range launch on Thursday. That is a fair question and the honest answer today is that you cannot pin it.

We could describe the roadmap in the present tense and nobody would catch it until a pilot. That is how vendors end up with a checklist that matches the brief and a product that does not, and it is a worse outcome for us than losing the deal now.

What the console does hold is the part the engine depends on: the catalogue and its attributes, the personas products are tagged against, the share of traffic held back, and the record behind any individual decision. That is a real surface, it is just a smaller one than the name suggests.

If we described overrides we have not built, you would discover it in a pilot. Finding out here costs us a conversation and costs you nothing.

Why this page reads oddly

Most console pages describe the console somebody is planning to build.

There is a cheap version of this page and an expensive one. The cheap one costs us a conversation.

Described, then discovered

A feature list written from the roadmap.

The gap surfaces three weeks into a pilot, with a team already committed and a merchandiser explaining to their manager why the thing in the demo is not in the product.

Costs the buyer a quarter. Costs the vendor the account.

Listed before you ask

A feature list written from the codebase.

Overrides are not built. Scheduled merchandising is not built. Both are named here, with what exists today beside them, so the pilot starts from an accurate picture.

Costs us a conversation. Costs you nothing.

What it looks like

What the console holds today.

Catalogue and attributes, personas, the holdback percentage, and the decision record.

What the console holdsVerified

Built

Catalogue and attributes
Persona tags
Holdback percentage
Decision record

Not built

Boost, bury, pin
Rule simulator

The second list is why you can trust the first.

What happens

What you can do in the console today

Catalogue
01
Manage what the engine reads
Products, categories, brands and the attribute schema behind them. This is upstream of every ranking: an attribute the catalogue does not carry is one no surface can order on.
Control
02
Set the holdback
The share of sessions that never see the engine, stable per session. It is an organisation setting, it defaults on, and it is what makes any later comparison possible.
Audit
03
Pull a decision record
Any ranked response carries an id and the four factors behind each score. When somebody asks why a product placed where it did, the answer is retrievable.

What you get

What the console gives you

Catalogue and attribute management
The products, categories, brands and attribute schema the engine ranks against, in one place, with the taxonomy that the audit measured.
Persona tagging
Which products are associated with which personas, which is one of the four ranking factors and the one a merchandiser has the most useful opinion about.
Holdback control
What share of traffic never sees the engine. On by default, because a runtime without a control arm produces numbers nobody should act on, ours included.
The decision record
Per-request id, the factors, and what was shown. Enough to answer why a product ranked where it did without reconstructing it from logs.

Before you commit

What is built, and what is not

What this doesKeep the holdback on by default, so switching measurement off has to be a deliberate act

Show latency as a live distribution rather than a single median, which hides the tail

Change nothing on your storefront: this console configures and reads, it never publishes

Work without engineering involvement, because nothing in here deploys anything

What it does not doBoost, bury or pin a product. Not built. There is no merchandiser override in the ranking path today, and the engine's internal boosts are not reachable as controls

Simulate a rule change before it goes live. Not built, and it depends on overrides existing first

Run an A/B test from the console. The holdback arm exists and is what a test would be built on, but the test tooling is not there

Report attributable sales. That requires a live experiment we have not run, and a number without one would be invented

Questions

The ones that decide it.

Can a merchandiser pin or boost a product?: Not today. There is no merchandiser override in the ranking path, and we are not going to describe one in the present tense because it is on a roadmap. The engine has internal boosts for persona and price fit, but those are how it scores rather than controls anybody can reach. If pinning is a requirement for you, this is the honest moment to say so.
Then what is the point of the console today?: It holds the things the engine depends on: the catalogue and attribute schema it ranks against, the persona tags, the holdback percentage, and the decision record. Those are upstream of every ranking. It is a smaller surface than the name suggests, which is why the name is followed by this list rather than a feature grid.
Why is the holdback on by default?: Because a runtime with no control arm produces numbers nobody should act on, and that includes anything we would report to you. Making it opt-in would mean most deployments could never be evaluated, which is the situation we built this company to argue against.
When will overrides ship?: We are not going to give you a date, for the same reason we will not give you an uplift figure: we would be guessing, and a guess in a sales conversation becomes a commitment. What we will do is tell you what exists when you ask, which is what this page is.
Can we still control what shoppers see?: Yes, upstream rather than at ranking time. Persona tags, the attribute schema and what is in the catalogue at all are all under your control and all feed the ranking. What you cannot do yet is reach into an individual result and move one product.

The catalogue work comes first anyway.

The console is most useful once the shelf underneath it can support decisions. That starts with one category export and no integration at all.

Request a Decision Audit

If overrides are a hard requirement, tell us on the call and we will say where that leaves us.

The console, and an honest list of what it cannot do yet.

A feature list written from the roadmap.

A feature list written from the codebase.

Manage what the engine reads

Set the holdback

Pull a decision record

Catalogue and attribute management

Persona tagging

Holdback control

The decision record

The catalogue work comes first anyway.

The console, and an honest list of what it cannot do yet.

A feature list written from the roadmap.

A feature list written from the codebase.

Manage what the engine reads

Set the holdback

Pull a decision record

Catalogue and attribute management

Persona tagging

Holdback control

The decision record

The catalogue work comes first anyway.