Why the 1C-Bitrix recommendation system does not deliver returns
The recommendation module for the online store has been installed, blocks on the product page have appeared, but returns are not growing: all visitors see the same set of products — both the first-time visitor and the one who has been buying here for three years.
The reason is usually not in the engine, but in the fact that the 1C-Bitrix recommendation system receives too narrow a signal: the current product page and general sales statistics, without session history, cart, and orders.
The second failure is that data lies in different places. The module does not take into account the customer's history: repeat orders, abandoned carts, views from the personal account remain in separate tables and do not get into the recalculation.
Personal recommendations in the catalog ultimately are built on popularity for a period — an averaged metric that does not distinguish a regular customer from a random guest.
Hence — template selections and irrelevant product blocks.
The selection of related products often relies on manual linking by identifiers: when the assortment or supplier changes, the links become outdated, and the customer sees in the block items that are out of stock or belong to another category.
Such blocks do not sell, but reduce trust in the catalog, and behavioral signals worsen because of this.
A separate issue is load. If the set is calculated on every page view without caching ready-made selections, queries to history and aggregates go in dozens per one transition.
With several blocks on the product page and in the catalog, response time sags precisely during peak hours, when recommendations are needed most.
Below we analyze how this is addressed: from the signal collection scheme and scheduled recalculation to serving ready-made sets from the cache.
What changes in metrics after module implementation
The effect of recommendations is visible not in general words, but in four metrics: the share of orders assembled from selections, catalog view depth, share of repeat purchases, and the amount of manual work by managers.
In 1C-Bitrix this is calculated automatically — the module marks the session of the selection source and writes the label into the order item, so the storefront, product page, and email make different contributions instead of merging into one report.
Attribution changes the picture.
Previously "the customer found it themselves" and "the customer was prompted" looked the same; after implementation, it is visible what share of the cart was assembled by the "customers also buy" block on the product page, and what share — by a selection in the cart or in an email after an abandoned order.
If a block does not bring additions over a measurable period, its weight is recalculated or it is removed.
View depth grows due to links between products: each product page becomes an entry point to the next, not a dead end, so the visitor goes through more pages in the catalog per session instead of returning to the search results.
This also raises the conversion of the product page itself — related items and analogues appear on it, and part of the bounces turns into add-to-cart.
A separate shift is repeat orders: reminders about consumables and kit selections return the customer to the catalog before they remember about the purchase themselves.
At the same time, managers no longer have to manually assemble kits and select analogues — the selection is inserted into the order and commercial proposal, and the person confirms a ready-made solution instead of assembling it manually.
Methods of product selection in the catalog: comparison
The method of building recommendations determines how quickly the block reacts to changes in demand and how much manual work remains for the team. Below are four schemes that are actually chosen between, and the boundaries of applicability for each.
| Option | When it fits | Limitations |
|---|---|---|
| Rules and manual selections | Up to several hundred items, pronounced seasonal bundles, a predictable block is needed | Does not scale: links are set manually, new items do not get into the output |
| Learning on customer behavior | Thousands of items and a steady stream of views, carts, and orders | Requires accumulated data and regular retraining; there is nothing to show new customers and "cold" products |
| External recommendation service | Quick start without in-house analytics, several channels — website, app, emails | Dependence on an external environment, transfer of behavior outside, limited control over ranking |
| Hybrid selection scheme | Large catalog: some categories live on rules, some — on the model | More expensive to maintain: a layer is needed that decides which source serves the block in a specific place |
The choice almost never comes down to "either-or": rules cover the upper levels of the catalog, where manageability is important, and the trained model — the depth of output and personal blocks.
A hybrid selection scheme provides predictability where there is still little data, and adaptability where traffic has already accumulated.
Stages of developing the selection module: from scheme to launch
Each stage ends with an artifact that can be checked: a scheme, a report, or a working block in production. We do not start writing code until we understand on what data the selection will generally produce a result — otherwise the module will show random product pages.
- Store data audit. We look at order history, catalog structure, product properties, duplicates, and unfilled characteristics. The output is a list of bundles already confirmed by purchases and a list of gaps that need to be closed in the catalog.
- Selection scheme. We fix the signals: co-purchases, views, similar properties, behavior of a specific customer. For each, we set weight and exclusion rules — for example, do not show what is already in the cart or out of stock.
- Collection of behavioral events. We mark up the product page, cart, search, and filters so that events go to the storage without loss during peak load. We maintain anonymous sessions separately — otherwise a new visitor will remain without recommendations until registration.
- Rules and model training. We set up scheduled recalculation and cold start: a new item gets links by properties and category until it has accumulated statistics. Rules are edited without a module release.
- Selection quality check. We enable selection on part of the traffic and compare with the usual output by click and add-to-cart. We look not only at the top positions, but also at the whole block — otherwise growth in the first row hides a failure in the rest.
- Handover of the module to the customer. We provide the configuration, data scheme, retraining and monitoring regulations, and conduct team training. After that, the block lives on your side: edits to rules and thresholds do not require us.
The order of stages is strict: a skipped data audit nullifies work on the model — the scheme is built on links that may not exist in the catalog.
Delivery composition: code, schemes, documentation, regulations
We deliver the module as source code in your repository, not as a closed archive: it is installed by the standard update mechanism and deployed in your environment.
Along with it goes the configuration under which selections on the test environment reproduce the same as on production. Below is the full delivery composition and what task each artifact addresses.
- Module code and build. Sources with change history, build file, dependency list — updating to a compatible core branch does not require changing the selection logic.
- Settings and data scheme. Which tables and indexes are involved, which events reset the cache after catalog export or price changes.
- Service interaction scheme. Flows between the website, app, job queue, selection service, and storage — with failure points and timeouts at transitions.
- Selection formation rules. Priority of sources: purchases, views, product properties, manual links — with weights, thresholds, and output examples for verification.
- Instructions for the content manager. How to enable a block on a page, set exclusions, and pin a product manually — without code edits and without calling a developer.
- Maintenance regulations. What we monitor, which deviations we consider normal, when we rebuild indexes, and how we roll back to the previous module version.
- Module documentation. Extension points for new data sources and the update procedure when moving to a new core branch.
Each item is a working artifact, not a presentation: using it, a third-party engineer can maintain the system without contacting us for explanations.
Implementation practice: selections in the store catalog
How the output looked before the work
The catalog on 1C-Bitrix showed "Similar products" by a formal attribute — common section and brand.
With an assortment of about 12,000 items and dozens of subcategories, this gave random bundles: next to a pump there was fittings of a different diameter, and consumables for it were not shown at all.
Managers manually assembled around 120 selections via properties and discount rules, and after a supplier change, half the links led nowhere. The share of orders where the customer took a product from such a selection held at 3-4%, view depth — 4.1 pages per session.
What was changed and what it gave
We calculate the link matrix from depersonalized order history: co-purchases, transitions between product pages within one session, repeat visits to an SKU.
Recalculation runs at night on a schedule, the result goes into a separate table and is cached by sections — the catalog page does not trigger heavy queries and is served at the previous speed.
We back up new items without statistics with attributes, and personalization is by segments, not by each visitor, so the cache stays hot.
After two months, the share of orders with selected products grew from 3-4% to 27%, view depth — to 6.3 pages, repeat purchases in the catalog added 18%. Manual selections are gone: eight seasonal ones remain, updated according to the supply calendar.
The customer put it this way: "We stopped keeping a person on relinking links, and the recommendation block for the first time started bringing orders instead of taking up space."
How a recommendation system differs from ready-made blocks
A ready-made "Customers also buy" block is a static selection: links between items are set manually or assembled by one formal attribute, most often by common category. Such a block is the same for all visitors and does not change until it is rewritten.
With a catalog of several thousand items, maintaining such selections manually becomes a separate job, and usually they quickly become outdated.
The recommendation system calculates links by data, not by markup. The calculation includes the viewing and order history of a specific customer, co-purchases, behavior of similar segments, stock availability, and delivery time.
Personalization of output means that two visitors on the same page see different selections — according to their interest and stage of choice.
The difference is also noticeable when the catalog changes. A new item has appeared — a template selection will not show it until it is added manually; recommendations pick up the new item as soon as enough signals accumulate. A product went out of stock — it disappears from the output without content edits.
Separately — resilience to catalog restructuring. Manual links break when categories merge, assortment changes, and moving to a new section structure: some selections start leading to nowhere or to discontinued items.
A model that is recalculated on a schedule survives such changes and continues to serve relevant output.
We build a recommendation system on 1C-Bitrix as a separate module: event collection, calculation, storage of the result, and serving to website templates.
At the same time, we do not throw away ready-made blocks — they remain a fallback option for new visitors about whom there is no data yet.
Frequent technical questions about the selection module
We hand over the selection module for operation along with answers to questions that arise in almost every project.
We address them before the start: at the design stage, it is already clear where there will not be enough data for training, where the load on the catalog will grow, and how the solution will behave when the platform is updated.
What to do if there is not enough data for training?
At the start, there are not enough orders, and the model goes into cold start. For this time, we enable rules: similar by attributes and sections, manual selections for key items, popular in the category. Later, the weight shifts to customer behavior, and the share of manual substitutions decreases.
How do recommendations affect the load on the catalog?
Recalculation runs in batches on a schedule, and the storefront serves ready-made selections from the cache — calculation is not launched on every view. We move heavy selections outside peak load hours, so the response time of the product page and listing remains the same.
What happens when the platform is updated?
The module works on standard core mechanisms, without edits to the core itself, so updates are transferred in the standard way. Before rollout, we check compatibility on the test environment and keep a rollback point.
What is included in support after launch?
We monitor the quality of output and the share of empty blocks, update rules for assortment changes and seasonality, and handle errors. We make configuration edits upon request with testing on the test environment.
Let's discuss the task and come back with an estimate and work plan
To give the timeline for developing the recommendation module and estimate the scope, we do not need full access to the production environment — a slice of the system is enough: how the catalog is organized, what links between products already exist, and what customer behavior data is accumulated. Below is what is needed from the customer to start.
- access: a test copy of the website, admin panel, read-only export of nomenclature from 1C;
- catalog structure: sections, properties, trade offers — links between products are built from them;
- behavior data: views, carts, orders for the past period — output weights are configured on them;
- business rules: manual selections, manufacturer priorities, products that must not be recommended;
- a responsible person on your side who confirms the output logic and accepts the stages;
- access to the analytics system, if it is separate — to compare metrics before and after.
The interaction procedure is as follows: we study the catalog and data, show the module scheme and ranking logic, agree on the output — and only after that we fix the module development timeline by stages.
Usually this is several iterations: the composition of recommendations is refined on real data, not on words.
Describe the task and send what is already available according to the list — we will come back with an estimate and a work plan broken down by stages. If there is no test copy, we will propose a safe way to take data without affecting the production website.