Dynamic pricing means adjusting a product’s selling price as conditions change, using inputs such as demand, available stock or competitor prices. In ecommerce, a rule or model can calculate the next price, with changes published automatically or held for human approval. Prices can move down as well as up.
Dynamic pricing does not mean changing every price constantly. The “dynamic” part is that defined changes in data can trigger a repeatable pricing decision.
For example, an online store might propose reducing a $120 product to $115 after a competing offer changes. Whether that proposal reaches the storefront depends on the store’s price limits and approval rules. A calculated price is only one step in the process.
Key Takeaways
- A basic rule can calculate the next price without AI or a demand model.
- Minimum and maximum prices, change limits and approval rules determine which proposals can be published.
- Keep the data observation, decision and confirmed price update separate in the execution history.
How does dynamic pricing work?
A practical dynamic pricing workflow starts with a trigger and ends with a verified selling price. You can structure it as six steps:
- Collect inputs. Read the relevant product, stock, sales and market data, including when each observation was made.
- Evaluate the rule. A scheduled run or a new event starts a price calculation for eligible products.
- Check constraints. Test the proposed price against the limits that apply to that product and channel.
- Authorize the change. Publish within approved boundaries or send the proposal to a reviewer.
- Apply and verify. Submit the change and confirm the resulting price on the selling channel.
- Record the outcome. Save what changed, what was blocked and what failed, along with the inputs and rule version.
The calculation can be simple. A rule might match a selected competing offer, reduce a price when stock exceeds a threshold, or restore a price after a temporary condition ends.
Price optimization addresses a different question: which price best serves an objective, such as profit or revenue, given an estimated demand response. An optimization model can supply recommendations to a dynamic pricing workflow, but a basic repricing rule does not need such a model. Automatically applying a rule does not establish that its result is the best price.
What data can trigger a price change?
Dynamic pricing in retail can respond to changes in your own business, the wider market or both. Choose inputs that explain the condition your rule is meant to address.
| Input | Possible use in a rule | Check before acting |
|---|---|---|
| Competitor price and availability | Recalculate when a comparable offer changes | Same variant, pack size, condition, currency and delivery basis |
| Sales over a defined period | Review prices when sales cross a chosen threshold | Stockouts, advertising changes and unusual orders |
| Available inventory | Respond to excess stock or limited supply | Sellable units, committed orders and expected replenishment |
| Costs and selling fees | Update the minimum acceptable price | Current product costs and channel-specific charges |
| Time or an end date | Change the applicable rule as a deadline approaches | Correct timezone and a defined rule after expiry |
These are possible inputs, not a requirement to connect every data source. For a first rule, use the smallest set you can explain and validate.
Competitor observations need particular care. A low number from a different pack size should not trigger a price cut. A missing stock status should not silently become “in stock.” The broader work of turning observations into a usable comparison belongs to pricing intelligence for ecommerce.
Observation time and execution time are different
A rule that runs every few minutes can still use an old price observation. There are three separate times to track: when the input was observed, when the rule evaluated it and when the selling price changed.
Set a maximum acceptable input age for each rule. If the required data is too old, hold the current price and record why. Choose that threshold through a separate competitor price monitoring frequency decision; running the calculation more often does not refresh the underlying evidence.
Also define when a new observation justifies another evaluation. Repeatedly processing the same input should not produce a series of unintended price cuts.
Which rules and limits should control the new price?
Write the pricing action and its restrictions together. “Follow the competitor” is incomplete without specifying which offer qualifies, how the price is calculated and when the result must be held.
A useful rule description includes:
- Scope: the products, variants, market and selling channel covered.
- Trigger: the event or schedule that starts evaluation.
- Calculation: how valid inputs produce a proposed price.
- Hard limits: boundaries the workflow must not cross.
- Review conditions: changes that need a person to approve them.
- Hold conditions: stale data, missing inputs or conflicting instructions.
Use a minimum price to protect the economics you have already calculated. Add a ceiling where required by your business policy, and set limits on both individual changes and cumulative movement over a period. A small allowed cut repeated many times can still produce a large overall reduction.
Related products may need constraints too. For example, a rule for the basic model should respect the intended relationship with the upgraded model. That relationship comes from your price lining decisions. The repricing workflow checks whether a proposed change preserves it.
Distinguish a hard limit from a preference. Some pricing systems allow lower-priority preferences to be relaxed when rules conflict. A minimum you intend never to breach must be enforced as a hard limit, including after rounding or other price adjustments.
Decide how violations behave: reject the proposal, substitute an allowed boundary price, or request review. Those choices produce different outcomes. Document the one your rule uses. A reviewer can choose a compliant price; approval must not override a hard limit. If the current price itself breaches a hard limit, flag it for correction rather than treating a hold as acceptable.
A worked dynamic pricing example
Suppose a store sells a desk lamp for $120 and uses a rule that proposes a price $1 below a selected comparable competitor. The following numbers and thresholds are illustrative, not recommended defaults or measured results.
| Setting | Illustrative value |
|---|---|
| Current selling price | $120 |
| Valid competitor price | $116 |
| Rule calculation | Competitor price minus $1 |
| Hard minimum / maximum | $108 / $125 |
| Automatic change limit | Up to 3% from the current live price |
| Maximum input age | 30 minutes |
| Below-floor behavior | Reject the proposal and hold the current price |
The proposed price is $116 − $1 = $115.
It passes the hard limits because $115 is between $108 and $125. The percentage change is ($115 − $120) ÷ $120 × 100 = −4.17%, rounded to two decimal places.
That reduction exceeds the 3% automatic limit. The result is therefore pending review, with the selling price still at $120. If an authorized reviewer approves the exact proposal and the inputs remain valid, the store can submit $115. Only a confirmed channel update establishes that $115 is live.
After $115 is confirmed, suppose a later valid competitor observation is $105. The same calculation proposes $104, below the $108 hard minimum. Under this rule’s stated behavior, the proposal is rejected and the current $115 price remains. The system does not silently replace $104 with $108.
The arithmetic shows how the workflow behaves. It does not prove that undercutting by $1 is commercially worthwhile. Choosing whether to match, undercut or hold belongs to the store’s competitive pricing strategy.
Where manual approval belongs
Manual approval can sit between calculation and publication without changing the underlying dynamic pricing mechanism. Use it for changes that exceed a movement threshold, affect a sensitive product group or arise while a rule is being tested.
The reviewer should see the current price, exact proposed price, reason for the change, input age and all relevant limits. Approving a rule for future automatic use is a different decision from approving one proposed price.
Approval should also expire when the facts behind it change. If someone approves $115 but the current price or required inputs change before publication, recalculate and check the proposal again. Do not treat an earlier approval as permission to publish any later result.
Define who can pause a rule, change its boundaries and restart it. Pausing further changes and restoring a previous price are separate actions: a pause should not be assumed to undo a price already published. Check that any restoration still satisfies current hard limits.
What should execution history show?
Execution history should explain both the decision and what actually happened on the selling channel. A record containing only the final price cannot show whether the rule worked as intended.
For each evaluation, retain:
- Product, variant, market and channel identifiers.
- The previous live price and the exact proposed price.
- Input values and their observation times.
- The rule version, limits and reason for the decision.
- Any reviewer decision and the time it was made.
- Submission, confirmation or failure details.
In the lamp example, an input observed at 09:00 could produce a review request at 09:05, receive approval at 09:12 and result in a confirmed update at 09:13. Those times describe different events. They should not all be labelled “price updated at 09:05.”
Keep outcomes distinct: no change needed, held for invalid data, blocked by a limit, pending approval, submitted, confirmed and failed. These are suggested record categories; actual software may use different names.
A channel can reject an update, or a connection can fail before confirmation arrives. Before retrying, check the live price and whether a newer change has already been accepted. An old retry should not overwrite a later decision.
Where surge pricing fits
Surge pricing describes price increases during periods when demand is high relative to available supply or capacity. It is one application of dynamic pricing. Ecommerce price changes can also respond to competitor offers, excess inventory or weaker sales, and can result in lower prices.
A fixed weekend discount is not necessarily dynamic: its amount may have been set in advance without responding to changing conditions. If a promotion and a repricing rule can run together, specify which takes precedence. Keep the campaign design in your promotional pricing plan and test how the two interact.
Make the customer’s purchase journey part of the design. Explain material price-change conditions where shoppers make decisions, clarify what a “reserved” price means and keep advertised prices accurate. Avoid pressure messages that imply an unsupported imminent increase. As a customer-facing safeguard, keep the price stable while the customer is paying.
Common dynamic pricing errors
Most useful checks concern the connection between input, decision and result. Test failures as well as successful updates before expanding a rule.
| Failure | What can happen | Control to test |
|---|---|---|
| Stale or mismatched input | The rule responds correctly to the wrong evidence | Input-age limits and exact-offer checks |
| Conflicting rules | A promotion and a repricer overwrite each other | Explicit priority and product exclusions |
| Repeated small moves | The total change exceeds the intended tolerance | Cumulative movement limits and a pause condition |
| Discount applied after repricing | The payable price falls below the intended floor | Check permitted discount combinations against the floor |
| Approval arrives late | An outdated proposal replaces a more recent decision | Revalidate the price and inputs before publication |
| Submission mistaken for success | Records show a price customers cannot buy at | Separate submission from channel confirmation |
After a rollout, also check the commercial result. More updates, higher sales or a faster response alone do not establish higher profit. Compare sales and contribution alongside stock availability, advertising and promotions so you can identify other plausible explanations.
Start with a limited product group and run the rule in observation mode, producing proposals without publishing them. Review the proposed changes, deliberate failure cases and execution records. Enable automatic publication only after the workflow consistently handles both valid proposals and the cases where the price should stay unchanged.
See how your own catalog compares with the market
SkuPeek finds matching competitor offers and compares their prices and availability with your products.