Why AI upsell recommendations do not increase average order value
The AI upsell recommendation block is present both on the product page and in the cart, but average order value does not move. The reason is that the selection ranks candidates by general popularity and shows the buyer the same thing they have already found themselves.
Low average order value here is not a demand problem, but a consequence of the hint carrying no new information and not adding a single item to the order.
The second loss is an empty recommendation block. As soon as a product runs out of stock or the product page falls into a narrow category, the algorithm lacks candidates, and the module either disappears from the storefront or returns a random item.
These are direct storefront losses: the buyer sees that nothing was offered to them and goes to those who assemble a complete set.
Irrelevant recommendations cost the most. If the model does not see order history, price segment and item compatibility, it suggests an accessory to something already purchased or a duplicate in different packaging.
The buyer compares a couple of options, finds no bundle and leaves to complete the order elsewhere — along with their cart.
Growth appears when selection is built on data: real-time stock, current and previous cart, compatibility rules and feedback based on actual purchases. Then the block suggests what the customer has not yet considered but is ready to take. We break down how this is addressed at the level of the model, data and storefront.
Effect of implementation: growth in average order value and repeat purchases
Before implementation, upsell relied on the manager's memory: some orders went out with a single item because a suitable product simply was not offered. Metrics were not collected at the same time — there was no way to estimate how much was missed.
We start with measuring the baseline: over a comparable period we record the share of orders with an additional item, average order value, share of repeat purchases and catalog conversion.
Then we calculate every change on comparable customer groups — control and test.
Recommendations receive identifiers that show which block led to adding a product to the cart, and model versions and their metrics are maintained in MLflow: it is clear which version produced the shift, which needs retraining and which to roll back to.
The practical result usually looks like this. The share of orders with an additional item grows from 10-15% to 25-30%, average order value — by 15-20% without increasing discounts.
Repeat purchases grow due to personal selections and consumable reminders, catalog conversion — due to the fact that rare items stop being invisible to the buyer.
We also relieve the load on people separately: the share of manual selections falls severalfold, managers return to large deals where a conversation is needed.
We bring effect metrics into one panel, where next to revenue you can see how many selections were assembled automatically and what part of them were accepted into an order.
Upsell scenario options: rules, model, hybrid
The first weeks after launching an AI upsell recommendation system determine what to show: hard rules, a trainable model or their combination. The choice depends on catalog breadth, the volume of order history and how often the assortment changes. Below are three modes to choose between at the start.
| Option | When it fits | Limitations |
|---|---|---|
| Selection rules | narrow catalog, clear product compatibility | does not scale: every exception is added manually |
| Trainable model | order history accumulated and there is something to rank with | cold start and rare items — nothing to train on |
| Hybrid approach | rules define allowed pairs, model defines order | more expensive to maintain: labeling and control required |
Selection rules do not depend on accumulated data and work from day one: explicit "bought — suggest" associations provide predictable output.
The weak point is manual support: a new item, seasonal replacement or exception requires editing the list, and on a broad catalog the scheme diverges from reality.
A trainable model on top of order history, for example on CatBoost, captures what rules cannot describe: for an expensive item it is more profitable to suggest a related product than a second cheap one.
The limitations are the same as for any recommendation model: cold start and the first weeks of operation, when there is still nothing to train on.
Therefore we most often build a hybrid: rules cut off incompatible and unavailable pairs, the model ranks what remains by purchase probability, and its share in impressions grows as orders accumulate.
The price is regular output review and rule updates, otherwise the catalog and recommendations diverge.
Implementation stages: from data audit to solution handover
We work in iterations: each stage is closed with a verifiable artifact — a data report, pipeline diagram, rule configuration. This makes it possible at any moment to see what a recommendation is built on and where the boundary between the pipeline and the storefront lies.
- Data audit. We analyze events: views, add-to-cart, orders, cancellations, search queries. We check history depth, share of missing values and quality of category labeling — without this personalization degenerates into random output.
- Pipeline design. We decide where the recommendation is calculated: online at request time or precomputed by segments, which signals feed into it, where the result is delivered — product page, cart, emails. We separately define behavior when the service is unavailable so that the storefront does not lose output.
- Selection setup. We assemble basic rules: related products, upgrade to a higher line, ready-made sets. We apply restrictions on stock, margin and diversity — the system should not suggest what is not available.
- Quality check. First offline: on historical orders we see whether the purchase made it into the top of the output. Then live traffic — share of clicks and add-to-cart, change in average order value, share of empty outputs versus the control group.
- Solution handover. We provide pipeline documentation, rule configuration, accesses and a metrics dashboard. We train the customer's team to change weights, add associations and read reports without us.
- Support. We monitor assortment shifts, seasonality and a drop in the share of non-empty outputs — based on these signals, rules and the model are rebuilt according to the policy.
What remains with you after project handover
The project ends not with a demonstration of working output, but with a set of artifacts your team can use to further develop the system on its own.
Everything we change in the production pipeline is stored in a code repository with change history — rolling back to a previous version takes minutes.
- Data and flow diagram. Event sources (views, cart, orders), their fields, update frequency and deduplication rules — you can see where each feature for ranking comes from.
- Model and rule configurations. Confidence thresholds, category weights, exclusion lists are kept in separate files next to the code, with notes on what changes without retraining and what requires a run.
- Accesses and roles. Separation of read, write and release launch permissions, service accounts, key issuance through a secrets vault, audit log of access to sensitive data.
- Update policy. Data window for retraining, launch frequency, metrics used to determine degradation, and conditions for automatic rollback to the previous version.
- Instructions for the team. Step-by-step scenarios: bring up the environment, rebuild features, release a new version, roll it back, investigate an incident using logs.
- Documentation and decision log. Architectural notes, rationale for the chosen approach, tested and rejected hypotheses, open questions.
The system can be handed over to your team or another contractor — without verbal agreements and settings that live only in the developer's head.
Case: average order value growth in a retail chain without traffic growth
A grocery retail chain: 180 offline locations and an online store, traffic was not growing.
Cart recommendations worked by the "popular in category" rule — an additional item appeared in only every ninth order, and ranking rules were edited manually three times a year, based on category managers' gut feeling.
Metrics before and after
We compared not with the previous month, but with a control group of 10% of traffic — this way the effect was separated from seasonality and promotions. Receipts and behavior were collected from POS logs and the web storefront in Google BigQuery.
| Metric | Before | After 4 months |
|---|---|---|
| Orders with an additional item | 11% | 34% |
| Average order value | baseline | +21% |
| Share of repeat purchases over 90 days | 24% | 31% |
| Manual ranking edits | 80% of output | 9% |
Implementation timeline: what was changed
The first three weeks — export of purchase and stock history, another three — model training on co-purchases and seasonal slices. The pilot at 12 locations took a month: we monitored the share of orders with upsell, output completeness and response time during peak hours.
It was rolled out to the entire chain in two months — the metrics held, and rolling back to the previous ranker is one rule in the settings, without rebuilding the storefront.
What to do if the catalog and prices change every week?
The recommendation system does not store selections as a ready-made list — it assembles them on the fly from product features and customer behavior.
Therefore a price change, a new arrival or an item going to zero does not require rebuilding the entire model: only the freshness layer is updated. Frequent catalog updates are a standard mode for such a scheme, not an emergency.
New items enter the output through features: category, attributes, price segment, compatibility with what is already in the cart.
While a product has no purchase history, it receives a limited share of impressions next to similar items — this is enough to collect statistics and then compete with the old assortment on equal terms.
Stock availability is maintained by a separate filter: a recommendation is not shown if the stock is zero or the product is discontinued.
The filter works at the output stage, not during training, so returning an item to stock immediately returns it to selections — without retraining or manual edits.
The sustainability of the solution lies in versioning weights and rules: any edit can be rolled back, and changes are first tested on part of the traffic.
We monitor the share of recommendations without stock, the share of new items in impressions and upsell conversion — these metrics show where the catalog and model have diverged.
Rebuilding selections happens in parts, by affected categories, and a full recalculation is launched on schedule. Therefore even a sharp assortment update does not turn into a pause in the block's operation.
Common technical questions before starting a project
Before starting, almost every team goes through one list of doubts: whether there is enough data, how this will fit the current storefront, whether we will attribute ordinary seasonal growth to recommendations, and who is responsible for the system after launch.
Will our data be enough for training?
At the input, order and event history by customers, a product reference with categories and segment features are needed. If there is little history, we start on rules and gradually replace them with a model — the storefront receives recommendations from day one.
How does integration with the catalog work?
We connect to your catalog via an API or regular export; we do not migrate the storefront itself. Recommendations are delivered to the same block where the customer sees products — the checkout logic does not change.
How do you separate the effect from seasonality?
We compare the control and test groups within the same week: the seasonal spike lifts both equally and cancels itself out. The report shows average order value growth specifically from recommendations.
What about data security?
We work in your environment or in an isolated environment; personal data is anonymized before training. Accesses are granted by role, actions are recorded in a log.
How long until launch and what happens after?
The first version goes out in a limited segment within a few weeks, full launch — after metrics are verified. Then the system is under support: we monitor impression share, retrain on schedule, and investigate drops.
Let's discuss the task: where to start and what we need from you
A conversation about starting a project is more useful when it starts from data, not general wishes. Below is the minimum input data sufficient for us to come back with a timeline estimate and work plan, rather than clarifying questions a week later.
- Export of order and cart history: composition, amounts, time, anonymized customer identifier.
- Catalog with cross-sell features: category, price, compatibility, what is bought together.
- Current upsell scenario: where recommendations are shown, what rules are set manually and why.
- Target metric: average order value, share of orders with upsell or repeat purchases — what we consider the result.
- Constraints: which systems cannot be changed, load requirements, who accepts the result on your side.
- Accesses: test environment and access to the data mart to test hypotheses on real behavior.
Our first step is to analyze the export and check whether there is enough history to train recommendations on your assortment. Then we come back with a stage-by-stage work plan, timeline estimate and team composition for each stage.
If some data is missing, this is not a blocker: we will advise how to collect the required minimum with the least interference in current processes. Describe the task — we will come back with an estimate and plan.
