Why product recommendations in Bitrix do not work on order history
A typical picture: on a product page, the "customers also buy" block is either empty or shows something the customer already bought a month ago.
The reason is not in the markup, but in the fact that the recommendation module takes data from the view log and the cart, not from the purchase history in 1C.
Deals live in the accounting system, order statuses are closed there too — and until this loop is connected to the storefront, the algorithm physically does not know what the person has already purchased.
The second gap is inventory-related. Personalized recommendations of an online store are built on a co-purchase matrix, but without stock balances by warehouses and delivery regions.
As a result, the block offers related products that are not available at the nearest warehouse: the customer adds them to the cart, and at checkout gets a refusal or a delivery time of three weeks. The conversion of the block drops, even though the selection formally "worked."
The third failure is the repeat of an already purchased item.
Consumables, filters, cartridges, pet food are bought cyclically, and the recommendation must take this into account: somewhere to offer a repeat after a calculated interval, somewhere to exclude the item as already mastered.
Without labeling the product lifecycle, the algorithm drags everything into the block and annoys the regular customer.
The fourth reason is the lack of feedback. Clicks on the block, add-to-cart actions, and refusals do not return to the model, so the weights of the connections are not recalculated, and a month later the block shows the same set as on the launch day. We analyze how this is closed by the combination of 1C and the storefront.
What Changes After Implementing Selection Based on Purchase History
When recommendations are built on actual order history from 1С rather than on static manual blocks, what changes is not the "beauty of the storefront" but behavioral metrics: the share of orders with additional items, the average basket composition, and product page conversion. Below is exactly what shifts and why.
Cross-sells in the catalog stop being a lottery
Manual placement of "customers also buy" becomes outdated after every assortment rotation and does not account for demand seasonality.
Selection based on purchase history recalculates the relationships between products using real orders: related items, repeat purchases, substitute products.
As a result, the recommendation block shows what is actually bought together, and the share of orders with additional items grows without pressuring the customer.
The average order value of the online store grows due to basket composition
The effect comes not from pushing but from relevance: the customer is offered an item that logically complements what they have already chosen.
The average basket composition increases by 1–2 items among the portion of the audience that would otherwise have limited themselves to a single purchase.
Separately, the problem of "empty" blocks is eliminated — when recommendations are not generated and the space on the product page sits idle.
Product page conversion and bounce rates
An empty or irrelevant recommendation block works against the store: the visitor finds no continuation and leaves.
When selection relies on purchase history, the product page gets a meaningful continuation of the journey — deeper navigation through the catalog grows, and bounces from blocks with irrelevant products decrease. This also relieves the load on managers who manually edit the placement.
We work with 1C-Bitrix and Bitrix24 in conjunction with the accounting system, so recommendations are calculated on current order data, not on an export that became outdated a week ago.
Comparison of approaches: rules, co-purchases, order-based learning
The recommendation block in 1C-Bitrix is built on three fundamentally different mechanisms, and the choice between them is determined not by how "fashionable" an algorithm is, but by what order data you have already accumulated and how often your assortment changes.
Related product rules rely on the expertise of a category manager, co-purchases rely on the statistics of real receipts, and order-based learning relies on behavioral patterns that are difficult to describe manually.
| Option | When it fits | Limitations |
|---|---|---|
| Related product rules | Narrow assortment, clear pairings (accessories for equipment, consumables), starting without order history | Requires manual maintenance: as the catalog grows, the number of rules grows non-linearly, and priority conflicts have to be resolved manually |
| Co-purchases (collaborative filtering by receipts) | Several hundred orders accumulated, stable assortment, repeat purchases present | Cold start: a new product will not appear in results until someone buys it; sensitivity to one-off demand spikes |
| Order-based learning (model based on history) | Large catalog, long history, pronounced seasonality and different customer profiles | Requires regular retraining and data quality control: duplicate SKUs, returns, and test orders distort the weights |
How to choose for your catalog
In practice, approaches are combined: rules cover the cold start and strategic pairings, receipt statistics cover mass scenarios, and the model covers personalization for regular customers.
The recommendation algorithm is assembled so that when data is insufficient it automatically falls back to a simpler level rather than showing an empty block.
The key data requirement is a clean order history: the same item under different codes or unaccounted returns break the weights more than a lack of volume. That is why before implementation we check the export from 1C and bring the product reference to a unified form.
How we implement Bitrix product recommendations on 1C data
The work proceeds from the data, not from a ready-made module: first we look at what actually exists in 1C and in the catalog, then we build connections, and only then do we enable the output.
The order of the stages is the same — what changes is the volume of the export and the selection logic for a specific product matrix.
- Data audit. We check the order history in 1C: its depth, the share of items with a correct nomenclature code, duplicates, and substitute products. Separately, we verify that the trade offers in the catalog are linked to the same codes, otherwise the recommendations will point into emptiness.
- Connection scheme. We determine which attributes the selection is built on: joint purchases within a single order, category, brand, series, compatibility. We define which connections are calculated on the 1C side and which on the site side, so as not to push the full catalog through on every request.
- Order export. We set up regular transfer of depersonalized purchase history and stock balances to Bitrix: incrementally, by changed documents, with an error log. This way the recommendations rely on fresh data rather than on a snapshot from six months ago.
- Output setup. We assemble recommendation blocks for the places on the site — product page, cart, "thank you for your order" page. We set rule priorities, limits on the number of items, and filters: out of stock, hidden sections, made-to-order products.
- Testing on historical orders. We run the algorithm over past periods and see whether the selection would have hit a real purchase. We adjust the weights and cut off connections that produce random matches.
- Measurement and handover. We compare behavior before and after: the share of orders with an added product, cart depth, clicks from the block. We hand over access credentials, the data update schedule, and instructions for editing the rules.
Stages 2 and 3 run in parallel with the export setup — this way the 1C and Bitrix integration does not hold up the launch. After handover, the customer's team can change block priorities and add new output locations without rebuilding the algorithm.
What you keep after handover: configuration, diagrams, regulations
We hand over the project not as "access to a panel," but as a complete package that your team can run without us.
Everything related to recommendations — selection rules, product relationships, the 1C exchange schedule — is documented in the project documentation, rather than left in chats and people's heads.
- Recommendation selection rules. Which blocks appear on which pages, and the logic behind the output: co-purchases, related categories, repeat orders. With weights, thresholds, and an explicit description of what is shown when there is insufficient history.
- Product relationship map. A diagram of how the 1C nomenclature, trade offers, and on-site product cards are matched: which attributes form the link, where analogs and substitutes are stored, and what happens when a new product appears.
- Export settings. The data refresh regulation: what goes out of 1C and how often, which fields participate in selection, and how discontinued items and stock levels are handled.
- Instructions for the content team. How to tag a product so it enters or drops out of recommendations, how to set manual links on top of automatic ones, and which errors in a product card break selection.
- Data refresh regulation. Who checks that the exchange ran, and when, how to read the log, and what to do when the number of links diverges after an export.
- Settings handover procedure. Access credentials, roles, entry points to the admin area — with descriptions so a new engineer can figure things out without calling us.
- Change log. What changed in the selection rules and why, so that six months later it is clear why the output looks the way it does.
The package stays with you in the repository and in the knowledge base — update it as your catalog grows. If you need to extend the selection logic or connect a new data source, describe the task — we will come back with an estimate and a plan.
Case study: recommendations based on order history in a building materials catalog
The client is a building materials supplier with a catalog of several tens of thousands of SKUs.
The catalog ran on 1C-Bitrix, order records were kept in 1C, and there was no link between them: recommendations were rendered as static "customers also buy" blocks that led to random items.
A buyer who had added cement and rebar would see decorative tiles in those blocks — the blocks had no effect on the cart, and managers manually upsold related items over the phone.
What was changed
Order history from 1C was collected into a separate store, and recommendation rules were built on actual combinations of items in receipts rather than on manual links.
The logic accounts for category, unit of measure, and pack multiple: a bag of mix pulls in a primer, a profile pulls in the right quantity of fasteners, rather than "a similar product from the section." The output was served through a cache refreshed on order events — the blocks stopped slowing down the product page.
Before and after metrics
| Metric | Before | After |
|---|---|---|
| Share of orders with additional items | 18% | 34% |
| Duplicates in blocks on the product page | up to 40% | less than 5% |
| Recommendation response time | 1.8 s | 120 ms |
Empty blocks were addressed separately: if there is no statistics for an item, the recommendation falls back to category rules instead of showing a placeholder.
Two months after launch, the share of orders with additional items had nearly doubled, duplicates in the blocks were gone, and response speed no longer depended on catalog size. The project was led by our engineer, who worked with 1C-Bitrix and 1C integration.
How is selection based on purchase history different from similar products?
These are three different mechanisms, and they must not be confused — the choice determines what the customer sees on the product page.
"Similar products" are built on the properties of the product itself: category, brand, attributes, tags. This is a static relationship — it does not depend on who is viewing the page and is the same for everyone.
This block solves a navigation task: a person has landed on a product page and wants to see alternatives within the same group.
If the product is the only one in its category or the attributes are filled in carelessly, the block is either empty or shows a random set — so its quality depends entirely on how completely and consistently the catalog is maintained.
"Customers also buy" is already order statistics, but depersonalized. The mechanism collects pairs of products that appear in the same orders and shows the most frequent combinations.
What works here is not catalog logic but the behavior of all customers at once: the block suggests what is bought in addition to the selected item.
The limitation is that for rare products there is little statistics — a pair accumulates slowly, and the block remains empty for some time.
Personalized blocks based on purchase history are the third level. They look not at the product but at a specific customer: what they ordered before, how often, what they bought last time.
If the online store is connected to 1C, the history is taken from real orders, not just from the cart on the website — including offline purchases and purchases by invoice.
This enables selection that neither of the previous blocks can assemble: consumables for what has already been purchased, products with an expired replacement period, items from the same product line that the customer buys regularly.
In practice, these mechanisms do not replace but complement each other. On a product page, "similar" and "customers also buy" are appropriate — they help choose here and now.
A personalized block works better on the homepage, in the account area, and in emails: there it brings the customer back to what they actually buy.
We set up all three, but we display personalized selection only when there is sufficient order history — otherwise the block shows random items and undermines trust in recommendations.
Common Technical Concerns About Recommendations in Bitrix
Recommendations are built on order history, not on "magic" — so the first question is always about data quality.
If some orders in 1C are posted with a backdated date, some items are written off manually, and old deals sit without being linked to a counterparty, the algorithm will learn from noise.
We start with an audit: we reconcile the catalogs of nomenclature, trade offers, and properties, cut out duplicates and test orders, and bring statuses to a single dictionary. Only after that do the "customer → product" relationships become predictable.
The load on the catalog is the second most common fear. Recalculating recommendations on every page view really does bring down the catalog, so the relationships are calculated in advance, on a schedule, and stored in a separate table.
The storefront reads the finished result from the cache instead of running heavy queries across the entire order history.
What should be done if order data is incomplete or part of the history is lost?
We work with what is available: we reconstruct relationships from indirect signals — categories, brand, co-purchases within a single order.
If there is little history, recommendations initially rely on similar products and popularity within the category, and as orders accumulate they gradually shift to personalized ones. We check data completeness during the audit and record which fields are missing.
How do recommendations account for stock levels and avoid suggesting a product that is unavailable?
Stock accounting comes from 1C: items with zero stock or discontinued items are excluded from the output until the next synchronization. If a product runs out between updates, the display is backed up by an availability check at the moment of delivery. This way a recommendation does not lead the customer into a dead end with an unavailable product.
How often are the relationships updated and what happens if synchronization fails?
Recalculation runs on a schedule — usually once a day during low-load hours, and more often during active sales. If the exchange with 1C fails, the storefront continues to serve the last successful set rather than emptiness: a synchronization failure does not break the display. Exchange errors are logged, and we can see at which step the data was lost.
Let's discuss your task and come back with an estimate and a plan
To come back with a project estimate rather than generalities, we need context on your 1C-Bitrix setup and sales data.
Product recommendations are built on purchase history, so the accuracy of the estimate directly depends on how fully you convey the picture of your catalog and orders.
Send whatever you have on hand — we'll clarify the rest on a call:
- an export or description of the catalog structure: sections, properties, SKUs, stock by warehouse;
- how order history is currently maintained — in Bitrix, in 1C, or in both systems in parallel, and how often the exchange runs;
- what customer data is available: authorization, linking orders to a profile, processing consents;
- examples of products for which recommendations already work or, conversely, produce garbage;
- where recommendations should appear: product page, cart, emails, homepage;
- constraints on load and exchange mode, if any;
- the contact of the person who will confirm the business logic rules.
Based on these inputs, we assemble a work plan: an audit of the current exchange with 1C, a map of the relationships between orders and the catalog, the choice of approach to selecting similar products, configuration of block output, and testing on real traffic.
As a result, you receive an estimate by stage, an implementation sequence, and a list of risks — what could slow down the launch and how to close it in advance.
Describe the task in whatever form is convenient — we'll come back with an estimate and a work plan.