Рекомендательная система в каталоге 1С-Битрикс

Покупатель открыл карточку товара, посмотрел характеристики — и не купил, потому что именно эта модель не подошла по цене или размеру. Или купил, но только один товар, хотя к нему логично докупить чехол, кабель, крепёж, расходники. В обоих случаях магазин теряет деньги на уже пришедшем трафике. Ровно эту утечку и закрывает рекомендательная система: блоки «похожие товары» и «с этим покупают» удерживают выбор внутри каталога и увеличивают число позиций в заказе.

Ниже — практическое руководство, как собрать рекомендации в 1С-Битрикс без дорогих внешних сервисов: от простых правил по свойствам до поведенческих связей из истории заказов, с архитектурой, агентами и метриками. Это выжимка из наших проектов по разработке интернет-магазинов на 1С-Битрикс — с упором на то, что реально влияет на средний чек, а не на красивые, но пустые блоки.

Зачем магазину рекомендательная система

Рекомендательная система — это механизм, который для каждого товара и каждого посетителя подбирает другие релевантные товары каталога и показывает их в нужном месте: в карточке, в корзине, на странице раздела, в письме после заказа. Формально это выглядит как один-два блока с товарными карточками, но за ними стоит логика, которая напрямую влияет на два ключевых показателя магазина — конверсию и средний чек.

Ценность рекомендаций в том, что они монетизируют уже оплаченный трафик. Привлечь посетителя стоит денег: контекст, SEO, маркетплейсы, ретаргетинг. Когда человек уже на сайте, каждая дополнительная релевантная витрина повышает вероятность, что он найдёт нужное и купит больше, — и всё это без дополнительного рекламного бюджета. Именно поэтому рекомендательные блоки считаются одним из самых окупаемых инструментов e-commerce: они работают с самой «горячей» аудиторией.

Важно сразу разделить две задачи, которые часто путают. Первая — помочь выбрать, когда посетитель ещё не определился или конкретный товар ему не подошёл. Здесь работают рекомендации-заменители. Вторая — помочь докупить, когда выбор уже сделан и нужно предложить сопутствующее. Здесь работают рекомендации-дополнители. Если смешать эти задачи в одном блоке, он превратится в случайную выборку, которая не решает ни ту, ни другую цель.

В 1С-Битрикс рекомендательную систему можно построить полностью на штатных средствах: свойствах инфоблоков, истории заказов торгового каталога и агентах для фоновых пересчётов. Не нужно на старте покупать внешний сервис машинного обучения — он оправдан на больших объёмах, но чтобы получить первый прирост среднего чека, достаточно грамотно собрать данные, которые у магазина уже есть.

Два блока: «похожие» и «с этим покупают»

Фундамент рекомендательной системы магазина — два принципиально разных блока. Разберём каждый, потому что от понимания их различия зависит вся дальнейшая настройка.

«Похожие товары» — это заменители. Блок отвечает на вопрос «а что ещё в этой же категории, если конкретно эта позиция не подошла». Похожие подбираются по совпадению категории и близости свойств: тот же тип товара, соседний ценовой диапазон, тот же бренд или, наоборот, альтернативные бренды в той же цене. Такой блок снижает отказы: посетитель, которому не подошла модель, не уходит из магазина, а переключается на соседнюю. Работает в основном на конверсию карточки.

«С этим покупают» — это дополнители. Блок отвечает на вопрос «что докупают вместе с этим товаром». К смартфону — чехол, стекло, кабель; к дивану — чистящее средство и плед; к дрели — набор свёрл. Дополнители подбираются либо по правилам (аксессуары привязаны к категории или к конкретному товару), либо по поведению (реальные пары из истории заказов). Этот блок работает на средний чек и допродажу — это и есть кросс-селл.

Есть и третий, пограничный сценарий — апселл, предложение более дорогой или продвинутой версии того же товара («возьмите модель с большим объёмом памяти»). Его тоже удобно реализовать как отдельный тип рекомендации. Подробно логику допродажи мы разбираем в отдельном материале про апселл, кросс-селл и сопутствующие товары в 1С-Битрикс.

Типы рекомендаций и на чём они работают

За словами «похожие» и «с этим покупают» скрывается несколько технических способов подбора. У каждого своя область применения и свои требования к данным. Полезно держать в голове всю палитру, чтобы выбирать под свою ситуацию.

• Ручные связи. Товарищ по каталогу привязан к товару вручную через свойство-привязку. Максимальная точность, но не масштабируется: заполнять связи на десятки тысяч товаров нереально. Хорошо для витрин, флагманов и «наборов».
• Правила по свойствам. Рекомендации подбираются автоматически по совпадению категории, бренда, ценового диапазона и других характеристик. Работают сразу, без накопленной статистики. База любой рекомендательной системы.
• Правила по категориям (аксессуары). К категории «смартфоны» привязана категория «чехлы», и любой смартфон автоматически получает подборку чехлов. Экономный способ наполнить «с этим покупают» на старте.
• Поведенческие связи из заказов. Пары товаров, которые часто встречаются в одних чеках. Самый ценный сигнал для кросс-селла, но требует накопленной истории продаж.
• Совместные просмотры и корзины. «Смотрели вместе», «добавляли в корзину вместе» — данные веб-аналитики. Дают сигнал раньше, чем накопятся заказы, но шумнее.
• Персональные рекомендации. Подбор с учётом истории конкретного пользователя (что смотрел, что покупал). Ближе к машинному обучению и внешним сервисам, оправдан на больших объёмах.

На практике рабочая система почти всегда гибридная: скелет держат правила по свойствам и категориям, а поведенческие связи из заказов их усиливают там, где статистики уже достаточно. Такой подход даёт результат с первого дня и планомерно улучшается по мере роста магазина. Персонализацию витрины под конкретного посетителя мы рассматриваем отдельно — см. материал про персонализацию витрины в 1С-Битрикс.

Рекомендации на правилах: с чего начать

Правила — это детерминированная логика подбора, которая не зависит от накопленных данных. Она отвечает на вопрос «какие товары считать релевантными этому» через понятные условия по свойствам каталога. Именно с правил стоит начинать любую рекомендательную систему, потому что они дают предсказуемый результат в день запуска.

Для блока «похожие товары» базовый набор правил выглядит так:

• Та же категория (раздел инфоблока). Похожее ищем внутри той же товарной группы — смартфон к смартфону, а не к чехлу.
• Близкий ценовой диапазон. Отбираем товары в коридоре, например, ±30% от цены текущего. Замена в другой ценовой лиге редко уместна.
• Совпадение ключевых свойств. Бренд, тип, назначение, форм-фактор — то, что определяет «похожесть» в конкретной категории.
• Наличие и активность. Не рекомендуем то, чего нет в продаже или что скрыто. Отсутствие товара в рекомендации — это разочарование.

Для блока «с этим покупают» на правилах чаще используют привязку категорий-аксессуаров: к разделу основного товара сопоставляются разделы сопутствующего. Такой подход мы подробно разбираем в статье про сопутствующие товары и аксессуары в каталоге 1С-Битрикс — там показано, как связать категории и настроить автоподбор без ручной работы по каждому товару.

Ключевая тонкость правил — ранжирование. Условия отбирают кандидатов, но их обычно больше, чем мест в блоке. Нужен понятный порядок: сначала товары в наличии, затем более маржинальные или популярные, затем ближе по цене. Без явного ранжирования блок выдаёт случайный срез подходящих товаров, и его эффективность падает.

Поведенческие рекомендации: данные из заказов

Правила отвечают на вопрос «что похоже по описанию», но не знают, что покупатели на самом деле берут вместе. Этот пробел закрывают поведенческие рекомендации — они строятся на реальных данных о покупках и просмотрах. Главный и самый чистый источник для блока «с этим покупают» — история заказов.

Идея простая: если товар A и товар B часто оказываются в одних и тех же оформленных заказах, значит, между ними есть покупательская связь, даже если по свойствам они не похожи. Классический пример — «к принтеру берут бумагу и картриджи»: по характеристикам эти товары не пересекаются вообще, но в чеках стоят рядом. Такую связь никакие правила по свойствам не выявят, а история заказов покажет сразу.

Технически подбор поведенческих пар сводится к анализу состава заказов:

1. Соберите заказы. Возьмите оформленные (а лучше — оплаченные) заказы за период, например за последние 3–6 месяцев, чтобы данные были актуальными.
2. Разложите на пары. Для каждого заказа составьте все пары товаров, которые в него входят.
3. Посчитайте совстречаемость. Для каждой пары посчитайте, в скольких заказах она встречается вместе.
4. Отсейте шум. Уберите пары, встретившиеся слишком редко (одна-две покупки — это случайность, а не закономерность).
5. Сохраните связи. Для каждого товара сохраните список наиболее часто покупаемых с ним товаров в порядке убывания силы связи.

Более продвинутый вариант — учитывать не только абсолютное число совместных покупок, но и «неожиданность» связи (метрики вроде lift или confidence из ассоциативных правил). Это помогает не рекомендовать к каждому товару один и тот же ходовой аксессуар просто потому, что его берут вообще со всем. Но на старте достаточно простой совстречаемости с порогом отсечения — она уже даёт качественный блок «с этим покупают».

Архитектура: где считать и где хранить

Главный архитектурный принцип рекомендательной системы: тяжёлые вычисления не должны происходить в момент показа страницы. Анализ тысяч заказов и построение пар — операция дорогая, и делать её на каждый заход в карточку недопустимо: каталог мгновенно ляжет под нагрузкой. Поэтому вычисления и показ разносят во времени.

Рабочая схема состоит из трёх слоёв:

• Слой вычислений (офлайн). Фоновый агент по расписанию анализирует заказы и свойства, строит списки рекомендаций для каждого товара. Работает в часы низкой нагрузки, результат его работы — готовые связи.
• Слой хранения. Готовые рекомендации складываются туда, откуда их дёшево прочитать: в свойство-привязку товара, в highload-блок «товар → рекомендации» или в отдельную служебную таблицу. Здесь лежит уже посчитанный результат, а не сырые данные.
• Слой показа (онлайн). Компонент на карточке или в корзине просто читает готовый список из хранилища и выводит карточки. Он лёгкий, кэшируется и не делает тяжёлых запросов.

Такое разделение даёт сразу несколько выгод. Во-первых, скорость: показ рекомендаций стоит столько же, сколько чтение обычного свойства. Во-вторых, устойчивость: даже если пересчёт по какой-то причине не отработал, на карточке останутся прошлые рекомендации — деградация плавная. В-третьих, гибкость: логику подбора можно менять и усложнять в слое вычислений, не трогая вывод.

Отдельно стоит решить вопрос «свежести». Для большинства магазинов пересчёт раз в сутки ночью более чем достаточен — покупательские паттерны не меняются ежечасно. Ускорять пересчёт до нескольких раз в день имеет смысл только для очень динамичных каталогов с быстрой сменой ассортимента и акций.

Правила против поведения — сравнение подходов

Два основных подхода — правила и поведение — не конкурируют, а дополняют друг друга. Но чтобы правильно распределить усилия, полезно видеть их сильные и слабые стороны рядом.

Вывод из таблицы прямой: для «похожих» опорой служат правила, для «с этим покупают» — поведение, а новые товары и позиции с редкими покупками всегда подстраховываются правилами. Гибрид закрывает слабости каждого подхода: правила решают проблему «холодного старта», поведение добавляет неочевидные, но прибыльные связи.

Реализация в 1С-Битрикс

Перейдём от концепции к конкретным инструментам платформы. 1С-Битрикс даёт всё необходимое, чтобы собрать рекомендательную систему на штатных средствах. Разберём по слоям.

Хранение связей. Для ручных и правило-вычисленных рекомендаций удобно использовать свойство инфоблока типа «Привязка к элементам» — в нём хранится список товаров-рекомендаций для каждой позиции. Для больших объёмов поведенческих пар лучше подходит отдельный highload-блок с полями «товар», «рекомендация», «вес связи» и «тип» (похожие / сопутствующие). Highload-блок масштабируется и не раздувает основной инфоблок.

Источник данных о заказах. Состав заказов лежит в таблицах модуля «Интернет-магазин» (торговый каталог). Через API заказов и корзины (пространство \Bitrix\Sale) можно перебрать оформленные заказы за период и собрать из них пары товаров. Это и есть сырьё для поведенческих связей.

Вычисления. Логику пересчёта оформляют как агент или как консольную команду, запускаемую по cron. Агент разбирает заказы, строит пары, отсекает шум по порогу и записывает результат в хранилище. Тяжёлую работу выносят из веб-запроса именно сюда.

Вывод. На карточке товара и в корзине рекомендации показывают штатными компонентами каталога, которым на вход подаётся уже готовый список ID из свойства-привязки или highload-блока. Компонент кэшируется управляемым кэшем, поэтому повторный показ ничего не стоит.

Как это выглядит в админке 1С-Битрикс

Настройка рекомендаций живёт в двух местах: в свойствах товара (для связей) и в настройках компонента вывода (для правил и лимитов). Схематично карточка товара с блоком рекомендаций в админке выглядит так:

Агенты и пересчёт рекомендаций по расписанию

Сердце поведенческих рекомендаций — фоновый пересчёт. От того, как он организован, зависит и актуальность связей, и то, не будет ли он мешать посетителям. Разберём, как выстроить пересчёт правильно.

Запуск через cron, а не через хиты. Агенты 1С-Битрикс по умолчанию могут выполняться на хитах посетителей — это плохо для тяжёлых задач: пользователю не повезёт «оплатить» своим ожиданием чужой пересчёт. Тяжёлый анализ заказов запускайте по расписанию через cron в часы низкой нагрузки, ночью. Так пересчёт не влияет на живой трафик.

Пакетная обработка. Если заказов и товаров много, не пытайтесь обработать всё в одном проходе — процесс может упереться в лимиты времени и памяти. Разбивайте работу на партии: обработали N товаров, сохранили прогресс, продолжили в следующем шаге. Это устойчивее и не нагружает базу пиково.

Атомарная подмена результата. Пересчитывайте связи «рядом», а готовый результат подставляйте разом. Тогда посетители никогда не увидят полупосчитанное состояние: до момента подмены работают старые рекомендации, после — сразу новые целиком.

Прогрев кэша. После пересчёта имеет смысл сбросить и прогреть кэш компонентов рекомендаций, чтобы первые утренние посетители получили страницы уже из тёплого кэша, а не платили за первую пересборку.

Как рекомендации поднимают средний чек

Главная бизнес-цель блока «с этим покупают» — увеличить средний чек. Механика прироста складывается из нескольких эффектов, и полезно понимать каждый, чтобы усиливать нужные.

• Рост числа позиций в заказе. Основной эффект. Покупатель, пришедший за одним товаром, докупает сопутствующее, которое сам мог не вспомнить. Чек растёт за счёт количества строк.
• Продажа маржинальных дополнителей. Аксессуары и расходники часто маржинальнее основного товара. Даже небольшая по сумме допродажа заметно улучшает экономику заказа.
• Апселл на более дорогую версию. Блок «похожие» с уклоном вверх по цене подталкивает к более дорогой модели, поднимая чек по основной позиции.
• Снижение отказов. «Похожие» удерживают покупателя, которому не подошёл товар, — заказ вообще состоится, вместо того чтобы не случиться.

Чтобы эти эффекты работали, важно правильно выбирать место показа. Блок «с этим покупают» на карточке товара знакомит с аксессуарами, а тот же блок в корзине перед оформлением — это момент максимальной готовности докупить: «положить ещё стекло за 500 рублей» на фоне заказа на 30 000 воспринимается легко. Многие магазины недооценивают рекомендации именно в корзине, а это одно из самых конверсионных мест.

Ещё один рычаг — наборы и комплекты. Когда связка «товар + аксессуары» устойчива, её можно оформить как готовый комплект с небольшой выгодой за покупку целиком. Это повышает и средний чек, и воспринимаемую заботу магазина о покупателе. Логику допродажи и работу со средним чеком мы детально разбираем в материале про апселл и кросс-селл в 1С-Битрикс.

Метрики и A/B-тесты рекомендаций

«Рекомендации помогают» — гипотеза, которую нужно проверять цифрами, а не ощущением. Рекомендательная система хороша тем, что её эффект измерим напрямую. Вот метрики, за которыми стоит следить.

Ключевой инструмент проверки — A/B-тест. Разделите аудиторию на две группы: одной показывайте рекомендации, другой нет (или показывайте разные варианты логики подбора), и сравните средний чек и конверсию. Только так можно отделить реальный вклад рекомендаций от общего роста продаж. Важно тестировать достаточно долго, чтобы набрать статистическую значимость, и сравнивать сопоставимые периоды.

Отдельно отслеживайте «пустые показы» — карточки, где блок рекомендаций выводится пустым или почти пустым. Это чаще всего товары с «холодным стартом» или узкие категории, где правила не нашли кандидатов. Такие места нужно подстраховывать запасной логикой: показать хиты категории или бестселлеры магазина, чтобы блок никогда не был пустым.

Качество рекомендаций: фильтры и стоп-правила

Даже точная логика подбора нуждается в защитных фильтрах, иначе система начнёт рекомендовать нелепое. Набор стоп-правил отличает профессиональную рекомендательную систему от наивной.

• Только в наличии и активные. Никогда не рекомендуйте товар, которого нет в продаже или который скрыт. Пустой клик — это разочарование и подрыв доверия к блоку.
• Не рекомендовать сам товар. Очевидно, но регулярно всплывает: карточка не должна ссылаться сама на себя.
• Исключать несочетаемое. К товару категории A не предлагайте аксессуары от несовместимой категории B (чехол не от той модели). Совместимость — отдельное свойство, которое стоит учитывать.
• Ограничивать «вездесущие» товары. Ходовой аксессуар, который берут со всем подряд, не должен вытеснять более релевантные связи. Здесь помогают метрики «неожиданности» связи.
• Свежесть данных. Не стройте поведенческие связи на слишком старых заказах — ассортимент и спрос меняются. Ограничьте окно анализа разумным периодом.
• Лимит и разнообразие. Показывайте 4–8 рекомендаций, а не двадцать; следите, чтобы блок не состоял из почти одинаковых позиций.

Эти фильтры удобно применять на слое вычислений — тогда в хранилище попадают уже «чистые» рекомендации, а компонент показа остаётся простым. Отдельно полезно предусмотреть ручное вмешательство: возможность закрепить или, наоборот, запретить конкретную связь. Автоматика хороша, но человеческий контроль над флагманскими товарами и акциями обычно окупается.

Частые ошибки при внедрении

• Смешивают «похожие» и «с этим покупают» в одном блоке — он теряет смысл и не работает ни на конверсию, ни на чек.
• Считают связи «на лету» в момент показа карточки — каталог тормозит под нагрузкой, вместо того чтобы читать готовый результат.
• Рекомендуют товары не в наличии или скрытые — клик ведёт в никуда, доверие к блоку падает.
• Строят поведенческие пары по всем заказам, включая отменённые и невыкупленные, — статистика искажается.
• Оставляют пустые блоки на новых товарах без запасной логики — «холодный старт» создаёт дыры в витрине.
• Не отсекают шум: пара из одной случайной покупки попадает в рекомендации как «часто покупают вместе».
• Забывают про блок в корзине — теряют самое конверсионное место для допродажи.
• Внедряют рекомендации и не меряют эффект — невозможно понять, работают они или просто занимают место.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность рекомендательной системы перед запуском:

1. Блоки разделены. «Похожие» (заменители) и «с этим покупают» (дополнители) — это два разных блока с разной логикой.
2. Правила настроены. Для «похожих» заданы условия по категории, цене и свойствам; для аксессуаров связаны категории.
3. Поведение подключено. Пары из истории оплаченных заказов строятся с порогом отсечения шума.
4. Вычисления вынесены в офлайн. Пересчёт связей делает агент/cron ночью, не на хитах посетителей.
5. Результат кэшируется. Готовые рекомендации лежат в свойстве или highload-блоке, компонент их только читает.
6. Стоп-фильтры включены. Только в наличии, без самоссылки, с учётом совместимости; пустые блоки подстрахованы бестселлерами.
7. Место показа продумано. Блоки стоят на карточке и в корзине, где готовность к покупке максимальна.
8. Эффект измеряется. Настроены CTR блока, доля заказов с допродажей, средний чек; запущен A/B-тест.

Вывод

Рекомендательная система в 1С-Битрикс — это не обязательно дорогой внешний сервис. Начните с двух чётко разделённых блоков и правил по свойствам, добавьте поведенческие связи из истории заказов, вынесите вычисления в фоновый агент и меряйте эффект A/B-тестом. Такой подход даёт прирост среднего чека уже с первых недель и планомерно улучшается по мере роста магазина — вы монетизируете трафик, за который уже заплатили.