Каталожные рекомендации (BigData) в 1С-Битрикс

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

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

Зачем магазину рекомендации

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

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

Как устроен BigData в 1С-Битрикс

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

Ключевые элементы механизма:

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

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

Виды рекомендаций

Рекомендации бывают разные, и каждый тип закрывает свою задачу. Сведём в таблицу.

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

Где размещать блоки

Место блока не менее важно, чем его тип. Классические точки размещения:

• Карточка товара. Похожие (для сомневающихся) и сопутствующие (для допродажи) рядом с товаром.
• Корзина. «Забыли добавить?» — аксессуары и дополнения к выбранному, прямая допродажа.
• Главная страница. Персональные подборки для вернувшихся, популярное для новичков.
• Страница «спасибо за заказ». Рекомендации на следующий заказ, пока клиент вовлечён.

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

Сбор данных и качество

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

Отсюда практические выводы:

• BigData раскрывается на потоке. Магазину с ощутимым трафиком и историей заказов есть что анализировать.
• Нужно время накопления. После запуска сбора данным надо накопиться, прежде чем подборки станут точными.
• Полнота событий. Собирать нужно все ключевые действия: просмотры, корзину, покупки — иначе картина неполна.
• Малому магазину — простые правила. При малом трафике иногда практичнее правила (та же категория, бренд), а к BigData прийти по мере роста.

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

Настройка компонента

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

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

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

Метрики и оценка эффекта

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

• CTR блоков. Как часто по рекомендациям кликают — базовый сигнал релевантности.
• Доля заказов с рекомендацией. Сколько заказов и выручки прошло через клик по подборке.
• Влияние на средний чек. Растёт ли сумма заказа там, где работают сопутствующие товары.
• Глубина просмотра. Дольше ли пользователи остаются, переходя по рекомендациям.

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

Рекомендации в B2B

В B2B рекомендации работают иначе, чем в рознице, потому что иначе устроено поведение. Закупщик не совершает импульсивных покупок: он заказывает повторяющиеся позиции по спецификациям. Поэтому импульсные «похожие» здесь менее полезны, а на первый план выходят сопутствующие (расходники, комплектующие к заказу) и персональные подборки на основе истории заказов клиента.

Есть и важные ограничения. В опте цены зависят от группы клиента, а наличие — от склада, поэтому рекомендации обязаны учитывать эти данные: нельзя показывать закрытые цены гостю или рекомендовать недоступное клиенту. Часто для B2B штатные рекомендации дополняют или заменяют собственной логикой на основе истории заказов из 1С. Как строить такие данные и связи, мы отчасти затрагивали в материалах про интеграцию и работу с данными через D7 ORM.

Приватность и юридическая сторона

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

Что стоит сделать:

• Политика конфиденциальности. Описать сбор поведенческих данных и цели их использования.
• Уведомление о куках. Информировать посетителя об использовании cookie и трекинга.
• Учёт законодательства. Соблюдать требования к обработке персональных данных, где они применимы.
• Прозрачность. Не собирать больше, чем нужно, и не смешивать обезличенные данные с чувствительными.

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

Производительность и кэш

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

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

Внедрение пошагово

Подключение рекомендаций разворачивают по понятной последовательности.

1. Включите сбор данных. Активируйте счётчики поведения и убедитесь, что фиксируются просмотры, корзина и заказы.
2. Дайте данным накопиться. После запуска сбора выждите период накопления перед оценкой качества.
3. Разместите базовые блоки. Похожие и сопутствующие в карточке, допродажа в корзине.
4. Настройте фильтрацию. Учитывайте наличие, а для опта — цены по группам и склад клиента.
5. Подключите измерение. Разметьте блоки в веб-аналитике, настройте отслеживание кликов и заказов.
6. Оцените и скорректируйте. По метрикам меняйте типы, места и число блоков.
7. Оформите юридическую часть. Обновите политику конфиденциальности и уведомление о куках.

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

• Ждут чуда на малом трафике. Данных мало, рекомендации слабы, а разочарование списывают на сам инструмент.
• Перегружают страницу блоками. Пять подборок конкурируют между собой и размывают внимание.
• Рекомендуют недоступное. Нет фильтрации по наличию — блок ведёт к товару, которого нет.
• Не измеряют эффект. Блоки стоят «для красоты», без метрик непонятно, помогают ли они.
• Игнорируют B2B-специфику. Показывают закрытые цены гостю или импульсные подборки закупщику.
• Забывают про приватность. Сбор поведения не отражён в политике и уведомлении о куках.
• Тормозят первый экран. Тяжёлые персональные блоки грузятся синхронно и портят LCP.

Чек-лист и вывод

1. Сбор данных включён: просмотры, корзина и заказы фиксируются полностью.
2. Данные накоплены: прошёл период наполнения перед оценкой качества.
3. Блоки размещены логично: похожие и сопутствующие в карточке, допродажа в корзине, без перегруза.
4. Фильтрация настроена: учтено наличие, а для опта — цены по группам и склад.
5. Измерение работает: блоки размечены, отслеживаются клики, заказы и чек.
6. Настройка итеративна: типы и места блоков корректируются по метрикам.
7. Юридическая часть оформлена: политика и уведомление о куках обновлены.

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

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