Price simulation answers a single question: what if? You propose a new price for one or more products, and the system predicts what would happen to sales volume, revenue, and profit if that price went live. Think of it as a flight simulator for pricing decisions: you can try a price, see the projected outcome, and decide before anything actually changes on the shelf.
Crucially, simulation is read-only. It never changes your live prices. It forecasts the outcome of a price change so you can compare options and pick the best one; nothing goes live until you act on it through the normal pricing flow. If you're looking for the step-by-step setup instead, see How to Create a Simulation Scenario in Price Simulator. To turn a winning scenario into a live strategy, see How to Create a Price Change Strategy from a Simulation Scenario.
Where the proposed price comes from
A simulated price can reach the system in three ways. Whichever route it takes, the same forecast runs afterwards, so the projected numbers are always comparable.
Source | How the price is set |
Manual | You type the price in yourself. |
Dynamic | The price comes out of your dynamic-pricing rules (for example, "match the cheapest competitor"). |
Optimal | You ask the system to find the best price, the one that maximizes profit, or the one that maximizes revenue. |
When the system searches for an optimal price, it stays sensible. It won't recommend a price below cost, and it won't wander far outside the range of prices the product has actually sold at before, because the further a prediction strays from real data, the less it can be trusted. By default it keeps recommendations within roughly 10% of the highest and lowest prices the product has genuinely seen.
After the price is chosen, your business rules are applied on top of it: price floors and ceilings (safeguards), price grouping to keep related products aligned, and rounding. These work the same way they do elsewhere in Pricen. See How to Add Safeguards to Your Pricing Strategy, Pricing Groups – User Guide, and How Price Rounding Works.
How the forecast is produced
Every product has a demand curve, a relationship between price and sales volume that the system has learned from the product's own sales history. It describes, in effect, how many units sell at any given price.
To produce the forecast, the system plugs the proposed price into that curve to get expected daily demand, then derives the rest from it:
Revenue = demand × price
Profit = demand × margin
Because no forecast is exact, each number comes with a confidence range, an optimistic case and a pessimistic case around the central estimate. The width of the range reflects how sure the model is: a product with lots of clean price-and-sales history gets a tight range, while a sparse one gets a wide one. A narrow range means you can lean on the central number; a wide one is a signal to treat it as a rough guide.
Two real-world factors layered on top
The raw demand curve gives price-driven demand. Two further factors adjust it to reflect reality.
Seasonality. If the forecast window includes a known busy period, the seasonal pattern (learned separately) lifts expected demand for those dates. A forecast that runs into December reflects the December bump rather than assuming every day is average.
Stock. By default the system assumes unlimited stock, so the forecast shows pure price-driven demand. If you turn on stock awareness, the forecast becomes a realistic sell-through projection: it caps each day's projected sales at the inventory expected to remain, and flags the date stock is projected to run out.
What you get back
For the products that could be forecast, a simulation returns:
Output | What it shows |
Day-by-day forecast | Projected demand, revenue, and profit across the whole product set, with confidence ranges. |
Per-product breakdown | The daily and cumulative numbers for a single product, if you drill in. |
Final prices | The resulting price for every product you asked about, including the ones that couldn't be forecast. |
Insights | Total expected demand, revenue, and profit over the window, and the date any product is expected to sell out. |
The default forecast window is the next three weeks, but you can set any start and end date you like. (This is deliberately shorter than the 90-day seasonality horizon, because simulation is meant for near-term pricing decisions.)
Honest numbers, not optimistic ones
The system only forecasts products where it has actually learned a demand pattern. For a product it can't model, because a fixed rule already decides its price or because there was never enough sales history to learn from, it still returns a price, but it's upfront that it has no forecast to back it. You'll see the price accompanied by the reason it was excluded, for example "this product has a fixed rule in place" or "no cost data is available, so profit can't be projected."
Demand and revenue may still appear even when profit can't, since profit is the only one of the three that needs cost data. The principle throughout is that the system never claims a precision it doesn't have.
A note on multiple stores
If you sell across several stores, how the numbers read depends on whether you've selected one. When a specific store is chosen, the forecast is scoped to that store. When no store is selected, the system falls back to a combined sales history and describes what a single average store looks like across your portfolio, not the total across every store added up. A merchant with ten stores might expect the no-store forecast to show ten stores' worth of volume, but it shows roughly one store's worth, averaged. To see a particular store's numbers, select that store.
For the questions we hear most often about reading simulation results, see Price Simulation: Common Customer Questions.