Tecof • September 15, 2026 • 14 dk
AI and E-commerce in 2026: Personalization and Automation
In Brief
AI is no longer a separate project heading in e-commerce; it is a layer embedded in the infrastructure itself, running everything from product recommendations to stock alerts, from support triage to price monitoring. The 2023-2024 pilot era was about impressing a board with a single demo screen; what gets asked today is the difference in conversion rate, the drop in support resolution time, and what those are worth in lira. Personalization and automation are the two revenue-producing legs of this layer, and both depend on the same precondition: clean, connectable data in sufficient volume. As of 2026 the question is no longer "should we use artificial intelligence" but "which single use case, with which data, and with which measurement setup should we start with".
Tuesday morning, 09.20. The marketing team of a home textiles brand is in the meeting room. Last quarter they licensed a recommendation engine at 42,000 TL a month and added a "Selected For You" band to the homepage. On screen are the numbers from three months later: 186,000 impressions on the band, 3,940 clicks, a click rate of 2.1 percent. Visitors who saw the band converted at 1.84 percent; those who did not, at 1.79 percent. At that sample size the gap is indistinguishable from noise. The catalogue holds 312 products, 240 of them viewed fewer than ten times in the last 90 days. The engine keeps re-showing the 40 most popular items it has — the same items already sitting in the "Best Sellers" band on the homepage. That is 42,000 TL a month, 504,000 TL a year, paid to show already-visible products one more time.
The problem is not the recommendation engine; it is the pool feeding it. A 312-product catalogue lacks the signal density individual-level recommendation requires: inferring "this person likes that" needs both enough product variety and enough interaction per person. With both missing, the model makes the safest prediction it can — it shows what is popular. That is not a defect but correct behaviour. What was wrong was the decision to put that model on that surface with that data.
Where AI Settled in E-commerce by 2026
Why the pilot era closed
Through 2023-2024, AI projects ran on separate budget lines with separate teams and success criteria. "We tried it and got interesting results" closed a quarter. It no longer does. The trend we see in the field: the AI budget now sits inside the budget of the function it serves — recommendations under marketing, triage under support, forecasting under purchasing. That shift alone imposes discipline, because each line answers to its own metric.
The second shift: the model layer has become a commodity. The difference between three providers doing the same job produces no measurable difference in outcome for most e-commerce use cases. What makes the difference is the quality of the data going in and which workflow the output is wired into.
Telling hype from what actually pays
Three questions are enough to judge whether an AI use case creates value. Is a person doing this job today, and for how many hours? What does it cost when the output is wrong? Can I measure the result within 30 days? A use case you cannot answer all three for is probably a demo.
What survives this filter tends to be dull work: product description drafts, return request classification, stock alerts, category tagging. What fails tends to be the flashy kind: the general-purpose chat assistant, the avatar that talks to visitors.
Use case, data, impact and difficulty
The table below collects the ranges we see in the field across mid-sized e-commerce operations in Turkey. The figures in the impact column are not guarantees but observed bands.
| Use case | Data required | Minimum volume | Realistic impact | Implementation difficulty |
|---|---|---|---|---|
| On-site search ranking | Search logs, clicks, add-to-cart events | 20,000+ searches per month | 8-18% lift in search-driven conversion | Medium |
| Product description drafts | Product attributes, existing copy | Structured attribute fields | 25-40 min saved per text | Low |
| Support triage and classification | Past tickets, resolution labels | 6,000+ labelled tickets | 30-50% drop in first response time | Medium |
| Demand forecasting and stock alerts | SKU-level sales history, return rate | 18+ months, 30+ sales per SKU | 15-25% fewer stockouts | High |
| Individual-level recommendations | User-product interaction matrix | 2,000+ SKUs, 100,000+ sessions/month | 4-9% lift in AOV | High |
The last row sums up why the case at the top of this article never worked. At 312 SKUs and 30,000 sessions a month, the interaction matrix a recommendation engine needs stays too sparse.
Personalization: Segment-Level or Individual-Level
How the two approaches differ
Personalization is not one thing. In practice two distinct technical approaches are squeezed under the same word, and that confusion explains most budget mistakes.
- Segment-level personalization: you assign the visitor to a predefined group — "first-time visitor", "purchased in the last 30 days", "abandoned a cart over 1,500 TL", "mobile, Istanbul, evening hours". Each group sees a hand-built experience. The number of rules is limited, auditable and explainable.
- Individual-level personalization: the model produces a separate prediction for every user. There are no rules, only a score. It scales, but it is hard to audit and harder still to explain.
- Data threshold: the minimum interaction density the individual-level approach needs before it produces meaningful output. It is set jointly by catalogue breadth and session count; if either is low, the other does not compensate.
- Cold start: the situation where there is no signal at all about a new product or a new user. It is the best-known weak point of recommender systems and it recurs constantly when the catalogue is small.
Where it applies: homepage, category, search
The three surfaces personalization is applied to do not produce equal value. The ordering we see in the field: the highest return sits in on-site search result ranking, second in category page ordering, and the lowest in the homepage band. The reason is simple: a user who searched has already typed their intent, and fixing the ranking meets it. A homepage visitor's intent is still undefined, so the model has to guess.
Most projects nonetheless start with the homepage, because that is where it shows. When you measure the effect of on-site search on your conversion rate, you usually find a bigger lever than any homepage band rearrangement offers.
What to do with a small catalogue
In a 300-500 product catalogue, individual-level personalization does not pay back — but you need not abandon personalization altogether. What works at this scale is a small set of hand-built segment rules: entry-level products for new visitors, a size guide pushed forward in high-return categories, a cart reminder for the second visit. Four or five rules do more work than a model, and nobody pays a monthly licence.
| Dimension | Segment-level | Individual-level |
|---|---|---|
| Minimum catalogue | 50 SKUs is enough | 2,000+ SKUs |
| Minimum traffic | 5,000 sessions per month | 100,000+ sessions per month |
| Setup time | 1-2 weeks | 8-16 weeks |
| Monthly cost band | 0-8,000 TL | 25,000-90,000 TL |
| Auditability | High, the rule list is readable | Low, output is a score |
| KVKK disclosure burden | Limited | Significant, may count as profiling |
Automation: Where Human Approval Must Stay
Post-order flows and stock alerts
The least contested area of automation is post-order. Reading a carrier status code and informing the customer, messaging proactively on a delivery delay, asking for a review three days after delivery — none need a human decision. Nor do stock alerts: notifying the purchasing lead when a SKU's days-of-cover drops below threshold can be fully automatic. The AI contribution is not sending the alert but calculating the threshold dynamically against sales velocity.
Price monitoring and support triage
Price monitoring is different. Collecting and reporting competitor prices is automatic; changing your price is not. The most frequent failure in operations that automate price changes is a competitor's mistyped price cascading into your own. The rule: the system prepares the proposal, applies it inside a defined band, and asks a human outside it.
In support triage the line is clearer. Classifying a request, scoring urgency, routing it and drafting a reply can all be automated. Return approvals, refunds and exception decisions stay behind human approval — they are expensive to reverse and shape the customer relationship directly.
Three levels of automation
| Level | What the system does | Suitable work | Main risk |
|---|---|---|---|
| Advisory | Prepares and presents, changes nothing | Price change proposals, campaign designs, stock order drafts | Nobody reads the proposals, the system goes idle |
| Approved execution | Executes, but waits for human approval | Return approvals, personal discounts, bulk price updates | Approval becomes a bottleneck, the team starts rubber-stamping |
| Autonomous | Acts on its own and reports afterwards | Carrier notifications, stock alerts, ticket tagging, search ranking | Errors scale quietly and are noticed late |
The level is chosen by how reversible the work is. A wrongly sent shipping notification email can be corrected; 400 wrongly approved returns cannot.
Agentic Commerce: Permission Matrix and Audit Trail
What an agent does and does not do
Agentic commerce describes AI moving beyond suggestions to initiating transactions across systems: opening a supplier order against stock levels, filing a return into the carrier system, updating a campaign budget on an ad platform. We covered the boundaries of the concept in the piece explaining what agentic commerce is. The issue here is not technical capability but how permission gets defined.
In practice, agent deployments almost never fail on model quality. The cause is one of two things: no permission boundary in the systems the agent can reach, or no trace of what it did. Both are operational problems.
How to build a permission matrix
A permission matrix has three columns: which system, which operation, which upper limit. For example: "ERP, create purchase order, up to 15,000 TL per transaction, approved suppliers only." Past the limit the agent stops and asks for approval. Keep the matrix in writing as a table, and record who changes it.
- Audit trail: a record, for every agent operation, of which inputs it looked at, which decision it made and which API call it issued. It has to be readable retrospectively when something goes wrong.
- Rollback path: the ability to cancel every operation the agent performs in a single step. Operations that cannot be reversed are not handed to an agent.
- Blind spot test: deliberately feeding the agent incomplete or contradictory data and observing what it does. To be run before production.
At Tecof, agent deployments can be set up with defined permission boundaries and operation logging; on the AI agents side, which systems get connected under which limits is settled up front. Connecting agents to ERP, carrier and marketplace systems depends directly on the soundness of your API integrations; where the integration is weak, the agent layer amplifies that weakness rather than hiding it.
The Turkish Context: Marketplaces, KVKK, IYS, ERP
Marketplaces and your own site are not the same game
If you sell on Trendyol or Hepsiburada, personalization is not in your hands. The platform's algorithm sets the ranking; you control product data quality, imagery, price, delivery time and seller rating. Your AI investment there belongs in data quality and price/stock synchronisation. On your own site the reverse holds: ranking and experience are yours, but you bring the traffic.
The practical consequence: the two channels cannot share one AI strategy. On a marketplace what wins is the right keyword in the product title and accurate stock; on your own site it is search ranking and the checkout flow.
KVKK, profiling and automated decisions
Personalization means processing personal data. Segment-level rules can usually be assessed under legitimate interest; individual-level scoring, where it counts as profiling, enlarges your disclosure obligation. Your privacy notice must state which data is processed for which purpose, the retention period, and any transfer abroad. If your model provider sits outside Turkey, that last item is not a detail to skip.
Automated decision mechanisms are a separate heading. Where a decision produces an effect on a person — a personalised price or discount, an automatic refusal of instalment options, an automatic rejection of a return request — a path must stay open for that person to object and request human intervention. In practice this means the "connect me to an agent" option stays visible throughout return and cancellation flows.
IYS consent and automated messaging
However clever the automation, the precondition for a commercial electronic message is an IYS record. Cart reminders, back-in-stock notices and personalised coupons all count, and consent must be checked at the moment of sending. The most common mistake is the automation platform's own list drifting apart from the IYS record over time. A send-time consent check costs far less than the penalties that follow.
ERP integration and data quality
The data in Logo, Mikro or Netsis is the real fuel for the AI layer. Forecasting reads sales history; stock alerts read the current balance; price proposals read cost. Break one read and the output breaks with it. The three problems we hit most often: the same product under two stock codes, inconsistent unit conversions (case versus unit), and returns not deducted from sales. All three are data entry problems, and all three come before the AI project.
Measurement: How to Judge an AI Investment
Four metrics and realistic bands
Defending an AI investment with soft words like "satisfaction" or "efficiency" is the fastest way to lose the second year's budget. Four metrics are enough.
| Metric | For which use case | Measurement window | Difference that counts |
|---|---|---|---|
| Conversion rate | Search ranking, personalization | 4-6 weeks | 5% relative and above |
| Average order value | Recommendations, cross-sell | 6-8 weeks | 4% relative and above |
| Cart abandonment rate | Cart flow automation | 3-4 weeks | 2 points absolute and above |
| Support resolution time | Triage, draft replies | 2-3 weeks | 20% or more drop in the median |
Average order value also needs tracking by channel and campaign; without a separate framework for how AOV is calculated and raised, you cannot isolate the recommendation engine's contribution.
The attribution problem and holdout groups
The real difficulty in measuring AI impact is attribution. If a campaign launched the same week you turned the engine on, or the season turned, or the ad budget rose, you cannot isolate the source of the conversion difference. The answer is not a before-and-after comparison but a concurrent holdout group: a fixed share of traffic (usually 10-20 percent) never sees the system, the rest does, and the two are compared within the same week. This is the basic logic of A/B testing applied to AI use cases.
Three things matter when building the holdout: assignment should be user-based and sticky, sample size calculated against the expected effect size, and the test should run at least one full purchase cycle. Reading a 0.05 point conversion difference in a three-week test repeats the case at the top of this article.
What Not To Do
Buying a recommendation engine with no data foundation
This is the most expensive mistake. A recommendation engine does not work without the interaction data it sits on, and the vendor will not say so in the sales call because they do not know your volume. Check your own numbers first: SKUs, monthly sessions, average product views per user. Below the threshold, the same budget spent fixing on-site search returns more.
Dumping everything onto a chatbot
The second common mistake is handing the support load to a general-purpose chat assistant and calling it solved. In practice the assistant handles 60 percent of the easy questions, escalates all the hard ones, and loses context on the way, so the customer starts over. Net effect is often below zero. What works is not the assistant talking to the customer but preparing a draft reply and history summary for the agent. Same model, different placement, entirely different outcome.
Opening five use cases at once
The third mistake is parallelism. A team that launches recommendations, a chatbot, demand forecasting and automated pricing in the same quarter can measure none of them, and all four end up half-finished. Queueing is tiresome, but it is the precondition for measurability.
Launching Your First AI Use Case in 30 Days
Days 1-7: Data inventory
Write down what you actually have. Catalogue SKU count, monthly sessions over the last 12 months, on-site search volume and the share of zero-result queries, ticket count and the labelled share, months of sales history in the ERP. The same week, run three data quality checks: duplicate stock codes, returns deducted from sales, products with empty attribute fields. Keep it to one page, but the numbers must come from queries, not estimates.
Days 8-14: Choosing one use case
Look at the first week's numbers and choose one area: where you clear the data threshold, can measure impact within 30 days, and the cost of an error is low. In most mid-sized operations that is on-site search ranking or support triage. Write the success threshold now, as one sentence: "8 percent relative lift in search-driven conversion". Writing it afterwards means fitting the threshold to the result.
Days 15-21: Building the measurement setup
Set up measurement before switching anything on. Define the holdout, make assignment user-based and sticky, record the core metric's current value and its weekly fluctuation range. The same week, write a rollback plan: if the system misbehaves, who shuts it down, with which switch, in how many minutes. If that plan is not in writing, the system does not go to production.
Days 22-30: Switch on, read, roll out
Open the system to 50 percent of traffic and keep the holdout at 10-20 percent. Read daily for three days, weekly after. By day thirty one of three outcomes appears: the threshold was cleared, it was not, or the data is still insufficient. If cleared, move to the second use case with the same setup. If not, shut it down and write why — a closed pilot is far cheaper than a drifting one.
Here is the job for tomorrow morning: open your analytics panel, pull the on-site search report for the last 90 days, and put the 50 most searched queries and how many returned nothing into one table. If zero-result queries run above 10 percent, that table shows you your first AI investment belongs in search ranking rather than a recommendation engine — and it costs you no licence fee at all.
Frequently Asked Questions
Is an AI investment premature for a small e-commerce site?
Not premature, but the order matters. An individual-level recommendation engine is premature for a 300-product catalogue; product description drafts, support reply drafts and category tagging create value at that same scale today. The rule: use cases that demand data volume depend on scale, text generation and classification do not.
Which numbers should we check before buying a recommendation engine?
Three are enough: active SKU count, monthly sessions, and average product views per session. The rough threshold we see in the field is around 2,000 SKUs and 100,000 sessions a month. Below that, the same budget spent on on-site search and category ranking returns more.
Does personalization create KVKK risk?
Segment-level rules generally stay within a manageable frame. Individual-level scoring can count as profiling and so enlarges the disclosure obligation; for decisions with consequences, such as personalised pricing or automatic refusal, a path to objection and human intervention must stay open. If your model provider is abroad, do not skip adding the transfer disclosure to your privacy notice.
We sell on marketplaces — where should AI go?
On a marketplace you do not set the ranking, so personalization investment does not pay off. The areas that contribute are product data quality (title, attribute fields, imagery), the accuracy of price and stock synchronisation, and the classification of return and message requests. Trying to run the same strategy as on your own site is wasted budget.
Should we deploy a chatbot?
A general-purpose assistant talking directly to customers produces no net benefit in most operations. Using the same technology on the agent side — classifying the incoming request, summarising history, drafting a reply — produces measurable gains. Try the second setup first and decide on a customer-facing assistant afterwards.
Which parts of automation can run fully autonomously?
Reversible, low-cost work: carrier status notifications, stock alerts, ticket tagging, search result ranking. Keep the expensive-to-reverse work behind human approval: return and refund approvals, personal discounts, out-of-band price changes, supplier orders. The line is drawn by the cost of an error, not by the technology.
Is ERP integration mandatory for agentic commerce?
If you want the agent to act on stock, cost or orders, yes. The data in Logo, Mikro or Netsis is the reality the agent sees; if the integration is incomplete or lagging, the agent decides on stale data. Adding an agent layer without fixing the integration means reproducing bad data faster.
How do we prove the return on an AI investment?
Not with a before-and-after comparison but with a concurrent holdout group. Ten to twenty percent of traffic never sees the system, the rest does, and the two are compared over the same period. Group assignment must be user-based and sticky, and the test must cover at least one purchase cycle. A system switched on without that setup has an effect that can be narrated but not measured.
How many use cases should we start with?
One. Teams that open four in the same quarter cannot separate the effects and usually leave all four half-finished. Moving to the second only after reading the first one's 30-day result looks like it stretches the overall timeline, but it is the only path that produces a measurable outcome.
How much does the choice of model provider affect the result?
Less than you expect, for most e-commerce use cases. The difference between providers doing the same job is small next to the difference made by data quality and by how the output is wired into the workflow. Spending on data cleanup the three weeks you would spend choosing a provider gives a better result almost every time.