Why a repricer must be able to explain itself

It's Monday morning and a product is sitting at $18.40. You didn't put it there.

You open the tool, and it tells you the price changed under your Buy Box strategy. You knew that already, because that's the strategy you assigned.

What you wanted to know is different. Why $18.40 and not $19.10? And was it reacting to a competitor who's still there, or to an offer that lasted forty minutes?

Getting a real answer is harder than it should be, and the reason isn't the reporting. It's that the tool either wrote its reasoning down at the moment it decided, or it plans to work it out later from whatever it happened to keep.

The second one is unreliable. Not always, but whenever the explanation depends on something that can change or disappear, and a surprising amount of what it would need can do both.

The objection first, because it is a good one

"Surely you just log everything and look it up later."

That's what most people assume is happening, and here are four places it comes apart. None of them is about the tool being badly made.

The market it reacted to is gone. Competitor prices change constantly, so a repricer is either refreshing that picture or receiving it, over and over. Keeping all of it forever is expensive, and old snapshots stop being useful fast.

So a record that says "it beat the lowest offer" and points at the market data goes hollow the moment that data expires. Six weeks later your accountant asks about a thin month. The sentence is still there; the world it described isn't.

The rule changed since. You raised your floor in June, and the price you're asking about was set in May.

A tool that rebuilds the explanation from your current settings will describe a rule that didn't exist yet, and it will do it confidently. This is the worst of the four, because nothing breaks: you get an answer, the answer is wrong, and it doesn't look wrong.

A sentence is not an answer you can count. Say the tool did store the reasoning, as text: "Beat the Buy Box by $0.05."

Fine. You can read that one. Now ask the question you actually have at the end of a month: how many of my price changes were stopped by my own floor, and on which products?

"Hit minimum price", "Minimum price reached" and "Price constrained by floor" all mean the same thing to you. To anything counting them, they're three different strings, and a short reason code is what turns them into one thing you can filter and total.

Nothing happened, so nothing was logged. This one is easy to miss and it can cost the most.

The price you most need explained is often a price that didn't move. A listing that quietly stopped repricing three weeks ago produces no price-change event at all, so a log of price changes has nothing to show you. You find out because a product stopped selling.

The three things those four actually ask for

They don't all prove the same point, and separating them turns a complaint into a specification.

1. Keep the context while it still exists. That's the first two: the market moves, your settings move, and neither will be around to rebuild from.
2. Store the reason as a code, not as a sentence. That's the third, and it decides whether a month of price changes adds up to anything.
3. Record when a listing is stuck, not just when a price moves. That's the fourth, and it needs a different mechanism, because there's no event to hang it on.

You can add all three later, for decisions that haven't happened yet. What you can't do is get back context you never kept.

What "written down at the time" actually means

A tool that does this keeps two things about every price change, and they do different jobs.

A short label, from a small fixed list. Undercut a competitor. Matched one. Hit your floor. Protecting your margin. Cannot compete at your minimum. No competitors found. You set this by hand.

The exact list differs by tool. It has to stay small and stable, so that every price change in your account lands in one of them.

The numbers it used. Which reference price it followed, and what that price was that day. How far above or below it went. Which of your limits pushed back, and the price they held it at.

Stored as the numbers themselves rather than as a finished sentence, so the sentence can be written afterwards, in your language, out of facts that haven't moved.

There's an honest complication in the label. A price change usually has several things acting at once: a strategy that wanted one number, your own minimum pushing back, a MAP limit you have to respect. So "the reason" means picking one from several true answers, and somebody has to set that order and stick to it. Which order a tool picked is a fair thing to ask.

Four questions that separate the tools

Point these at anything you're looking at, including a marketplace's own built-in repricer.

1. Show me why this exact price changed, on a change from a few weeks back.

Not the strategy name. The reference price it used, the number, and what stopped it going further. If the answer gets thinner the further back you go, the explanation depends on data that expires sooner than the decision does.

2. How many of my price changes last month were stopped by my floor?

If the only way to answer is to read the changes one at a time, the reasons aren't working as data.

3. Which listings are not repricing right now, and why each one?

The answer should be specific: no cost entered, no minimum set, no competitors visible, the account needs reconnecting, or whatever is actually blocking it. "All listings are active" is an answer to a different question.

4. Do the facts change if I edit my strategy?

Open an old price change and note the reason, the reference price and the limits that acted on it. Change a rule. Look again.

The wording may have changed, if the tool builds its sentence from stored facts. The reason and the numbers must not. If those moved, the tool is guessing at your past from your present settings.

What we do about it, and what it costs

Every price change is recorded as it's decided: the price before and after, which reference it followed and what that reference was worth at the time, which of your limits pushed back and the price they held it at, and the version of the rule that produced it.

The facts are the record, and the sentence you read is built from them. That split is what lets the same decision show up in English or Spanish while the reason underneath stays something you can filter, group and count.

The order question above has an answer here too, because it's the kind of thing worth publishing rather than leaving people to find out. A price you set by hand beats everything. Then the case where you genuinely can't compete at your own minimum. Then having no competitor to react to. Then whichever of your limits pushed. Only then the strategy you chose.

That order is the same on every marketplace we support, so a reason means the same thing wherever the listing is.

When a listing isn't repricing at all, the reason sits on the listing itself, from a fixed set of named states, because there's no price-change event to hang it on.

So we record when a listing is stuck, and not every check that goes fine. A check that finds the price already correct isn't written down: those happen constantly, and one entry per listing per check would bury the changes you want to read.

And once a decision is written, nothing in the product edits it. No screen, no action, no background job. An administrator can delete a record, and that's the only way one ever changes. That's what keeps the facts in question four stable. It isn't a compliance ledger and we wouldn't call it one.

A stable list of reasons costs us something, and it's worth saying what. Adding a new kind of reason is a deliberate change to a fixed set, not a new sentence somebody writes. That's the trade, and it buys the thing question two needs: categories steady enough to compare across months.

And there are limits we won't pretend away.

The market snapshot behind a decision is kept for seven days, not forever. It's the biggest data in the system and its value drops fast with age, while the decision itself has no expiry date. That gap is the design: the market picture is temporary on purpose, the decision record isn't.

The record also has a ceiling. It keeps the facts needed to explain the price that was chosen, and it isn't a replay of every market input and every setting your old strategy carried. So the rule version on a decision tells you the rule has changed since. It doesn't bring the old rule back.

What this changes for you

Mostly it changes what you ask for on a demo call.

Most repricer feature lists look alike and having a price history is common, so the narrower question is what that history contains. A history of outcomes tells you what the price became. A durable history of reasoning tells you why that number and not another one, months later, after everything it depended on has moved.

Question one is the first test: pick a price change from last month and ask the person demoing it to explain that specific number. The other three tell you whether the explanation holds up across a whole catalog rather than on one lucky row.

We build a repricer, so the product-specific details above describe our own approach. The four questions are vendor-agnostic, and we think they're worth asking us too.