Repricing Software & Dynamic Pricing

The engine is not the hard part

A repricing rule is a short piece of logic: match the lowest competitor minus a cent, stay within a floor and ceiling, respect a manufacturer's advertised price constraint. Anyone can write that. What separates a repricer that makes money from one that destroys margin is entirely underneath it — whether the competitor it is reacting to is actually selling the same product, whether the price it read is current, and whether an anomalous reading gets acted on or quarantined.

A repricer amplifies data errors into revenue errors

This is the structural risk and it deserves stating plainly. A dashboard with a wrong number shows someone a wrong number. A repricer with a wrong number changes your price. If a matching error pairs your product with a smaller pack size, the engine will faithfully chase a price for a different product and hold it there until a human notices. Automation converts a silent data problem into a live commercial one, which raises the required quality bar rather than lowering it.

• Wrong match: chasing a different product's price. Guard with match confidence thresholds and a hard stop below a set level.
• Stale observation: reacting to a price the competitor abandoned. Guard with observation age limits per rule — a rule should refuse to fire on data older than it tolerates.
• Parsing error: a strikethrough reference price read as the live one. Guard with movement bounds that quarantine an implausible jump for review rather than acting on it.
• Feedback loop: two automated repricers watching each other, each undercutting, converging on zero margin. Guard with floors that are absolute rather than relative.
• Marketplace confusion: reacting to a third-party seller's price as if it were the retailer's. Guard by carrying seller identity on every observation.

What the data layer must return

A pricing engine needs more than a number per competitor. It needs enough context to decide whether to trust the number, and that context has to arrive with the price rather than being reconstructed later.

Freshness is a per-listing property

Uniform refresh across a catalogue is wrong in both directions. The majority of listings do not move for weeks, so re-reading them constantly burns the scarce resource — which is address budget, not compute — to confirm nothing happened. The minority that move several times daily are exactly the ones a repricer exists for, and a uniform schedule under-serves them.

Cadence should follow each listing's own measured volatility, bounded by a floor and a ceiling per source. And the floor is a hard constraint set by the source, not by your ambition: for sources with tight limits, the fastest honest refresh is slower than a repricing engine would like, and a system that pretends otherwise is reporting data it did not read.

MAP is a constraint, not a rule to optimise around

Where a manufacturer's advertised price policy applies, it binds the engine absolutely, and enforcement depends on evidence rather than alerts. A violation needs the observed price, the timestamp, the seller identity and a durable record of what was displayed — a screenshot alone is weak, and a number with no provenance is weaker. The evidentiary quality of the observation is the product here, not the notification speed.

Measuring whether it worked

Repricing is easy to evaluate badly. Revenue went up after switching it on is not evidence; seasonality, assortment changes and demand shifts all produce that. The honest evaluation holds out a control group of comparable SKUs, runs both for long enough to cover a full promotional cycle, and compares margin rather than revenue — a repricer can always increase volume by lowering price, and that is not the same as helping.

Rolling out without breaking anything

The failure pattern in repricing deployments is switching it on across the catalogue and discovering the data problems through margin. A staged rollout surfaces the same problems while they are still cheap, and the staging is by confidence rather than by category.

• Run in shadow mode first: compute the price the engine would set, record it, change nothing. Compare against what a human would have done.
• Enable on products where match confidence is highest and the competitive set is unambiguous — branded goods with barcodes, not private label.
• Set absolute floors before relative ones. A floor expressed as a margin over cost cannot be dragged down by a competitor spiral; a floor expressed as a discount off a competitor can.
• Keep a holdout group permanently. Without it you cannot distinguish the engine's effect from the season's.
• Alert on refusals, not just actions. A rule that declined to fire because the observation was stale is telling you something about your data pipeline.

Holding is a valid output

A repricer that always produces a new price is not more sophisticated than one that sometimes refuses — it is less careful. Every guard that matters is a refusal: do not chase a match below confidence, do not react to an observation older than the rule tolerates, do not act on a move implausible enough to be a parsing error. The systems that damage margin are the ones with no way to say not enough information.

Questions

Common questions

Related