Логика «похожие товары» и рекомендаций на бэкенде

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

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

Зачем нужны рекомендации и что они дают

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

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

Похожие, сопутствующие, персональные

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

Смешивать их в один блок с общей логикой — ошибка: похожие ищутся по близости свойств в той же категории, сопутствующие — по связям между разными категориями, персональные — по поведению конкретного пользователя. Каждый тип строится своим механизмом.

Правила на свойствах как основа

Базовый и самый надёжный слой — детерминированные правила на свойствах товара. Они предсказуемы, работают сразу без накопленных данных и не зависят от трафика.

• Та же категория. Похожие ищутся в рамках категории или смежных разделов.
• Близость характеристик. Совпадение по значимым свойствам — тип, назначение, ключевые параметры.
• Коридор цены. Альтернатива в разумном ценовом диапазоне от исходного товара.
• Тот же бренд или заменители. В зависимости от стратегии — либо близкие модели бренда, либо конкуренты.

Правила опираются на свойства инфоблоков и торговых предложений, поэтому качество рекомендаций упирается в качество данных каталога. Если свойства не заполнены, похожесть считать не по чему. Навести порядок в данных помогает аудит и оптимизация 1С.

Как считать похожесть по характеристикам

Похожесть — это измеримая близость товаров по набору свойств. Логика расчёта:

1. Выберите значимые свойства. Для категории определите, что важно: бренд, тип, параметры, цена.
2. Задайте веса. Для одной категории важнее бренд, для другой — технический параметр.
3. Оцените близость. Сравните кандидатов с исходным товаром по взвешенным свойствам.
4. Отфильтруйте и отсортируйте. Отсеките далёкие, отсортируйте по убыванию близости.
5. Ограничьте выдачу. Возьмите топ-N для блока, исключив сам товар.

Такой расчёт удобно вести через ORM с эффективными выборками по свойствам; подходы мы разбираем в статье про D7 ORM в Битрикс.

BigData-рекомендации Битрикс

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

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

ИИ-сервисы и смысловая близость

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

Где ИИ уместен, а где избыточен:

• Уместен. Мало структурированных свойств, богатые описания, потребность в персонализации на больших данных.
• Избыточен. Чистый каталог с полными свойствами — правила проще, дешевле и предсказуемее.

Разумно начинать с правил и BigData, а ИИ подключать точечно там, где они не справляются, обязательно проверяя качество выдачи, чтобы модель не подмешивала нерелевантное.

Предрасчёт и кэширование

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

• Фоновый предрасчёт. Списки похожих считаются агентом или по расписанию, а не на запрос.
• Кэш выдачи. Готовый список отдаётся на карточке из кэша мгновенно.
• Пересчёт по событиям. Обновление при значимых изменениях каталога, а не постоянно.
• Вынос тяжёлого в очередь. Массовый пересчёт — в фоновые задания, чтобы не нагружать сайт в пик.

Так блок рекомендаций остаётся быстрым даже на большом каталоге. Общие подходы к скорости витрины — композитный сайт, кэширование — усиливают эффект; инфраструктурную сторону мы разбираем в статье про хостинг и инфраструктуру на BitrixVM.

Наличие и цена на выдаче

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

• Фильтр по наличию. Отсутствующие позиции убираются из блока на выдаче.
• Цена группы клиента. Показывается цена, соответствующая группе авторизованного пользователя.
• Актуальность поверх кэша. Наличие и цена подмешиваются к закэшированному списку, а не пересчитываются целиком.

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

Оценка качества рекомендаций

Рекомендации нельзя настроить «на глаз и забыть» — их измеряют по влиянию на поведение.

• Клики по блоку. Насколько рекомендации интересны пользователю.
• Добавления в корзину из блока. Прямой вклад в продажи.
• Доля заказов с рекомендованными товарами. Как часто рекомендации доходят до покупки.
• Средний чек. Влияние сопутствующих товаров на сумму заказа.

Разные алгоритмы и составы блоков тестируют на реальном трафике через A/B, а не по интуиции. Метрика успеха — измеримый вклад в продажи, а не «красивый блок» на карточке.

Частые ошибки

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

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

1. Типы разведены. Похожие, сопутствующие и персональные строятся своей логикой.
2. Данные готовы. Значимые свойства заполнены, категории и цены корректны.
3. Правила настроены. Близость по свойствам с весами, коридором цены и порогом релевантности.
4. Слои скомбинированы. Правила как основа, BigData и ИИ — обогащение при достаточных данных.
5. Предрасчёт и кэш. Списки считаются в фоне и отдаются из кэша.
6. Наличие и цена на выдаче. Отсутствующее скрыто, показана цена группы клиента.
7. Качество измеряется. Клики, добавления, доля заказов, чек; A/B-тесты алгоритмов.

Вывод

Ценность рекомендаций целиком в логике на бэкенде, а не в вёрстке блока. Разведите типы — похожие, сопутствующие, персональные, — постройте предсказуемую основу на правилах по свойствам и обогащайте её BigData-рекомендациями и ИИ там, где хватает данных и где формальных свойств мало. Так блок показывает настоящие альтернативы и дополнения, а не случайный мусор.

Инженерно всё держится на двух принципах: тяжёлый подбор предрассчитывается в фоне и кэшируется, а актуальные наличие и цена подмешиваются на выдаче. И обязательно измеряйте вклад рекомендаций в продажи через метрики и A/B — только так блок из декорации превращается в инструмент, который удерживает покупателя и поднимает средний чек.