Tecof • September 15, 2026
AI-Driven Pricing Strategy: What Is Dynamic Pricing?
In Brief
Dynamic pricing is the practice of regularly updating a product's selling price through defined rules or models, based on variables such as demand, stock, cost, competition and sales channel. The approach has been standard in airlines and hospitality for decades, and the growth of marketplace volume and data access has now put it on the agenda of mid-sized e-commerce operations in Turkey as well. The range of implementations is wide, from simple rule-based scenarios to machine learning models that forecast demand, but not every point on that range is right for every business. As of 2026 the question is no longer whether you will change prices automatically, but within which limits, on which data, and how transparently you will change them.
Thursday afternoon, 14.40. The pricing lead at a home textiles brand is looking at seven days of performance for a duvet set in the Trendyol panel. The product was listed at 1,849 TL and sold an average of 34 units a day. On Monday morning a competing seller dropped to 1,799 TL in the same category; by Tuesday sales had fallen to 21 units. The pricing lead cut to 1,789 TL on Tuesday evening and sales climbed back to 37 units. But the table finance circulated on Wednesday shows item-level gross margin down from 31 percent to 24 percent. Because shipping and commission stayed flat, the 50 TL discount came straight out of margin. In the same week a second competitor moved to 1,759 TL. Four sellers are now squeezed into the 1,750-1,800 TL band; each is watching the others' price and none is watching demand. Over seven days the category average price fell 5 percent while total category unit volume barely moved.
The problem is not that prices change, but what they respond to. In the picture above every seller is reacting to a competitor's price; nobody is measuring how the customer reacts to price. A competitor's price is an input, not a target. Every discount made without knowing the demand curve is margin spent without ever being tested. Dynamic pricing works where price is tuned to demand, stock turnover and channel cost rather than to the competition.
What Dynamic Pricing Is Not
Building a system before defining the term is the most common mistake we see in the field. Three very different things get discussed under the same heading, and their risks and benefits are not the same.
Rule-based pricing
The most common and safest starting point. Predefined logic chains run: "if stock falls below 20 units, raise the price by 3 percent", "if the competitor's price is above my floor price, position 1 TL below it", "apply a weekly 5 percent markdown on end-of-season items that have not sold for more than 45 days". The great advantage of a rule-based system is auditability: the answer to "why did this price change" is written in a single line of rule. The disadvantage is that as the number of rules grows, contradictory rules appear and nobody can predict the outcome.
AI-based pricing
Here a model estimates the demand curve from historical sales data and proposes a price against a defined objective, whether revenue, gross margin or stock turnover. Making it work requires a serious data threshold: at least a few hundred transactions per product, observations at different price levels, and at least a full year of history to capture seasonality. If your catalogue has 5,000 SKUs and 4,200 of them sell fewer than three units a month, a model has nothing meaningful to say about that long tail. In practice the right setup is hybrid: model recommendations for the high-volume top 10-20 percent of SKUs, a rule-based framework for the rest. Consistent product codes are a precondition for making that split at all; if your SKU structure is messy, no model will see a clean demand signal.
Why personalised pricing is the wrong path
Showing the same product to two different customers at the same moment at different prices, based on their personal histories, is technically possible. But the reputational and regulatory risk it carries far outweighs the margin it produces. The reputational side is simple: if a customer sees the same product cheaper on a friend's phone, that screenshot travels on social media and the brand's price credibility is lost in one go. On the regulatory side, differentiating price per individual on the basis of personal data raises questions of personal data processing and profiling under KVKK, and can sit awkwardly with the transparency and good-faith principles of consumer legislation. The right approach is to tie price to context rather than to a person:
- Segment-based pricing: applying different price lists to contractually defined groups such as dealers, corporate accounts or retail customers. The customer knows which list they are on and why.
- Channel-based pricing: applying different prices on your own site, on Trendyol and on Hepsiburada. Because each channel has different commission, shipping and advertising costs, this is economically defensible and transparent to the customer.
- Time-based pricing: changing price by season, campaign period, day of the week or stock age. At any given moment the price is the same for everyone; it only varies over time.
- Basket and volume-based pricing: rules such as "buy 3 pay for 2" or free shipping above a threshold. The condition is public and anyone who wants it can qualify.
Staying within these four gives you most of the benefit of dynamic pricing without the exposure. If you want to give an individual discount, do it through coupons and a loyalty programme rather than through the price tag itself: a customer knows and accepts that they used a coupon, but will not accept discovering that the price was quietly changed for them.
Price Elasticity: Do Not Change Prices Without Measuring
What elasticity actually tells you
Price elasticity measures the percentage change in units sold in response to a one percent change in price. For a product with an elasticity of 2, cutting the price by 10 percent lifts units by roughly 20 percent; for one with an elasticity of 0.5, the same cut lifts units by only 5 percent and your revenue falls. The general pattern we see in the field is this: elasticity is high for standardised, well-known products sold by many sellers on a marketplace, and low for design-led items, single-seller listings and need-driven purchases such as spare parts. Applying the same discount policy to both means losing money on one and missing the opportunity on the other.
How to measure elasticity
Deriving elasticity from historical data is impossible for most catalogues, because price has rarely changed, or every change coincided with a campaign. Clean measurement requires a planned test: split similar products into two groups, hold price constant in one, apply a defined percentage in the other for two weeks, and try to hold traffic and season steady. Bringing A/B testing discipline to the pricing side turns your elasticity estimate from a guess into a measurement. Read the result in gross profit, not units alone; if units rise and profit falls, the test failed.
Psychological price thresholds
The price curve is not smooth; there are breaks just below and above certain round numbers. In the Turkish market, prices ending in 99 and 90, and round thresholds such as 500, 1,000 and 2,500 TL, make a visible difference to conversion. The 50 TL between 1,049 TL and 999 TL does not have the same effect as the 50 TL between 1,199 TL and 1,149 TL. If your automated pricing engine has no threshold definition, it will produce prices like 1,002 TL that are both ugly and conversion-damaging. A rule layer that rounds every engine recommendation to the nearest permitted threshold is essential.
| Product type | Typical elasticity range | Suitable pricing tool | Change frequency |
|---|---|---|---|
| Standard product, many marketplace sellers | 1.5 - 3.0 | Competitor tracking + floor price | Daily |
| Own brand, sole seller | 0.6 - 1.2 | Demand model + campaign calendar | Weekly |
| Spare parts / technical items | 0.3 - 0.8 | Cost plus margin | Monthly |
| Seasonal textiles, end of stock | 2.0 - 4.0 | Tiered markdown by stock age | Weekly |
| Gift / occasion products | 0.8 - 1.5 | Time-based campaign | Seasonal |
Marketplace Dynamics and Competitor Price Tracking
Buy box logic and the role of price
On marketplaces where several sellers list the same product, the default "add to cart" area on the product page goes to one of them. Trendyol and Hepsiburada consider price when making that choice, but not only price: seller rating, dispatch time, cancellation and return rates, stock continuity and customer satisfaction metrics all feed in. What we see in practice is that a seller with a weak operational score cannot win the box even at the lowest price, while a seller with a strong score can hold it a few lira higher. This means pricing strategy is directly tied to operational quality. In some categories, shortening delivery by one day is cheaper than a 3 percent discount.
Data quality in competitor tracking
Three mistakes recur when collecting competitor prices. First, comparing the label price instead of the total landed cost; 1,799 TL plus 89 TL shipping is not on the same shelf as 1,849 TL with free shipping. Second, matching by product name; "white double duvet set" can point to three different fabric weights, and matching should be done on barcode or product code. Third, pulling data once a day and missing intraday moves. Real-time tracking is not needed in every category, but in fast-moving ones a single daily pull makes you the party responding in the evening to a discount your competitor made in the morning.
Escaping the price war trap
The best-known side effect of automated tracking systems is the downward spiral in which everyone follows everyone. That is exactly what happens in the opening example: category price falls, total demand does not rise, and everyone's margin erodes. The way out is floor price discipline. Calculate a floor for every SKU including cost, commission, shipping, returns allowance and advertising cost, and make it technically impossible for the engine to go below it. To see what an order below the floor actually costs you, you need to break out your ROAS calculation by category; a floor that excludes advertising cost is not a floor.
| Cost item | Your own site | Marketplace A | Marketplace B |
|---|---|---|---|
| Product cost | 620 TL | 620 TL | 620 TL |
| Commission | 0 | 18% (~198 TL) | 21% (~231 TL) |
| Shipping and packaging | 95 TL | 75 TL | 75 TL |
| Advertising / traffic share | 145 TL | 90 TL | 110 TL |
| Returns and damage allowance | 35 TL | 60 TL | 65 TL |
| Floor price (zero margin) | 895 TL | 1,043 TL | 1,101 TL |
| Target price at 20% margin | 1,119 TL | 1,304 TL | 1,376 TL |
The real message in the table is this: price differences between channels are not arbitrary, they are the natural consequence of the cost structure. Offering the same product at a better price on your own site is a defensible choice and one you can explain openly to customers.
Margin Protection, Campaigns and Change Frequency
How the campaign calendar relates to the engine
Certain weeks of the year are abnormal for pricing in Turkey: the November discount period, New Year, season transitions, back-to-school and the weeks before religious holidays. A typical mistake is for the pricing engine to read those periods as ordinary demand and derive permanent rules from them. Load campaign periods into the calendar in advance and flag those ranges as a separate variable during model training. Otherwise the engine treats the 400 units sold in November as normal demand and holds January prices needlessly low.
Discount depth and basket effect
Read the discount decision at basket level, not product level. If a product sold at low margin adds on average two more items to the basket, its job is not to make profit but to open the basket. To draw that distinction you need transaction-level rather than product-level reporting, and you need to track average order value separately for discounted and non-discounted transactions. What we commonly see in the field is that 10 percent of the catalogue opens baskets, 15 percent carries profit, and the rest is dead stock doing neither.
How change frequency affects customer trust
Frequent price changes are not a problem in themselves; unpredictable ones are. If a customer sees the price of a product in their cart drop by 80 TL the next day, they learn to wait on the next purchase. That permanently depresses conversion and makes the expectation of a discount permanent too. Practical rules: keep the daily change ceiling in the 5-7 percent band, do not allow more than one change per SKU within 24 hours, be more conservative on upward moves, and hold off applying price increases for a defined period on items already in a cart. If you do not read your conversion rate work alongside price change frequency, you will look for the cause of falling conversion in the wrong place.
Legal Limits and the KVKK Perspective
Price and discount display rules
In consumer sales in Turkey, price information must be presented clearly, legibly and without misleading the buyer. When a sale is discounted, the price before the discount is expected to be shown and to be a price that was genuinely applied. For dynamic pricing the practical meaning is this: the engine cannot raise a price and immediately return it to the earlier level under a "discount" label. A struck-through price must be a price that was actually in effect for a period. For that reason, keep price history per product with timestamps; that record is what both internal audit and any external review will need.
Care with "lowest price" claims
Statements such as "lowest price of the year" or "the best price you will see" must be verifiable. Embedding such claims in static marketing copy while an automated engine is running is risky, because the price may fall further a week later and the claim becomes misleading in hindsight. The safe route is to limit these statements to fields fed and verified by the system, or not to use them at all. The general rule: do not let an automated system say something you could not say yourself.
KVKK and the risk of personalised pricing
Producing an individual price for a specific customer on the basis of personal data constitutes processing of personal data under KVKK and brings profiling into the discussion. What the legal basis is, how the disclosure obligation is met, and how the customer exercises their right to object all need clear answers. It is possible to build a structure that answers all of these soundly, but in most cases its cost and risk exceed the margin gained. Segment, channel and time-based pricing deliver most of the same economic benefit without processing personal data. Having the price on a product page be the same for everyone looking at that page at that moment is a position that is both easy to defend and easy to explain.
Auditability: being able to explain the engine's decision
Keep a record showing who changed a price, under which rule and with which inputs. That record is needed not only for compliance but for operations: if a product's price changed three times in three days and sales fell, only this record can explain why. Running automation without authority limits is the most expensive mistake in dynamic pricing. At Tecof, pricing rules and AI agents can be run within defined authority limits, so changes above a set threshold fall to human approval.
Technical Setup: ERP and Marketplace Integration
The single source of truth problem
The pricing engine's first question is: where does this product's price live? In most operations the answer is scattered. There is a list price on the Logo, Mikro or Netsis side; a different price on the e-commerce site; a third price in the marketplace panels. Someone edits the panel by hand, the ERP transfer overwrites it, and nobody knows which is correct. The first step of any setup is to have price produced in one place and distributed from there to every other channel. The ERP is usually the source of cost and list price, while the selling price is calculated in the pricing engine and written out to channels. Reverse writes must be switched off.
The integration layer and latency
How long a price update takes to reach a channel directly determines your strategy. On marketplace APIs, processing an update and having it appear on the storefront can take minutes, and bulk updates take longer. If you design a strategy that reacts by the minute while your infrastructure runs hourly, you will always be late. The realistic move is to set the update window according to your infrastructure's capacity and to write that window into the strategy. Error handling in the integration architecture matters just as much: if a failed price update disappears silently, the old price stays live on the channel and you sell at a loss. Run a verification read for every update.
Setup options
| Approach | Suitable scale | Setup time | Monthly upkeep | Main risk |
|---|---|---|---|---|
| Manual panel management | <300 SKUs | - | High (person-dependent) | Inconsistency, slow response |
| Excel + bulk upload | 300-1,500 SKUs | 1-2 weeks | Medium | Version confusion |
| Rule-based engine | 1,000-20,000 SKUs | 3-5 weeks | Low | Conflicting rules |
| Hybrid (rules + model) | 5,000+ SKUs | 8-12 weeks | Medium | Data quality |
For most operations in Turkey the right answer is the third row. Moving to the fourth makes sense only once the third is running properly and the data infrastructure has settled. Trying to build a model before ERP and marketplace integrations are complete is like roofing a building with no foundation.
Setting Up Dynamic Pricing in 30 Days
Days 1-7: Establish cost and floor price
Work out the true unit cost for every SKU: purchase price, freight, storage share, packaging, channel commission, shipping, returns allowance and advertising share. Pull this table from the ERP and fill the missing items by hand. By the end you should have a channel-level floor price list for every SKU. In the same week, gather the last 12 months of price and sales history into a single table and see how many times each product's price changed. Most teams discover at this step that a third of the catalogue has not had a price change in years.
Days 8-14: Write the rule set and define the limits
Start with at most 12-15 rules; more than that is unmanageable in the first month. For each rule write the trigger, the action, the ceiling and the priority order. Define these without exception: maximum daily change percentage, floor price lock, the list of psychological rounding thresholds, and the threshold requiring human approval. Run the rules first in "recommend only, do not apply" mode. Watch what the engine proposes for a week without acting on it.
Days 15-21: Limited pilot
Take the engine live on a high-volume, competitive product group covering 5-10 percent of the catalogue. Keep managing a similar group the old way as a control. Track daily: gross margin, units, average order value, buy box share and return rate. At least once during this week a situation will arise where rules contradict each other; if it does not, your rules are probably too loose.
Days 22-30: Roll out and audit
Compare pilot results against the control group and revise the rule set. Extend coverage to 30-40 percent of the catalogue; do not go to the whole catalogue in one month. At this stage make the price change log, the weekly margin report and the approval flow permanent. By the end of the month you should have three things: a working rule set, a measurable margin comparison, and a timestamped record of price history.
Here is the job for tomorrow morning: open your 20 best-selling products, add up product cost, channel commission, shipping, returns allowance and advertising cost for each to calculate the true floor price, then put that number side by side with today's selling price. Most teams that do this exercise find at least two of the first 20 are selling at a loss or at close to zero margin. Finding those two products is the step to take before buying any software.
Frequently Asked Questions
Does dynamic pricing make sense for a small store?
For catalogues under 500 SKUs a fully automated engine usually does not pay for itself, but the rule logic is still useful. Floor price calculation, tiered markdown by stock age and threshold discipline can all be applied by hand. The practical trigger for automation is when pricing decisions start taking more than a few hours a week.
Is automated competitor price tracking legal?
Monitoring publicly published price information is generally not problematic; the issue is how that information is collected and used. Avoid collection methods that breach a marketplace's own terms of use, and stay away from any coordination that could look like a price agreement with competitors. Tracking must remain a one-sided observation.
How many times a day should we change prices?
Once a day is enough for most categories and safer for customer trust. In electronics and fast-moving marketplace categories two or three times a day may be needed. If you change the same SKU more than once within a day, you should be able to prove it produces a measurable margin or buy box gain.
What can we use instead of personalised pricing?
Coupon codes, discounts tied to loyalty tier, tiered benefits based on basket value, and channel-level price differences. What these tools share is that the condition is public and known to the customer. If the customer can explain why they are seeing that price, the mechanism is safe.
How much data do we need to build a model?
A meaningful demand forecast per product generally needs at least a year of history, observations at different price levels and a few hundred transactions per product. In most catalogues the number of SKUs clearing that bar is 10-20 percent of the total. A rule-based approach gives better results for the rest.
Does cutting the price guarantee the buy box?
No. Marketplaces also weigh operational metrics such as seller rating, dispatch time, and cancellation and return rates. A seller with a low operational score may not win the box even at the cheapest price. In most cases shortening delivery time is a cheaper route to the same gain than cutting price.
How should we set the struck-through price?
A struck-through price must be a selling price that was genuinely in effect for a period. Referencing a price at which nothing ever sold is misleading. Keep price history with timestamps and base your discount display on that record.
Should we manage prices from the ERP or the marketplace panel?
Neither is sufficient alone. The ERP should be the source of cost and list price, while the selling price is calculated in a central pricing layer and written out to channels. If you allow manual panel edits, everyone needs to know that such an edit will be overwritten on the next transfer.
How much do price changes affect customer trust?
The effect depends less on the size of the change than on its predictability. An expected markdown at season transition does not shake trust; a cart item becoming noticeably cheaper the next day does. Setting a daily change ceiling and delaying price increases on items already in carts reduces this risk noticeably.
When do you move from a rule-based system to a model?
When the rule-based system has run cleanly for at least three months, price and sales history is being recorded properly, and systematic losses the rule set cannot explain start appearing. Building a model before those three conditions are met produces nothing more than a system that processes bad data faster.