AI in E-Commerce 2026: Demand Forecasting, Recommendations, and Service (Turkey)

TL;DR — In Turkish e-commerce, AI has moved past the "let's try it and see" stage; from what I observe in the field, demand forecasting and customer service come first, because both touch stock cost, operational load, and conversion directly. In this post I walk through concrete use cases with field scenarios — from demand forecasting to recommendation engines, from semantic search to dynamic pricing, from agentic customer service to returns and fraud detection — explaining what data each one needs, what value it produces, and where you must be careful under KVKK (Turkey's data protection law). At the end, for those asking "where do I start tomorrow morning," I leave a prioritization framework and a 90-day starter roadmap. I deliberately give ROI figures as illustrative examples; your result comes from your data, not mine.

The clearest change I've observed in the field over the last two years is this: AI is no longer sitting on a marketing team's slide as a "future vision"; it has become a concrete agenda item at the operations, procurement, customer service, and finance tables. Nearly all of the mid- and large-scale e-commerce companies I speak with are running at least one AI project, either in pilot or in production. But let me be honest: some of these projects are still stuck at "we bought a tool, we're not quite sure what to do with it." Closing exactly this gap is the whole point of this post.

In Turkish e-commerce, demand forecasting and customer service are being prioritized as the first AI application areas. I don't think that's a coincidence. Demand forecasting touches stock cost and cash flow directly, so finance backs it too; customer service is concrete in senior management's eyes because it affects both cost and customer satisfaction at once. The expected benefits are also stated clearly: reduction in stock and operational cost together with improvement in conversion rate. Those two sentences sound simple, but behind them lies a serious data discipline.

There's also an important development on the macro side. Turkey's National AI Action Plan 2026–2030 includes opening access to public datasets; the goal is to open data in areas such as health, agriculture, defense, and e-commerce, and to make at least 2,000 public datasets available through a National Data Library. Why do I care about this? Because in e-commerce the biggest bottleneck is often not the model itself but the clean, rich data that feeds it. Opening public datasets — especially for demand forecasting and market analysis — could mean a richness that small and mid-sized players cannot access today.

"

A field observation: The most common reason AI projects fail is not model choice but the failure to clearly answer "which business problem are we solving?" First the problem, then the data, and the model last. Almost everyone who breaks this order ends up asking, six months later, "why did we even do this?"

I'll unpack the use cases one by one in this post. But let me give a framework up front: I evaluate every use case with three questions. First, which business metric does it move (stock, conversion, returns, cost)? Second, which data does it need, and do I have it? Third, under KVKK, which risk door does it open? I'd say don't start any project without clarifying these three.

I deliberately put demand forecasting first, because it's the most concrete and fastest-returning area I see in the field. The logic is simple: by looking at your historical sales, seasonality, campaign calendar, price changes, and — where possible — external signals (weather, holidays, competitor price moves), you forecast how much demand each product will see in the coming period. An accurate forecast pays off in two directions: you don't hold more stock than needed (less tied-up capital, warehouse cost, end-of-season discounting) and you don't lose sales by running out.

For Turkey specifically, several local realities make demand forecasting harder, and models that ignore them end in disappointment. High and volatile inflation causes prices to change quickly, which makes using historical unit sales as-is risky. Currency movements directly affect cost and price for imported goods. Campaign intensity (special days, mega discount days) pulls demand away from its normal course. A good forecasting model must explicitly incorporate these variables; otherwise "we sold 100 this week last year, so we'll sell 100 again" simply doesn't hold in Turkey.

In practice the approach I recommend is staged. First, use ABC analysis to separate products by their weight in revenue. The most critical top 20% of products usually makes up the bulk of revenue; focus your first model on this group. For the thousands of long-tail (rarely selling) products, simple statistical methods are enough at the start; spending months of engineering effort on them isn't worth it.

"

Field scenario: Working with a fashion retailer, we saw that the biggest gain came not from a sophisticated deep learning model but from feeding the campaign calendar and size-level sales distribution into the model properly. Sometimes it's not the model but structuring the data correctly that creates the value.

The KVKK risk in demand forecasting is relatively low, because you mostly use aggregated data at the product and transaction level; you don't build individual profiles. Still, note: the moment you start personalizing the forecast model by customer segments, the work turns into processing personal data and the KVKK door opens.

Recommendation engines are perhaps the most visible AI application in e-commerce. "People who bought this also bought that," "picked for you," the personalized storefront on the homepage, complementary product suggestions in the cart... all members of the same family. A well-designed recommendation system can noticeably lift average basket size and conversion rate. But that very power also creates the area requiring the most care under KVKK, because a recommendation system by nature performs profiling.

On the technical side, recommendation systems have a few core approaches. Collaborative filtering builds on the preferences of similarly behaving users. Content-based methods look at product attributes. Modern systems blend the two and increasingly use deep learning-based embedding methods. The most common mistake I encounter in Turkey is underestimating the "cold start" problem: for a new user and a new product there is no past behavior, so the first recommendations are weak. That's why a hybrid strategy and a good default (popularity, category, editor's pick) are essential.

The point I insistently underline in personalization is this: personalization is a means, not an end. The goal is to help the customer find what they're looking for faster and to show the relevant product. Excessive personalization sometimes backfires; when the customer keeps meeting the same type of product, the sense of discovery is lost. Good systems balance relevance and discovery.

On the KVKK side, I recommend clarifying three things for recommendation systems. First, what is the legal basis for personalization (explicit consent, or legitimate interest)? Second, is the customer transparently informed that this profiling is happening? Third, can the customer turn personalization off? Moving to scaled personalization without resolving these three will cause you headaches in future audits.

On-site search is one of the most underrated areas in e-commerce, yet one of the biggest drivers of conversion. A customer who searches is the customer with the highest purchase intent; they know what they want. Classic keyword-based search, however, struggles with the pains of Turkish: suffixes, spelling variations, synonyms, mixed English-Turkish terms... If someone searching for "wireless headphones" types "bluetooth kulaklik" and comes back empty-handed, you've lost that sale.

This is where semantic search comes in. Meaning-based (embedding) search looks not at literal word matching but at the closeness of intent and context. A search for "light summer jacket" can reach the right products even if those exact words don't appear in the product description. For Turkish this is especially valuable, because the morphological richness of our language strains classic search. The good implementations I see in the field put semantic search not in place of classic search but alongside it: with hybrid scoring, they blend both exact matching and semantic proximity.

"

A field note: An e-commerce site that doesn't measure how many customers see "no results found" in the search box is sitting in a blind spot. Reviewing these "zero result" queries weekly is the cheapest way to see both catalog gaps and search quality.

The KVKK dimension of semantic search is relatively light, because queries can mostly be treated anonymously. But if you do person-specific search ranking (different ordering based on the person's history), you enter the profiling area again and must apply the same rules as for recommendation systems.

Dynamic pricing aims to adjust price automatically based on demand, stock, competitor prices, and customer segment. Done right, it can optimize margin and sales volume together. But let me be blunt: this is one of the most delicate areas technically, ethically, and legally, and I strongly advise against rushing it.

When designing dynamic pricing in Turkey, keep three boundaries especially in mind. First, consumer perception and trust: a customer who sees the same product at different prices five minutes apart loses trust and shares it on social media instantly. Second, the legal framework: unfair price increases, excessive pricing, and consumer protection legislation are matters closely followed in Turkey. Third, person-specific pricing is especially risky; showing a customer a different price based on their device, location, or history carries serious discrimination and profiling risk under both KVKK and consumer law.

My recommendation is to start dynamic pricing product- and time-based, not segment-based: campaigns on overstocked products, automatic end-of-season discounts, category-based adjustments following competitor price tracking. These produce value without profiling the customer individually. Approach person-specific pricing only very cautiously, and only after firmly establishing the legal and ethical framework.

Customer service, together with demand forecasting, is the most prioritized area in Turkey; and over the past year there's been a real leap here. Old-generation chatbots were tools that couldn't step outside pre-written scripts and led customers into dead ends. Agentic (action-taking) systems are different: they not only generate answers but can actually take actions — querying order status, initiating returns, tracking shipments, product exchanges — within the limits defined for them, of course.

The operational value of this is large. A well-designed agentic support layer resolves a serious share of repetitive, simple requests without them reaching a human agent; the human agent then focuses on genuinely complex, empathy-requiring, high-value matters. So the goal isn't to remove people from work, but to position people in the right place. The successful setups I see in the field all operate with this philosophy.

"

Field scenario: When setting up an agentic support assistant, our most critical decision was clearly defining the threshold for "when should the assistant hand off to a human." If the customer is dissatisfied twice in a row, if there's an anger signal, or if it's a financially risky transaction, the system quietly hands off to a human. Systems without this handoff rule produce maximum dissatisfaction at exactly the wrong moment.

There are three technical things to watch in agentic systems. First, hallucination control: the assistant must not make up things it doesn't know; for this, an architecture that grounds answers in the company's real knowledge base (retrieval-based) is essential. Second, limiting action authority: what transactions the assistant can perform, up to what amount it can approve a return, must be clearly defined. Third, logging and auditability: every action must be logged so it can be accounted for later.

Under KVKK, the customer service assistant is an important area, because the customer shares plenty of personal data during the conversation (name, address, order, sometimes much more). Where this data is processed, how long it is retained, and especially whether it goes to an AI service hosted outside Turkey is critical. I address this under a separate heading below.

Two items quietly eat into profit in e-commerce: high return rates and fraud. AI is valuable in both, because both are pattern-recognition problems. On the returns side, the model can learn which product-customer-campaign combinations produce high returns; this turns into concrete actions like "let's not show this product to this segment this way" or "let's fix the size chart." In Turkey, return rates in fashion and apparel especially are a serious cost item; even small improvements here add up to large sums in total.

In fraud detection, the model catches anomalous behavior patterns (unusual order frequency, fake account signals, payment anomalies, abused campaign codes) in real time. The value here is two-sided: you both prevent direct loss and strike a delicate balance so as not to wrongly block honest customers. An overly aggressive fraud model loses more than it protects by turning away real customers.

"

A field warning: Don't overlook your fraud model's "false positive" rate. Of every suspicious transaction the system blocks, how many were actually honest customers? Teams that don't ask this question unknowingly turn away good customers at the door.

Under KVKK, fraud detection falls into the automated decision area, and this is a sensitive matter. A system that automatically rejects a customer's order or suspends their account touches KVKK's framework of "fully automated decisions producing consequences against the person." Here, human review (human-in-the-loop) and granting the customer a right to object are what's right both legally and ethically.

The fastest-adopted area of generative AI has been content generation; product descriptions, category texts, email campaigns, social media posts, visual variations... While writing a unique, SEO-friendly description for every product in a catalog of thousands is nearly impossible with human effort, AI can do it at scale. The speed gain I see in the field is real and large.

But two traps get fallen into here. First, quality and brand voice: because a machine produced it, if you publish every text as-is, your catalog becomes monotonous and soulless; the brand's distinctive voice is lost. Second, accuracy: AI can add a feature the product doesn't have to its description (hallucination). Wrong product information means returns, loss of trust, and legal problems. So my model in content generation is always the same: the machine produces, the human approves. Especially for products with technical specifications, human control is non-negotiable.

The KVKK risk of content generation is relatively low, because you usually don't process personal data. The exception is when you generate person-specific marketing content; there the profiling rules kick in again. Also watch copyright and trademark: make sure the generated visuals and texts don't infringe third parties' rights.

You can use the table below as a quick checklist when evaluating a project. In each row I've tried to answer "what does this gain, what do I need for it, and where do I watch out under KVKK."

Use case	Value produced	Data needed	KVKK note
Demand forecasting	Lower stock and operational cost, fewer stockouts	Historical sales, campaign calendar, price/FX, seasonality	Low risk; aggregated data, no individual profile
Recommendation systems	Higher conversion and basket size	User behavior, product attributes, purchase history	High care; profiling, legal basis and transparency required
Semantic search	Search conversion, lower "no results" rate	Product catalog, descriptions, query logs	Anonymous queries low risk; person-specific ranking is profiling
Dynamic pricing	Margin and volume optimization	Demand, stock, competitor price, cost	High risk; person-specific price is discrimination/profiling risk
Agentic customer service	Faster resolution, lower operational cost	Knowledge base, order/shipping systems, past requests	High care; lots of personal data in conversation, cross-border risk
Returns prediction	Reduced returns cost	Product, returns history, size/segment data	Medium; if segment-based, watch profiling rules
Fraud detection	Direct loss prevention	Transaction, payment, behavior, device signals	High care; automated decision, human review required
Content generation	Content at scale, speed gain	Product data, brand voice guide, sample texts	Low; profiling for person-specific content, copyright/trademark care

I place particular importance here, because this is the area most often skipped and carrying the most penalty risk in the field. In e-commerce, AI mostly processes personal data; recommendations, personalization, fraud, and customer service fall directly into this area. KVKK's November 2025 Generative AI and Personal Data Protection guide is a guiding resource on this, and I strongly recommend reading it with your team before sitting down to work.

I especially underline two headings. First, profiling and automated decisions. Applications like recommendation systems, person-specific pricing, and fraud prevention profile the person and sometimes produce automated decisions that have consequences against the person. What's required here: a clear legal basis (explicit consent or a legitimate interest assessment), transparent notice to the customer, the possibility of objection and human intervention for fully automated decisions against the person, and processing limited to its purpose.

Second, and perhaps the most overlooked, cross-border data transfer. Today many AI services (especially large language models) host their servers outside Turkey. When you send your customer's personal data to such a service, this may constitute a transfer of data abroad and becomes subject to KVKK's transfer rules. So saying "we connected to an API and it works" isn't enough; you need to know where that API moves the data and through which legal mechanism it transfers it.

"

Let's think in numbers: For 2026, KVKK administrative fines range roughly from 85,437 TL to 17,092,242 TL. When calculating the return of an AI project, put the penalty risk of non-compliance at this scale into the same table. Often the cost of building it right from the start is far below the cost of later correction and penalty risk.

My practical recommendations: anonymize or pseudonymize sensitive personal data as much as possible before sending it to the model. Where possible, prefer solutions that process data within Turkey or guarantee data residency. Keep a data processing inventory for each AI use case: which data, for what purpose, where it goes, how long it's retained. And involve the legal/compliance team at the beginning of the project, not the end. The most expensive mistakes I see in the field always come from those who say "let's do it first, we'll look at compliance later."

The answer I give in the field to "there are so many use cases, which do I start with?" always rests on the same simple framework. Score each idea on two axes: business impact (how much difference does it make to revenue/cost/satisfaction) and ease of implementation (is the data ready, how much technical and legal complexity). Multiplying these two yields a priority order.

Per this framework, the picture that typically emerges in the field is this: demand forecasting and semantic search usually sit in the "high impact, reasonable ease" zone; they are ideal starting points for those seeking quick wins. Agentic customer service is high impact but demands a bit more effort on KVKK and integration; it's tailor-made for the second wave. Person-specific pricing, though it looks high impact, is high risk; it should be deliberately left for last. This picture may come out differently at your company; what matters is honestly scoring these two axes with your own data.

When prioritizing, I remind you of three principles. Start small, measure, scale: a clear success in a single use case is better than ten half-finished pilots. Define the value up front: the answer to "what does success look like" must be written before starting the project. Assess your data honestly: if you don't have clean data, even the best model produces disappointment; sometimes the first project is actually a data collection and cleaning project.

For those wanting a concrete start, I'm sharing a 90-day setup I've seen work in the field. Take it as a skeleton, not a recipe; adapt it to your own context.

First 30 days — discovery and groundwork. In this first month, talk and take inventory more than write code. Sit with business units and clarify the three most painful problems (is it high stock, low conversion, heavy customer service load). At the same time, produce your data inventory: which data exists, at what quality, where it sits. Discuss the KVKK framework and especially the cross-border transfer policy with the legal/compliance team. By the end of this month, a single priority use case should be chosen and the "what does success look like" definition written.

30–60 days — narrow-scope pilot. Set up a narrow-scope pilot in your chosen use case (at most companies this is demand forecasting or semantic search). Target not the whole catalog but the most critical product group; not all customers but a controlled segment. Measure the metric you defined up front and always compare against a control group; "it felt good" is not a metric. At this stage, aim not for perfection but for learning.

60–90 days — evaluation and decision. Honestly evaluate the pilot's results. If you hit the metric target, make a gradual rollout plan; if not, understand why (data, setup, or problem choice) and either fix it or drop it. Dropping is not a failure but discipline. By the end of this month you should have either a gain ready to scale or a clear learning that lights the way to the next attempt.

When you turn this three-month cycle into an organizational habit, AI stops being a one-off project and becomes a continuously operating capability. The shared trait of the companies I've seen succeed in the field is exactly this: they don't declare a grand "AI transformation," they stack small, measured gains one on top of another.

Finally, let me gather the mistakes I see again and again in the field and want to warn you about up front; because most of them, if known in advance, are easily prevented.

Rushing to the tool without defining the problem. This is the most common mistake. Projects that start with "the competitor did it, let's do it too" end up directionless. First the business problem, then the data, and the tool last.

Underestimating data. A model's success is largely bounded by the data. With dirty, incomplete, inconsistent data, even the most advanced model produces disappointment. Sometimes your first investment should go not to the model but to the data infrastructure.

Leaving KVKK for last. The "let's get it running first, we'll look at compliance later" approach means both penalty risk and rebuild cost. Make compliance part of the design, don't patch it on afterward.

Removing the human from the equation. Especially in content generation, fraud, and customer service, fully automated flows are risky. At critical points, human approval and a handoff threshold are essential.

Proceeding without measuring. Projects rolled out with "I think it worked," without a control group, can never actually know whether they produce value. Define the metric up front, measure with a control group.

Over-engineering. Trying to build a deep learning model for every long-tail product is spending resources in the wrong place. Sometimes a simple rule or statistical method is sufficient and, moreover, easy to maintain.

Mistaking a pilot for scale-ready. A solution that works in a controlled pilot may not deliver the same performance across the whole catalog and all customers. Plan the rollout as a separate engineering and operations job; the real work begins where the pilot ends.

The common denominator of most of these mistakes is the same: proceeding hastily, without measuring, and ignoring compliance. I've repeatedly seen that teams which look slow but move solidly are far ahead six months later. If you treat AI in your e-commerce not as magic but as a disciplined engineering and business practice, today's examples turn into your real results tomorrow.