Рассказываем реальный кейс Брейнфорса: 12 000 товаров в 1С, а на сайте — всего 1 000. Торговые предложения убивали поиск и фильтр. Мы отказались от них и получили рост заказов на 30%. Как — читайте ниже. А в моем Телеграм канале есть информация, которой никогда не было и не будет здесь. Самое "мясо".
Почему торговые предложения — это не всегда хорошо
В мире e-commerce есть негласное правило: если вы продаёте товары с вариациями (размер, цвет, материал), вы должны использовать торговые предложения. В Битриксе для этого есть SKU, в 1С — выгрузка «из коробки». Звучит правильно. На словах.
Но на практике всё иначе.
Когда мы в Брейнфорс взялись за проект, клиент уже прошёл «стандартный» путь. И он привёл в тупик. Торговые предложения создали хаос: поиск не находил товары, фильтр выдавал пустые страницы, а 90% ассортимента покупатели просто не видели.
Мы решили пойти против правил. Отказались от торговых предложений, переделали логику обмена с 1С и получили рост заказов в 1,3 раза. Вот как это было.
Три фатальных недостатка торговых предложений
1. Поиск слепнет
Компонент поиска Битрикса по умолчанию ищет только по родительским товарам, игнорируя торговые предложения. Покупатель вводит артикул конкретного размера — поиск говорит «ничего не найдено». Хотя товар есть.
Представьте: человек ищет «кеды белые 42 размер». Поиск выдаёт просто «кеды». Дальше нужно кликать на карточку, разворачивать список размеров, искать свой. Это минимум три лишних действия. Каждое — потеря конверсии.
Особенно сейчас, когда все избалованы Wildberries и Ozon и не хотят даже думать, не то что кликать лишний раз.
Да, можно доработать поиск под торговые предложения. Но посмотрите на выдачу — она часто остаётся неудобной и непонятной.
2. Фильтр врёт
Умный фильтр Битрикса — мощный инструмент. Но с торговыми предложениями он работает непредсказуемо. Покупатель ставит фильтр «размер 42» и «цвет белый». Система должна показать подходящие товары. Вместо этого часто выдаёт пустую страницу или все товары без учёта фильтра.
Почему? Фильтр работает с родительским элементом, а не с торговыми предложениями. Чтобы он «видел» размеры и цвета, нужны сложные доработки. И даже в этом случае при выборе, например, «красного» цвета в каталоге покажется главная карточка товара, где цвет может быть белым. Это запутывает покупателя.
3. Пользовательский опыт страдает
Люди приходят за товаром, а не за архитектурными решениями. Когда вместо конкретной карточки с ценой и размером они видят конструктор «выберите цвет, размер, материал» — это раздражает.
Особенно если сайт — не гигантский маркетплейс, а магазин с небольшим ассортиментом. Покупатели привыкли видеть конкретные товары, сравнивать, добавлять в корзину одним кликом. Торговые предложения усложняют путь. Каждый шаг усложнения — потерянная продажа.
История провала: как мы потеряли 12 000 товаров
Клиент пришёл с типичной проблемой производителя. В 1С — 12 000 единиц номенклатуры. Однотипные товары, различающиеся характеристиками: напряжение, мощность, совместимость с моделями. На сайте отображалось только 1 000 позиций. Остальные существовали в учёте, но покупатели их не видели.
Мы пошли по стандартному пути: создали торговые предложения, настроили выгрузку по документации. И получили катастрофу.
Первое: многие товары не выгрузились. Списочные свойства 1С передавала в формате, который Битрикс отказывался понимать. Система либо пропускала их, либо записывала только первое значение.
Второе: из-за ошибок интерпретации Битрикс создавал не те товары. Происходило склеивание или дублирование. Вместо 12 000 уникальных карточек появлялось 1 000 некорректных.
Что мы перепробовали (и почему не сработало)
Попытка №1. Доработать 1С
Идея: изменить обработку обмена на стороне 1С, чтобы передавать данные в нужном формате. Технически возможно — CommerceML позволяет расширять структуру.
Отказались, потому что:
- Дорого. Нужен отдельный специалист по 1С.
- Долго. Каждая доработка требует тестирования и согласований.
- Негибко. При обновлении конфигурации всё придётся переделывать.
Попытка №2. Подобрать типы свойств в Битриксе
Перебирали типы свойств в инфоблоке: строки, списки, справочники. Ничего не работало. 1С упорно передавала данные в своём формате, Битрикс — не понимал.
Борьба длилась неделями. Даже множественные свойства «список» не помогли — в ядре Битрикса оказался баг: для таких свойств импорт обрабатывает только первое значение из XML. Остальные отбрасываются.
Попытка №3. Ловить события обновления
Пытались перехватить данные через штатные события Битрикса: OnAfterIBlockElementUpdate, OnAfterIBlockElementAdd. Идея: после загрузки товара из 1С «дописать» нужные свойства.
Не сработало. При импорте через 1c_exchange.php многие события либо не вызываются, либо срабатывают до полной записи данных в базу.
Как мы нашли решение: работа с XML-файлом напрямую
Когда стандартные методы провалились, мы пошли в обход. 1С выгружает данные в XML-файл. Битрикс его принимает и обрабатывает. В этом процессе есть момент, когда файл уже на сервере, но ещё не обработан. Идеальная точка для вмешательства.
Мы нашли событие, которое вызывается при получении XML-файла из обмена. Оно гарантированно срабатывает и даёт доступ к исходным данным.
Что мы сделали в обработчике:
- Получили путь к XML-файлу.
- Распарсили структуру, нашли нужные узлы с характеристиками.
- Построили массивы данных, провели необходимые обработки.
- Записали данные напрямую в инфоблок через CIBlockElement::SetPropertyValues.
Всё за один проход, без костылей. Для технарей: мы создали массив связок, по определённому значению свойства объединяли товары, обновляли служебное свойство, не участвующее в обмене. Алгоритм работает только с import.xml — в offers и rests не лезем, там нет нужных данных.
Почему этот подход правильный:
- Не зависит от версий. Не нужно переписывать код при обновлениях.
- Не требует правки 1С. Клиент сэкономил бюджет и время.
- Работает для любых свойств. Списочные, множественные, привязки — всё обрабатывается.
- Прозрачно для пользователя. Интерфейс не ломается, лишних сущностей нет.
Итоги: что мы получили
После внедрения новой логики:
- Каталог расширился с 1 000 до 12 000 позиций. Все необходимые товары выгрузились без потерь и дублей.
- Фильтрация заработала как часы. Покупатели выбирают по любым характеристикам — от простых до сложных.
- Поиск перестал терять товары. Артикулы, названия, характеристики — всё индексируется.
- Через месяц после индексации заказы выросли в 1,3 раза.
Рост в 1,3 раза — не случайность. Это прямое следствие того, что ассортимент стал видимым, а покупатели перестали натыкаться на пустые страницы.
Что это значит для бизнеса в деньгах
Допустим, до внедрения магазин делал 50 заказов в день со средним чеком 3 000 рублей. Это 150 000 рублей выручки в день.
После внедрения — 65 заказов в день. Это уже 195 000 рублей. Плюс 45 000 рублей ежедневно.
За месяц +1,3 млн рублей. За год — более 15 млн дополнительной выручки.
Затраты на доработку — разовые. Окупаемость такого проекта — 1–2 недели.
Бонус: команда выдохнула
До внедрения менеджеры тратили часы на ручную правку каталога. Товары не выгружались — нужно было заходить в админку, искать, исправлять, дописывать свойства.
После настройки автоматической выгрузки через обработку XML эта работа ушла. Менеджеры перестали править каталог и занялись продажами. Это ещё один фактор роста.
Главный урок: слушайте бизнес, а не документацию
Когда мы начинали, мы тоже пытались сделать «как правильно». Потратили недели на то, чтобы подогнать 1С под Битрикс, перебирали типы свойств, ловили события. Ничего не работало.
Только когда мы отбросили документацию и посмотрели на проблему с точки зрения бизнеса («нам нужно, чтобы все товары были на сайте, и покупатели их находили»), мы нашли правильное решение.
Документация — это хорошо. Но бизнес клиента и его конечная цель куда важнее.
Как повторить этот успех у себя
Если вы узнали свою ситуацию:
- огромный каталог в 1С;
- проблемы с фильтрацией и поиском;
- потеря ассортимента при выгрузке;
- ручная правка товаров менеджерами;
то наш опыт — готовая дорожная карта.
Мы не чиним 1С. Мы не ломаем Битрикс. Мы находим точку, где данные ещё не испорчены, и обрабатываем их так, как нужно бизнесу.
P.S. В статье мы намеренно опустили технические детали реализации, потому что они не важны для принятия бизнес-решения. Если вам интересен технический разбор — мы можем провести отдельную консультацию.