What Dynamic Pricing Actually Requires

The appeal is obvious. Price is the most direct lever on margin, and the major online marketplaces have shown that prices can be continuously adjusted to reflect demand, competition, and inventory. Since then, dynamic pricing has appeared on nearly every AI wish list in retail — usually near the top.

On that same wish list, however, the use case is often wrongly positioned as an entry point. Dynamic pricing requires more cells of our matrix to be in place simultaneously than any other use case, and every mistake is immediately visible — on the shelf and in the shop. This article works through the prerequisites one by one so you can assess how far your organization is from its first pricing algorithm — and whether this is the right path to pursue right now.

What is dynamic pricing, and what does it promise?

Dynamic pricing means prices are adjusted continuously and rule-driven rather than maintained manually at fixed intervals. The range is wide. At one end sit simple rules — automatic markdowns at the end of a season or a price floor relative to competitors. At the other end, an algorithm optimizes prices across the entire assortment based on demand forecasts, inventory levels, supplier terms, and competitor prices.

The comparison to marketplaces can easily mislead. A pure online retailer changes a price with a single database entry, in one channel, without anyone touching a label. A multichannel retailer has store prices, shelf labels or electronic shelf labels, printed promotional materials, and customer expectations that online and in-store prices align. The same price change that costs nothing online triggers a cascade of follow-on effort in a physical store. Copying the marketplace model without accounting for this difference means underestimating the project from the outset.

The promise: higher margin at the same sell-through, fewer markdowns at season end, faster response to competitors. Honesty requires acknowledging what we have already noted in our piece on use cases with proven impact: in our view, there is no robust, cross-source estimate of pricing's effect size for retail. The figures in circulation come predominantly from vendors of pricing software. That does not mean the lever is small — it means you have to measure it for your own assortment rather than take it from a brochure.

Why does pricing place the highest demands on data?

For two reasons: the use case requires many data domains simultaneously, and it does not tolerate delays. A pricing decision draws on at least four sources at once. Sales data reflects demand, purchasing terms set the floor, inventory levels determine the urgency to act, and competitor prices define the frame. If any one of the four sources fails or lags behind, the algorithm is working from a distorted picture.

Then there is the cost-of-error side, which sets pricing apart from almost every other use case. A wrong replenishment suggestion can be corrected internally before any damage occurs. A wrong price is live immediately. Too low, and it directly costs margin — in the worst case, below the purchase price. Too high, and it costs sell-through and, more gradually, price trust. Gartner warns in general terms that AI-ready data gaps put projects at risk. In pricing, that warning is sharper: the consequence of bad data is not internal rework — it is a wrong price facing the customer.

Which data domains specifically need to be in order?

Four — and all at once, and all current. First, the product master: purchase price, units, and pack sizes must be correct, or every margin calculation is wrong. A classic real-world trap is the unit mismatch, where the purchase price is maintained per carton while the selling price is calculated per unit. A human would spot the outlier; an algorithm treats it as a valid value.

Second, transaction data: sales must be clean and comparable by channel, including promotional periods. An algorithm that treats a promotional sales spike as normal demand learns systematically incorrectly. Third, inventory — more current than for most other use cases. Calculating today's prices against last night's stock levels means marking down items that have already sold out. Fourth, supplier terms and competitor prices: versioned, with validity periods, from a reliable source rather than spreadsheet files. How to audit the state of these domains yourself is covered in What data does AI need?. For pricing, run that audit four times — once per domain.

What else is needed beyond the data?

Guardrails, an audit log, and a defined operating framework. A pricing algorithm without boundaries is an operational risk. The minimum setup includes a hard floor per article — usually relative to the purchase price — a ceiling to protect price perception, rules for maximum price movements and change frequency, and a price log that makes every change traceable: which price was in effect when, and why. Without that log, you cannot measure the effect later, and you cannot explain an individual price when someone asks.

The operating setup also requires monitoring with alerts: prices below cost, an unusually high number of changes in a short period, outliers against competitors. These cases halt the automated process and route to a person for approval — the same principle that has proven its value with replenishment agents. The algorithm handles the standard case; exceptions remain a manual task.

Two topics outside the technical domain also matter. Customer price trust: changing prices too frequently or in ways that appear arbitrary is perceived as unfair, and that damage is hard to undo. How often prices change and how visible those changes are is therefore an assortment and brand decision, not a purely algorithmic one. This also includes the channel question: does the same price apply in-store and online, and if not, how do you explain the difference? That decision must be made before the algorithm is built, because it determines which prices the algorithm is even allowed to touch. And the legal framework: price changes, reference prices, and especially personalized pricing are all subject to rules that need legal review before launch. We are not a legal advisory, so this is simply a flag that the review belongs on your prerequisites list before the first algorithm runs.

How should organizations start with dynamic pricing?

Small, rule-based, and measurable — almost never with a full-assortment algorithm. The proven starting point is a defined subset with built-in urgency, typically end-of-season markdown management: a clear target metric, a limited number of articles, manageable risk. This is the right arena to practice the full chain — data supply, guardrails, and price log — before touching the core assortment.

A second proven entry point is the long tail of the online assortment: articles with low sell-through where no one has time to maintain prices manually and where a mistake carries little cost. The same principle applies: rules first, machine learning second.

Measurability matters from day one. Before launch, define the metric against which success will be judged — such as markdown rate or remaining stock at season end — and document where that metric stands today. Keep a portion of the assortment on the existing process as a control group. This produces a robust, first-hand proof of effect within a single season that replaces any vendor-supplied figure. Only once that proof exists does it make sense to discuss the next expansion step.

One organizational point that determines whether the initiative survives or stalls: pricing needs a business owner. One person who owns the rules, handles the alerts, and represents the results to buying and sales. Without that role, the algorithm becomes an orphan the moment margin and sell-through come into conflict — and orphans get switched off.

Five questions to answer before your first pricing algorithm

1. Are purchase price, unit, and pack size correct in the product master — verified, not assumed? Without a reliable floor, any pricing automation is flying blind.
2. Can you cleanly separate sales by channel and identify promotional periods as such? Contaminated demand data causes the algorithm to learn systematically incorrectly.
3. How current is your inventory data at the moment a pricing decision is made? For pricing, last night's figures are often already too old.
4. Are guardrails defined and a price log in place? If not, the project is not ready to launch — regardless of how good the data is.
5. How will you measure success, and is there a control group? Without both, you will never know whether the effort was worth it.

Organizations that can answer all five questions with solid evidence are among the few for whom dynamic pricing is genuinely the next step. For everyone else, the questions reveal what needs to happen first — and that is the real value of the exercise.

In the KI-Studie 2025 des Handelsverbands Deutschland (HDE), 89.1 percent of retail companies cite high data quality as a relevant success factor for AI projects. It remains the most important success factor identified in the study. For most organizations, the honest first step is therefore not pricing software. It is an honest assessment of their own data foundation — with evidence drawn from their systems, using the open framework described on the method page. The pricing algorithm is not going anywhere. It only becomes cheaper, faster, and considerably less risky when the foundation is already in place.

Sources

Source	What it says
Gartner · Lack of AI-ready data puts AI projects at risk, Februar 2025
HDE & Safaric Consulting · KI-Studie im Handel 2025