"Does Price Optimization change my prices automatically?"
Not by default. The system generates suggestions, and you review and approve them, individually or in bulk, before anything goes live. You can turn on auto-approval later if you trust the configuration and want hands-off operation, in which case approved suggestions are applied as soon as they're generated.
"Why is the suggested price the same as the current price?"
Usually because the optimizer found your current price is already optimal (or very close) for your chosen objective, which is a good sign that the product is well priced. It can also happen if a safeguard is holding the price in place, or if the product was assigned a keep price action item because it didn't have enough data to model (see Why Some Products Aren't Optimized).
"Why does the suggested price change every time you run it?"
By design. Each run, the system mostly uses the price it believes is best but occasionally tests a nearby price to keep learning how customers respond. The variation is bounded, so it never produces a wild price. See Why Suggested Prices Change Between Runs.
"Why is the suggested price different from the 'optimal' price you also show?"
The optimal price is the best-estimate target; the suggested price is what this run actually chose, which sometimes tests a nearby price. Over time the two converge. See Why Suggested Prices Change Between Runs.
"How fresh is the data behind a suggestion?"
Recent sales count for much more than old ones, since the system steadily discounts older history, so a suggestion reflects current customer behaviour far more than year-old sales.
"What time period is the suggested price optimized for?"
The next couple of weeks. It also takes into account the season the product is heading into, rather than using a flat all-year average. So a product moving into its busy season is priced for that season instead of being pulled toward its year-round norm.
"We sold out of this product. Does that throw off the model?"
No. The system recognises when sales were capped by available stock rather than by demand, and treats a sell-out as a minimum ("at least this many were wanted") rather than the full picture. That stops a run of sell-outs from making a product look less price-sensitive than it really is.
"What does an inelastic confidence label mean?"
It means the product did sell at different prices and demand barely moved in response, so the system treats it as price-insensitive instead of fitting a price response to it. This isn't a data problem, it's a finding: something other than price is driving this product's sales. Products like these often have room for a price increase. See Understanding Confidence Levels.
"Why did all my variants get different prices? I expected them to match."
By default each product is optimized on its own, and there's no mechanism to align variants unless you tell the system they belong together. Check whether a pricing group is set up to keep them at the same price. See Pricing Groups – User Guide and Optimizing Products Individually or in Groups.
"Why is the suggested price higher than any competitor?"
The optimizer maximizes your chosen objective, not your position against competitors. If your goal is profit and the demand pattern shows customers will pay more, the AI will suggest a higher price. Competitor-matching rules aren't applied during optimization and no competitor data is loaded into it, so they can't pull the price toward a rival's. To cap how high a suggestion can go, use a ceiling safeguard.
"Can the AI suggest a price increase?"
Yes. The optimizer explores prices from near-zero up to about three times the current price. If demand won't drop much at a higher price, it will recommend an increase. This is common for products that turn out to be underpriced.
"Why does this product show 'rule_based' instead of an optimized price?"
The product was given an action item instead of being optimized, because it didn't have enough price variation in its sales history to model reliably, or, under a profit objective, its cost data was missing. The system fell back to a conservative instruction (keep the price, or lower it slightly). The remedy is more complete data, not a configuration change; later runs will optimize it once it has enough history. Full detail is in Why Some Products Aren't Optimized.
"Why wasn't this product optimized even though my whole catalogue is in the strategy?"
Same root cause as the rule_based answer above: too little sales history, or missing cost data under a profit objective. The product still appears in the results; it just carries a simple rule rather than a modelled suggestion. Switching to a pure demand or revenue objective (with no profit weight) lets products with missing costs be optimized, since those goals don't depend on cost.
"Why didn't my safeguard work?"
Check the safeguard's configuration. The usual causes are: the value the safeguard is based on (such as margin or cost) is missing or zero for that product; the safeguard is set as a ceiling when you needed a floor, or vice versa; or the product's cost data is missing. See How to Add Safeguards to Your Pricing Strategy.
"What if my cost data is missing?"
Products without cost data get limited or no margin-based safeguard protection, since those floors can't be calculated. On top of that, under a profit objective the product is left unchanged rather than optimized, because profit can't be computed without cost. We strongly recommend completing your cost data before relying on optimization.
"How often should I run optimization?"
It depends on how dynamic your market is. For fast-moving, competitive categories, daily is appropriate. For stable categories, weekly or every couple of weeks is plenty. You can schedule a strategy to run automatically at whatever frequency suits you.