Сопутствующие товары и аксессуары в каталоге 1С-Битрикс: связи и автоподбор

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

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

Зачем магазину блоки сопутствующих товаров

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

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

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

Виды связей: аксессуары, «с этим покупают», похожие, комплекты

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

Аксессуары

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

«С этим товаром покупают»

Это статистическая связь: система показывает то, что фактически кладут в корзину вместе с текущим товаром. Здесь не важна логическая совместимость — важна наблюдаемая закономерность. К кофемашине берут капсулы и средство от накипи; к краске — валик и малярную ленту. Такие связи формируются автоматически из истории заказов или через BigData и постоянно обновляются: сезонность, акции и мода меняют реальные пары покупок.

Похожие товары

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

Комплекты и наборы

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

Апселл и кросселл: в чём разница и где что показывать

Два английских термина, которые постоянно мелькают в разговорах о среднем чеке, — апселл (up-sell) и кросселл (cross-sell). Разница между ними принципиальная, и от неё зависит, какой товар и в каком месте показывать.

Апселл — это предложение более дорогой или продвинутой версии того же товара. Покупатель смотрит модель за 30 000, а вы показываете «а вот эта — с большей памятью за 38 000, разница всего 8 000». Цель апселла — поднять сумму по основной позиции, переключив внимание на топовую версию. Уместное место апселла — на самой карточке товара, рядом с ценой и вариантами, пока решение о конкретной модели ещё не принято.

Кросселл — это предложение дополнительных товаров к выбранному: аксессуаров, расходников, услуг. Цель — добавить в корзину вторую (третью, четвёртую) позицию. Кросселл хорошо работает и на карточке («с этим товаром берут»), и особенно в корзине, когда основной выбор уже сделан и покупатель мысленно «в режиме покупки». Именно кросселл чаще всего и подразумевают под «сопутствующими товарами».

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

Ручные связи через свойство «привязка к элементам»

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

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

1. Создайте свойства связей. В инфоблоке каталога добавьте свойства ACCESSORIES («Аксессуары») и, при необходимости, RELATED («С этим покупают, ручной список»). Тип — «Привязка к элементам инфоблока», множественное — «Да».
2. Настройте вид в карточке. Для удобства менеджера включите режим выбора «диалог с автозаполнением» — поиск по названию и артикулу, а не длинный выпадающий список на весь каталог.
3. Заполните связи. В карточках товаров-«локомотивов» (телефоны, техника, мебель) укажите подходящие аксессуары. Начните с топовых позиций — они дают основную выручку.
4. Выведите блок в шаблоне. Прочитайте свойство, соберите массив ID и передайте в bitrix:catalog.section с фильтром по ID или в специализированный компонент вывода списка.
5. Проверьте наличие и активность. В выводе отфильтруйте неактивные и отсутствующие в наличии товары, чтобы блок не показывал «мёртвые» позиции.

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

Автоподбор по свойствам, разделу и бренду

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

Основные принципы автоподбора:

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

Технически автоподбор — это выборка через catalog.section или прямой запрос к CIBlockElement / D7-API (\Bitrix\Iblock\ElementTable) с фильтром по свойствам текущего товара и исключением его самого из результатов. Чтобы блок не был случайным набором, добавьте сортировку по осмысленному признаку: сортировка по популярности (число продаж), по рейтингу или по показателю наличия выводит наверх то, что действительно берут.

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

Рекомендации на основе истории заказов

Самые точные рекомендации «с этим покупают» строятся не по свойствам, а по фактам — по реальным заказам вашего магазина. Логика проста: если товар A и товар B часто встречаются в одних и тех же заказах, значит, показывая A, стоит рекомендовать B. Это классический анализ рыночной корзины (market basket analysis), и в 1С-Битрикс для него есть все данные — модуль продаж хранит полную историю заказов и их состав.

Реализовать такие рекомендации можно несколькими способами:

• Периодический расчёт пар. Агент или крон-скрипт раз в сутки/неделю проходит по заказам за период, считает совместную встречаемость товаров и складывает топ-совместных в отдельное свойство или служебную таблицу. Днём карточка просто читает готовый результат — быстро и без нагрузки.
• Расчёт «на лету» с кэшем. При открытии карточки система запрашивает заказы, содержащие текущий товар, и агрегирует, что ещё в них было. Результат кэшируется на несколько часов. Подходит для средних каталогов.
• Гибрид с ручным приоритетом. Автоматические пары дополняются ручными связями и модерацией: менеджер убирает нерелевантные или неуместные пары (например, случайные совпадения), оставляя осмысленные.

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

BigData «Персонализация» в 1С-Битрикс

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

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

BigData предлагает несколько типовых сценариев рекомендаций, каждый под свою зону сайта:

Технически BigData подключается через компонент bitrix:catalog.bigdata.products (или main.recommended.products в старых сборках). Вы указываете тип рекомендации, число товаров и оформление, а данные подтягиваются из облака Битрикса. Компонент умеет работать асинхронно: сначала отдаётся страница, затем блок догружается запросом к сервису — это правильно с точки зрения скорости.

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

Где выводить блоки: карточка и корзина

Место вывода блока не менее важно, чем его содержимое. Один и тот же список товаров работает по-разному в зависимости от того, где и когда его показать. Разберём две ключевые зоны.

Карточка товара

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

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

Важно не перегружать карточку: три-четыре блока по 4–8 товаров — потолок. Больше — и покупатель тонет в выборе, а страница тяжелеет. Приоритет отдавайте аксессуарам с высокой конверсией докупки.

Корзина и оформление заказа

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

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

Реализация в 1С-Битрикс: компоненты и настройка

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

Компоненты вывода

• bitrix:catalog.section — универсальный вывод списка товаров с фильтром. Для ручных связей передаёте в фильтр массив ID из свойства-привязки; для автоподбора — условия по свойствам, разделу, бренду.
• bitrix:catalog.top — вывод топовых/популярных товаров, удобно для fallback «хиты продаж», когда персональных данных нет.
• bitrix:catalog.bigdata.products — персональные рекомендации из облака BigData. Указываете тип рекомендации (похожие, сопутствующие, персональные, бестселлеры) и число позиций.
• bitrix:sale.basket.basket и шаблон корзины — сюда встраивается блок кросселла в корзине, чаще всего через дополнительный вызов catalog.bigdata.products или catalog.section.

Пошаговая настройка ручных аксессуаров

1. Свойство-привязка. «Контент → Инфоблоки → каталог → Свойства»: создайте свойство «Аксессуары», тип «Привязка к элементам инфоблока», множественное, привязка к инфоблоку каталога.
2. Заполнение в карточке. В карточке товара выберите аксессуары через диалог поиска. Начните с товаров-локомотивов.
3. Вывод в шаблоне. В шаблоне карточки прочитайте значение свойства (массив ID) и передайте в catalog.section с фильтром ['ID' => $ids, 'ACTIVE' => 'Y'] и, при необходимости, условием наличия.
4. Оформление. Подключите тот же шаблон карточки товара (плитки с ценой и кнопкой «в корзину»), что и в каталоге, для единого вида.
5. Кэш. Включите кэширование компонента и добавьте в кэш-ключ ID текущего товара, чтобы блоки разных карточек не смешивались.

Кэширование и производительность блоков

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

Базовые правила скорости:

• Кэшируйте компоненты вывода. Тип кэша — «Авто» (managed cache) с тегированием инфоблока. Тогда блок пересобирается только при изменении товаров, а не на каждый запрос.
• Правильный кэш-ключ. Для персональных и контекстных блоков добавляйте в ключ кэша ID товара, раздел, а для персонализации — признак сегмента. Иначе разные карточки будут показывать один и тот же закэшированный блок.
• Ограничивайте выборку. Не подбирайте «похожие» по всему каталогу без лимита. Ставьте разумный nPageSize (4–8), фильтруйте по разделу и наличию — это резко сокращает объём работы.
• Тяжёлые расчёты — заранее. Совместную встречаемость по заказам считайте агентом по расписанию и складывайте результат, а не пересчитывайте на лету при каждом открытии.
• BigData — асинхронно. Компонент BigData подгружает данные из облака отдельным запросом уже после отрисовки страницы. Не блокируйте им основной контент.
• Композитный кэш. На карточке статику отдавайте композитом мгновенно, а динамические блоки догружайте — это улучшает LCP и INP.

Управление связями и загрузка из 1С

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

Ведение связей на стороне сайта

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

Загрузка связей из 1С

Если матрица совместимости ведётся в 1С (например, у производителя или дистрибьютора есть справочник аналогов и сопутствующих), связи логично передавать на сайт через обмен CommerceML. В правилах обмена вы сопоставляете реквизит или характеристику номенклатуры со свойством инфоблока-привязкой. Тогда связи приезжают вместе с товарами и всегда синхронны с учётом. Тонкость: в CommerceML связи передаются идентификаторами (XML_ID) товаров, и важно, чтобы сопоставление элементов было корректным, иначе привязки «повиснут» на несуществующих ID.

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

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

Влияние на средний чек и метрики

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

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

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

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

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

Что имеет смысл проверять A/B-тестом:

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

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

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

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

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

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

1. Типы связей разделены. Аксессуары, «с этим покупают», похожие и комплекты выведены разными блоками с понятными заголовками.
2. Свойства-привязки созданы. В инфоблоке есть свойства для ручных связей, тип «Привязка к элементам», множественное, с удобным выбором.
3. Локомотивы связаны вручную. Топовые товары имеют выверенные аксессуары; остальное закрыто автоподбором.
4. Автоподбор настроен. Правила по разделу, бренду и цене дают релевантные «похожие», текущий товар исключён из выдачи.
5. Рекомендации по заказам считаются. Совместная встречаемость рассчитывается агентом, с поправкой на популярность и фильтрацией шума.
6. BigData подключён. Компонент bigdata.products выводит персональные и сопутствующие подборки асинхронно, с fallback на бестселлеры.
7. Блоки в карточке и корзине. Аксессуары — у кнопки покупки, кросселл — в корзине, наличие и дубли отфильтрованы.
8. Кэш и скорость. Компоненты кэшируются с корректным ключом, тяжёлое считается заранее, композит отдаёт статику мгновенно.
9. Связи и 1С согласованы. Определён источник правды, обмен не затирает ручные поля, привязки указывают на активные товары.
10. Метрики и тесты. Настроена атрибуция добавлений из блоков, запущен базовый A/B-тест, эффект измеряется по доле заказов с рекомендацией.

Вывод

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