Dynamic pricing with AI – how does it work?

Dynamic pricing using AI is an approach in which the price is automatically adjusted to current demand and supply conditions as well as clearly defined business objectives. In practice, it is not just about increasing rates, because the system also lowers them just as often to increase conversion, make better use of capacity or reduce stock levels. AI makes it possible to learn from data and forecast the effects of a price change on demand, rather than playing catch-up only after sales have already fallen. For such a solution to be justified, both sufficient demand volatility and the ability to update prices frequently in sales systems are needed. In this article, we show how the mechanics of dynamic pricing with AI work and what data and integrations are necessary for recommendations to be useful and operationally safe. If one of the elements is missing (e.g. cost data or price enforcement), we describe how this affects the result and what is worth paying attention to.

Basics of dynamic pricing and the role of AI

Dynamic pricing is the automatic adjustment of price to current demand and supply conditions and business objectives. It works best where demand is variable and new prices can be published frequently, e.g. in e-commerce, hospitality, aviation or car-sharing. If prices are restricted by contractual terms or there are very few transactions (e.g. B2B with a handful of clients), AI has too few signals to price reliably. In such situations, simpler processes or manual control may be a better starting point.

AI differs from classic pricing rules in that it can learn the relationships between many factors at once and predict how demand will react to a price change. Rules such as “-10% when stock > 100” are simple, but they usually do not take into account in one model how seasonality, competition, segment, device or campaign affect one another. In practice, AI’s advantage lies in the fact that it estimates the impact of price on demand and makes it possible to optimise decisions, rather than merely reacting to what has already happened. For this to work, you need to define from the outset what the optimisation goal is: revenue, margin, profit or intermediate KPIs (e.g. conversion or sell-through).

A key concept in dynamic pricing is price elasticity, i.e. information on how much demand will change when price changes by 1%. Elasticity can be estimated from historical data or A/B tests, but you need to control for the impact of promotions and seasonality, otherwise the result will be misleading. The frequency of price updates depends on market dynamics and the cost of making a change: in e-commerce, updates 1–6 times a day are typical, while in on-demand services they may happen every few minutes when data comes in real time. Many companies also prefer several price tiers (“good / better / best”) rather than one “optimal” value, so AI can calculate a recommended range and select a level that is consistent with the brand policy.

1. 01Automatic adjustmentTo current demand and supply conditions and objectives.
2. 02Variable demand, frequent pricesE.g. e-commerce, hospitality, aviation, car-sharing.
3. 03Constraints for AIFixed contracts, too few transactions.
4. 04Advanced learningPredicts reactions, analyses many factors at once.

AI goes beyond simple rules by predicting demand through the simultaneous analysis of many factors.

Key inputs and integrations

Effective dynamic pricing with AI requires full transaction data and integrations that make it possible to publish and enforce price recommendations. The foundation is sales logs (price, quantity, discounts, channel, time, returns), supplemented by purchase context, e.g. delivery cost and payment method. Data “from the receipt” alone is often not enough, because the absence of sales may be due to a lack of traffic rather than the price level. For this reason, exposure data (impressions) and clicks are also highly valuable.

• Demand and supply data: inventory levels, stockout risk, lead time, product searches, add-to-cart events, abandonment and seasonal signals (e.g. holidays, school breaks, weather).
• Competitor prices: comparison feed data (e.g. Ceneo, Google Merchant Center) or scraping with tools such as DataForSEO, Bright Data or Apify, with refresh rates matched to the category (e.g. every 1–3 hours in electronics, once a day in furniture).
• Costs and margins: cost of goods sold, variable costs (e.g. marketplace commissions, payment fees of 1–2% of value) and logistics costs, to avoid optimising revenue at the expense of margin.

The biggest risk of incorrect recommendations appears when the model cannot “see” costs or confuses list price with the discounted price. If AI is to protect margin, you need a hard floor price constraint, e.g. cost + minimum margin, so that the system does not go below cost. It is equally important to take promotions, coupons, performance campaigns and email marketing into account, because they affect demand independently of price and can distort elasticity estimation. In personalisation, information about the segment (e.g. new vs returning) and context is useful, although it is often safer to differentiate the offer (e.g. bundle, free delivery) rather than change the price itself for a specific person.

In practice, dynamic pricing also depends on data quality and well-implemented system integrations. Typical difficulties include a lack of signals about unavailability, changes in SKU identifiers and inconsistent price definitions, so validations (e.g. Great Expectations) and a coherent data model in the warehouse (BigQuery/Snowflake) are needed. On the integration side, the system should be connected to ERP/WMS (stock and costs), PIM (attributes), the shop platform (Shopify/Magento) and analytics (GA4, Amplitude). Prices are usually published via API or queues (Kafka), and cache (Redis) helps protect the shop from recommendation delays.

AI models and methods for price optimisation

AI models in dynamic pricing most often combine demand forecasting with an algorithm that selects a price in order to maximise a previously defined objective. In practice, demand is first estimated in a specific context, and then the impact of a price shift on the business outcome is assessed. Demand prediction often uses gradient boosting models (XGBoost, LightGBM, CatBoost) or networks trained in TensorFlow/PyTorch. For SKUs with clear seasonality, time series approaches, e.g. Prophet, and sequential models work well.

Modelling price response involves teaching a demand function in relation to price, taking into account interactions with the segment, competition and season. If the historical data lacks sufficiently large price fluctuations, the model will not estimate reliable elasticity, and then controlled price experiments (price experiments) are unavoidable. Users often ask whether AI “knows” that it is the price causing the change in demand. Standard models learn correlational relationships and can make mistakes when promotions or campaigns are running in parallel. That is why causal approaches (e.g. Double Machine Learning, causal forests) and A/B tests help separate the effect of price from marketing and seasonality.

Price optimisation usually starts with calculating profit as a function of price, e.g. Z(p) = (p − koszt) * D(p), where D(p) denotes the forecast demand for a given price. The maximum is most often found by searching a grid of candidate values (e.g. 30–100 levels) or by Bayesian optimisation (Optuna), especially when constraints are involved. Reinforcement learning is sometimes used when pricing decisions have long-term consequences (e.g. subscriptions, churn), but it is often not necessary because it is harder to control. In many companies, supervised learning combined with rules and cyclical experiments is enough.

Pricing models should also take into account dependencies between products, because the price of one SKU may cannibalise sales of others or boost them. In such situations, multidimensional models and portfolio optimisation with price consistency constraints are used. For slow-moving SKUs, a hierarchical approach (category → brand → SKU) and transfer learning are applied so that a new product “inherits” parameters from similar items. To avoid paying for errors caused by an overly high price, anomaly detection (e.g. Isolation Forest, robust z-score) and safety rules such as “max change 5% daily” are implemented.

Interpretability is crucial, because the business expects an answer to the question “why this price?”. SHAP tools show the contribution of variables such as competitors’ prices, season or stock levels to the demand forecast and the final recommendation. This makes it easier to spot issues in the features, for example when the model overestimates the impact of one channel because data on supply constraints is missing. Such transparency also speeds up agreement on rules for accepting recommendations and operational exceptions.

1. 01Demand forecastingEstimation in context (LightGBM, Prophet)
2. 02Modelling price responseDemand function in relation to price. Takes into account segment, competition, season.
3. 03Optimisation algorithmsChoosing a price for the business objective (XGBoost, sequential models)
4. 04Historical data challengeNo large price fluctuations? Unreliable elasticity, difficult estimation.

The key is to combine precise demand forecasting with an intelligent optimisation algorithm to effectively maximise the defined objective, despite the data-related challenges.

System architecture of dynamic pricing

The architecture of a dynamic pricing system is an end-to-end pipeline leading from data acquisition through to price publication and monitoring, which ensures consistency and risk control. The most common setup looks like this: data collection → feature store → training → recommendation serving → price publication → monitoring. Real-time is not always necessary, because in many cases batch mode is enough (e.g. nightly training and daily prices), while online is mainly used for categories with high volatility. Such a split makes it easier to match infrastructure costs to the actual needs of the business.

The feature store organises and standardises the features used in training and prediction, reducing the risk of training-serving skew. In practice, this means that the same feature definition (e.g. “average competitor price from 24h”) is calculated in the same way in batch and online. The pipeline is usually orchestrated in tools such as Airflow, Prefect or Dagster, with separate tasks for data validation, training and publication. The training frequency depends on category stability (e.g. once a week), while price updates may happen more often based on fresh features.

Model versioning and change control are handled through registries such as MLflow Model Registry, SageMaker Model Registry or Vertex AI, together with metrics and information about the training data. Recommendation serving can be implemented as an API (e.g. FastAPI) or as a batch for import, and in the online approach latency is key. the typical target is <100 ms per SKU. Running in parallel with the model is a rules and constraints engine (e.g. Drools or rules in code), which enforces, among other things, floor/ceiling, psychological thresholds (e.g. 99,99) and compliance with price lists. Such a rule engine does not “break” AI, but acts as a safeguard for the brand and operations, because the model optimises under ideal conditions, while the constraints protect against decisions that nobody wants to deliver in production.

Auditability requires logging what informed the decision and how the final price was created: input features, model version, applied constraints and the result. This makes it easier to handle complaints and analyse why the system behaved differently than expected. Because costs and margins are sensitive, roles (RBAC), encryption and environment separation are used, as well as limits on changes, approval for expensive SKUs and detection of input data manipulation. Implementation usually starts with a POC on 1–3 categories with 4–8 weeks of test data and a “what if” simulation (backtesting), while production requires agreement on the price approval process, integration with checkout and clearly defined KPIs.

Pricing strategies and business constraints

Pricing strategies and business constraints in dynamic pricing come down to setting “guardrails”, i.e. the framework within which AI can recommend a price. Most often a minimum price (floor) is defined, e.g. cost + 5–15% margin, and a maximum price (ceiling), e.g. no more than +20% versus the competitor median. These thresholds answer the question of why AI does not choose the “highest possible” price: the constraints are meant to protect conversion, reputation and consistency with pricing policy. In practice, guardrails also take into account compliance with the manufacturer’s MSRP, if this is required in a given category.

The frequency and amplitude of price changes are limited so that customers do not feel that prices are “jumping”. Typical rules include a maximum change of 3–7% per day or a limit of one change every 24 hours for selected categories, while in on-demand services adjustments may appear more frequently, provided clear rules apply (e.g. a higher price at peak times). At the same time, price psychology and rounding are used, because businesses usually prefer endings such as 99.99 rather than values like 103.27 zł. Mapping to a price grid (e.g. 0.50 zł steps or ending thresholds) usually only slightly worsens optimisation, while improving consistency and the perception of the price.

The strategy should take into account differences between sales channels, because costs and price elasticity are not the same in a собственный store and on a marketplace. For example, a marketplace commission of 8–15% may require a higher minimum price threshold than in a direct-to-consumer model. In a product portfolio, relational constraints are also introduced so that the “better” variant is not cheaper than the “worse” one (e.g. 256 GB is always ≥ 128 GB), and in price wars a minimum margin and “ignore outliers” rules are used (e.g. ignoring prices below the 5th percentile). For premium brands, narrower ranges, a lower change frequency and a greater focus on benefits rather than discounts are maintained (e.g. free delivery, extended warranty) so as not to dilute positioning.

1. 01Defining guardrailsSetting AI boundaries.
2. 02Setting price thresholds (min/max price)Minimum and maximum safe prices.
3. 03Protecting conversion and reputation (constraints)Consistency with policy, MSRP.
4. 04Controlling frequency and amplitude (frequency)Limit of changes per day.

Guardrails and constraints protect business consistency and customer trust.

Effectiveness testing and KPI monitoring

Effectiveness testing and KPI monitoring involve comparing the results of an AI-based pricing strategy with a control group and continuously detecting situations where the model stops working in line with the intended goal. Results are most often analysed by category and segment, because the effect can differ for different SKUs and channels. In dynamic pricing, profit and margin are usually key rather than revenue alone, because the model can easily “buy” GMV at the expense of profitability. To get a fuller picture, indirect metrics that signal side effects are also tracked.

• Business metrics: revenue, gross margin, profit, GMV, average basket value, conversion.
• Market and visibility metrics: price position vs competition, share of exposure, CTR.
• Model quality metrics: feature drift (e.g. competitor prices) and relationship drift (a drop in forecast accuracy).
• Tests and validations: A/B price tests and backtesting, to assess risks and the correctness of recommendations before implementation.

An A/B test involves randomly assigning traffic or SKUs to a group with AI pricing and to a control group, most often for 2–6 weeks, over a horizon matched to volume. To minimise side effects, the experiment is run at SKU or user level, while taking cannibalisation and cross-elasticity into account. Backtesting makes it possible to check recommendations on historical data in a “what if” scenario, which does not replace an A/B test, but helps to identify data errors and risky signals (e.g. a mass move down to the floor). After implementation, continuous tracking of drift and prediction quality remains key, because market realities can change faster than the assumptions adopted during training.

Operational monitoring should be supplemented with alerts and dashboards so that the business can see exactly what changed in prices and why. For example, an alert “20% drop in conversion with steady traffic” may suggest that the model overestimated elasticity for a given segment or SKU, while safety thresholds can catch situations such as “price >Y% above the market median” or “price change of >X%”. Good panels for the team show the recommendation versus the final price, the reason for constraints (floor/ceiling), the impact on margin and the list of SKUs with the greatest impact on results, which makes it easier to manage exceptions (e.g. a manual price block for 7 days). Experiment results should feed the model as training data, and after 2–3 testing cycles (e.g. quarterly) it is possible to clearly improve elasticity estimation for key SKUs.

Legal, ethical aspects and implementation risks

The legal, ethical aspects and implementation risks of dynamic pricing with AI come down to ensuring that prices are presented clearly, and that the mechanisms do not mislead customers or breach fair trading rules. In many jurisdictions, rules apply to price presentation and promotional transparency, including a ban on artificially inflating a price before a discount. Dynamic pricing is usually legal, provided the price communication remains unambiguous and you do not use practices that may be deemed unfair. If the price depends on a user profile, you enter the area of profiling and personal data, which requires a legal basis and compliance with information obligations.

The most serious ethical risk remains price discrimination, where the model indirectly relies on characteristics correlated with sensitive attributes (e.g. postcode). To prevent this, fairness audits are carried out, the degree of price personalisation is limited, and offers are more often split into packages or discounts based on objective criteria (e.g. a loyalty programme) rather than setting a “tailor-made” price for a specific person. In markets with automatic reactions to competitors’ actions, there is also the risk of unintended price coordination (“algorithmic collusion”), which is why rules such as “always +1% above X” are avoided, and in oligopolies the strategy is discussed with lawyers. In sensitive sectors, it is worth introducing limits in advance and an “emergency cap” mode to limit sudden increases in exceptional situations (e.g. to +10–15%).

Implementation risks also include manipulation of input signals, because competitors or bots may trigger decreases or increases through planted prices on the web or artificially generated traffic. The response is source filtering, domain reputation assessment, bot detection (e.g. Cloudflare Bot Management) and the principle that the price does not change solely on the basis of one source. On the operational side, it is crucial to designate the process owner (usually the pricing manager) and clearly define roles in the RACI model: who recommends changes, who approves exceptions and who responds to incidents. The system should also have an SLA and a degradation mode (reverting to the last good price or base rules) with the option of rollback, while communication with customers is supported by a consistent pricing policy and practices that limit the visibility of fluctuations, e.g. price stabilisation for logged-in customers for a set period (e.g. 24h) or a price lock after adding to the basket.