Разработка системы рекомендаций товаров 1С-Битрикс

Вы теряете до 30% выручки, если в вашем интернет-магазине на 1С-Битрикс нет персонализированных рекомендаций. Покупатель приходит за конкретным товаром, но не видит сопутствующих позиций, не получает предложений на основе своих интересов — и уходит к конкурентам. Мы решаем эту задачу, внедряя системы рекомендаций, которые увеличивают средний чек на 15–25% и конверсию в покупку. Опыт 10+ лет, сертифицированные специалисты, гарантия результата.

Почему персонализация так эффективна?

Персонализированные рекомендации работают потому, что снижают когнитивную нагрузку на покупателя. Вместо того чтобы перебирать сотни товаров, он видит только релевантные варианты. Алгоритмы анализируют поведение пользователя — просмотры, добавления в корзину, покупки — и подбирают то, что с высокой вероятностью заинтересует именно его. Сравните: по данным нашей практики, collaborative filtering даёт CTR на 30% выше, чем content-based, при наличии 1000+ действий на товар. Исследование McKinsey показывает, что персонализация повышает выручку на 10-30%.

Как алгоритмы рекомендаций повышают конверсию?

Выбор алгоритма определяет точность рекомендаций. Рассмотрим основные подходы.

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

function getContentBasedRecommendations(int $productId, int $limit = 10): array {
    $product  = \CIBlockElement::GetByID($productId)->GetNext();
    $iblockId = $product['IBLOCK_ID'];
    $price    = \CPrice::GetBasePrice($productId)['PRICE'];
    $sectionId = $product['IBLOCK_SECTION_ID'];

    // Товары из той же категории в ценовом диапазоне ±30%
    $result = \CIBlockElement::GetList(
        ['RAND' => 'ASC'],
        [
            'IBLOCK_ID'          => $iblockId,
            'IBLOCK_SECTION_ID'  => $sectionId,
            '!ID'                => $productId,
            '>=CATALOG_PRICE_1'  => $price * 0.7,
            '<=CATALOG_PRICE_1'  => $price * 1.3,
            'ACTIVE'             => 'Y',
        ],
        false,
        ['nPageSize' => $limit],
        ['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE']
    );

    $items = [];
    while ($item = $result->GetNext()) {
        $items[] = $item;
    }
    return $items;
}

Алгоритм прост в реализации и работает моментально, но не учитывает вкусы конкретного пользователя.

Collaborative filtering — «пользователи, которые смотрели этот товар, также смотрели...» Требует накопленной истории просмотров и покупок, но даёт более персонализированные рекомендации. Собираем данные из:

• b_sale_basket и b_sale_order — реальные покупки.
• Кастомная таблица custom_product_views — просмотры карточек.
• b_sale_fuser — гостевые пользователи.

Производительность коллаборативной фильтрации на 30% выше content-based по CTR при наличии 1000+ действий на товар.

Матричная факторизация (ALS/SVD) — продвинутый алгоритм, требует библиотек (Python: implicit, surprise). Выносим расчёт рекомендаций в отдельный микросервис на Python, результаты сохраняем в Redis/PostgreSQL, Битрикс только читает. Такой подход даёт прирост CTR до 12% на крупных каталогах.

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

// Трекинг просмотра товара
// Вызывается в шаблоне компонента catalog.element
$userId  = $USER->GetID() ?: 0;
$fuserId = (int)\Bitrix\Sale\Fuser::getId();

$db->query("
    INSERT INTO custom_product_views (product_id, user_id, fuser_id, viewed_at)
    VALUES (?, ?, ?, NOW())
    ON DUPLICATE KEY UPDATE view_count = view_count + 1, viewed_at = NOW()
", [$productId, $userId, $fuserId]);

CREATE TABLE custom_product_views (
    id         SERIAL PRIMARY KEY,
    product_id INT NOT NULL,
    user_id    INT DEFAULT 0,
    fuser_id   INT NOT NULL,
    view_count INT DEFAULT 1,
    viewed_at  DATETIME,
    UNIQUE KEY uk_product_fuser (product_id, fuser_id),
    INDEX idx_fuser (fuser_id),
    INDEX idx_product (product_id)
);

Расчёт «пользователи также смотрели»

-- Товары, которые чаще всего смотрят вместе с товаром $productId
SELECT
    v2.product_id,
    COUNT(DISTINCT v2.fuser_id) AS co_views
FROM custom_product_views v1
JOIN custom_product_views v2
    ON v1.fuser_id = v2.fuser_id
    AND v2.product_id != v1.product_id
    AND v2.viewed_at BETWEEN DATE_SUB(v1.viewed_at, INTERVAL 1 HOUR)
                         AND DATE_ADD(v1.viewed_at, INTERVAL 1 HOUR)
WHERE v1.product_id = :productId
GROUP BY v2.product_id
ORDER BY co_views DESC
LIMIT 20;

Результаты кешируются в Redis на 6–24 часа. Пересчитываются агентом Битрикс ночью по всем популярным товарам.

Персонализация для авторизованного пользователя

Для авторизованных пользователей смотрим историю просмотров за последние 30 дней:

function getPersonalizedRecommendations(int $userId, int $limit = 12): array {
    // Последние просмотренные категории пользователя
    $recentCategories = getRecentUserCategories($userId, 5);

    // Товары из этих категорий, которые он ещё не смотрел
    return \CIBlockElement::GetList(
        ['CATALOG_PRICE_1' => 'ASC'],
        [
            'IBLOCK_ID'         => CATALOG_IBLOCK_ID,
            'IBLOCK_SECTION_ID' => $recentCategories,
            '!ID'               => getViewedProductIds($userId),
            'ACTIVE'            => 'Y',
        ],
        false,
        ['nPageSize' => $limit],
        ['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE']
    );
}

Административное управление рекомендациями

Система позволяет:

• Просматривать статистику кликов по рекомендациям (CTR каждого алгоритма).
• Добавлять ручные рекомендации (пинкоды) для отдельных товаров.
• Исключать товары из рекомендаций (распроданные, сезонные).
• A/B тестировать алгоритмы: половина пользователей видит content-based, половина — collaborative.

Сравнение подходов по времени и эффекту

Сроки

Итого: 2.5–3.5 недели для полной системы. Content-based рекомендации без персонализации — 1 неделя.

Что входит в работу

• Документация по API рекомендаций и схеме данных.
• Доступ к админ-панели управления рекомендациями.
• Обучение сотрудников (администрирование, A/B тесты).
• Поддержка 2 месяца после запуска (исправление ошибок, донастройка).

Как мы внедряем систему: пошаговый план

1. Анализ данных — оцениваем объём каталога, историю просмотров и покупок, определяем целевые страницы для размещения рекомендаций.
2. Выбор алгоритма — на основе анализа выбираем content-based, collaborative или гибридный подход. Для небольших магазинов часто достаточно content-based, для крупных — коллаборативная фильтрация с collaborative filtering.
3. Интеграция сбора данных — внедряем трекинг просмотров и покупок через кастомные таблицы и события Битрикс.
4. Разработка рекомендательных блоков — создаём компоненты для вывода рекомендаций на каталоге, карточке товара, в корзине.
5. Кеширование и агенты — настраиваем Redis для быстрого доступа и агенты Битрикс для ночного пересчёта.
6. A/B тестирование — запускаем тестирование разных алгоритмов для сбора статистики.
7. Деплой и обучение — развёртываем на продакшене, обучаем сотрудников работе с админ-панелью.

Закажите разработку системы рекомендаций и увеличьте продажи. Наша команда реализовала системы рекомендаций для 20+ интернет-магазинов на Битрикс. Оценим ваш проект за 1 рабочий день. Получите консультацию — свяжитесь с нами для расчёта стоимости и сроков.

Разработка и настройка модулей 1С-Битрикс

Главная ловушка Битрикса — init.php. Сунул туда обработчик OnBeforeIBlockElementUpdate, потом ещё один — через год файл на 2000 строк, и при каждом хите весь этот ком выполняется. Мы переносим бизнес-логику в полноценные модули с D7 ORM, собственными таблицами и административным интерфейсом. Модуль можно отключить, перенести на другой проект, покрыть тестами — с init.php ничего из этого не получится. Опыт команды — 10+ лет в Битрикс, сертифицированные специалисты, гарантия на код 6 месяцев. Закажите консультацию — расскажем, как перевести legacy-код в модульную архитектуру.

Почему init.php — худшее место для бизнес-логики?

Init.php не поддерживает автозагрузку классов, не имеет изолированного пространства имён, не поддаётся модульному тестированию и не отключается без правки самого файла. Каждый обработчик, написанный там, срабатывает на каждом запросе, даже если он не нужен. В модуле вы регистрируете обработчика через EventManager, и он выполняется только при наступлении события. Разница в производительности — до 3 раз при 10+ обработчиках.

Стандартные модули: типовые проблемы и решения

Информационные блоки. Архитектура ИБ — первое, что мы ревьюим на любом проекте. Классическая ошибка: один инфоблок каталога с 80 свойствами, из которых 30 — множественные. Таблица b_iblock_element_property раздувается до миллионов строк, CIBlockElement::GetList на фильтрации по трём свойствам уходит в полное сканирование. Переносим справочники в Highload-блоки, убираем множественные свойства где можно, проектируем структуру с прицелом на то, что каталог вырастет в 5 раз.

Интернет-магазин (sale). Бизнес-правила корзины — отдельная история. Настраиваем приоритеты скидок, чтобы две акции не дали 60% вместо 30%, подключаем платёжные обработчики, прописываем кастомную валидацию через OnSaleOrderBeforeSaved.

Поиск. Встроенный модуль search с морфологией работает до 10–15 тысяч элементов. Дальше — Elasticsearch. Настраиваем через API модуля поиска Битрикс, индексируем через CSearchFullText или кастомные индексаторы.

Highload-блоки для справочников, логов, пользовательских данных — вместо раздутых ИБ. Прямые запросы через Bitrix\Highloadblock\HighloadBlockTable, собственные таблицы вместо EAV-структуры стандартных инфоблоков. Миллион записей — без деградации.

Почтовые события. Настройка — не только шаблоны в b_event_message. Главное — SPF, DKIM, DMARC на DNS, иначе транзакционные письма летят в спам. Проверяем доставляемость, настраиваем bounce-обработку.

Проектирование инфоблоков для производительности

Используем Highload-блоки для справочных данных (цвета, размеры, производители), которые не участвуют в сложных выборках. Для торговых предложений — отдельный инфоблок с привязкой через IBLOCK_ELEMENT_PROPERTY. Включаем INDEX_PROPERTY для часто фильтруемых свойств. Кэширование тегированное: при изменении элемента сбрасывается только связанный кеш. Highload-блоки обрабатывают до 10 раз быстрее, чем инфоблоки с множественными свойствами, на объёмах от 100 000 записей.

Разработка кастомных модулей

Каждый модуль — по структуре /local/modules/vendor.modulename/:

• install/index.php — класс установки, создание таблиц через $DB->RunSQLBatch()
• lib/ — классы D7 ORM, наследники Bitrix\Main\ORM\Data\DataManager
• admin/ — административные страницы через CAdminList, CAdminForm
• include.php — автозагрузка, регистрация обработчиков через EventManager::getInstance()->registerEventHandler()
• REST API endpoints через \Bitrix\Rest\RestManager

Модуль регистрируется в системе, появляется в списке «Установленные решения», имеет свои настройки в /bitrix/admin/settings.php?mid=vendor.modulename. Его можно включать, отключать, обновлять через UpdateSystem или свой механизм миграций.

Примеры реализованных задач:

• Управление акциями — визуальный конструктор условий через CAdminCalendar, таймеры через агенты (CAgent::AddAgent), аналитика эффективности в связке с модулем sale
• Калькулятор стоимости — React-виджет на фронте, REST API в модуле, формулы хранятся в Highload-блоке
• Система бронирования — real-time календарь, блокировка через $DB->StartTransaction() / $DB->Commit() при одновременных запросах, синхронизация с channel manager через webhook

Компоненты и композитный кэш

Кастомизация компонентов — через result_modifier.php и component_epilog.php, не через правку template.php стандартного шаблона. Так ядро обновляется безболезненно.

Композитный кэш (технология «Композитный сайт») — сервер отдаёт готовый HTML, минуя PHP-роутинг. Динамические зоны (корзина, авторизация) подгружаются через CBitrixComponent::setFrameMode(true) и AJAX. TTFB падает до 30–50 мс. Но есть нюансы: не все компоненты совместимы, $APPLICATION->ShowPanel() ломает композит, нужна аккуратная разметка <div id="bx-composite-...">.

Маркетплейс: аудит перед установкой

Перед установкой модуля с маркетплейса — обязательный аудит. Проверяем: SQL-запросы без подготовленных выражений (привет, SQL-инъекции), прямое обращение к $_REQUEST без фильтрации, использование устаревшего API старого ядра вместо D7, конфликты с модулем композитного кэширования. Модуль без обновлений больше года и с парой десятков установок — скорее всего, проблема на ближайшем обновлении PHP. Типичный случай: модуль вызывает CIBlockElement::GetList с несброшенным кешем — сайт падает при 5000 элементов.

Миграция на D7

При обновлении PHP или переходе на новую редакцию — рефакторинг устаревших вызовов:

• CIBlockElement::GetList() → Bitrix\Iblock\Elements\ElementTable::getList()
• CSaleOrder::GetList() → Bitrix\Sale\Order::getList()
• CModule::IncludeModule() → Bitrix\Main\Loader::includeModule() Тестирование на staging, откат через git при проблемах.

Согласно официальной документации 1С-Битрикс, D7 ORM является рекомендуемым средством для работы с данными, обеспечивая безопасность типов и автогенерацию запросов.

Сравнение подходов: Init.php vs Модуль

Стоимость и состав разработки модулей

Что входит в разработку модуля?

• Техническое задание и архитектурная схема
• Код с соблюдением PSR-4 и код-стайла Битрикс
• Unit-тесты (PHPUnit) на бизнес-логику
• Интеграционные тесты на события и REST API
• Документация по установке, настройке и API
• Передача доступов к репозиторию и документации
• Обучение администраторов работе с модулем
• Гарантийная поддержка 6 месяцев

Ориентировочные сроки и сложность:

Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта.

Тестирование модулей

Unit-тесты через PHPUnit покрывают бизнес-логику: расчёт скидок, валидацию, формирование документов. Моки для Bitrix\Main\Application::getConnection() позволяют тестам не зависеть от БД. Интеграционные тесты проверяют обработчики событий на реальной базе — OnAfterIBlockElementAdd, OnSaleOrderSaved и другие. REST API endpoints тестируем через curl или PHPUnit HTTP-клиент. Критично для модулей, работающих с b_sale_order, b_catalog_price — где ошибка стоит денег.

Совместимость проверяется на PHP 7.4, 8.0, 8.1, 8.2 и редакциях: Стандарт, Малый бизнес, Бизнес. Проверяем конфликты с популярными модулями маркетплейса — они любят перехватывать те же события. Нагрузочное тестирование: замеры на 10K, 100K, 1M записей, профилирование через Xdebug на предмет утечек памяти и N+1 запросов.

Примеры из практики

Модуль акций для сети электроники. Штатные скидки модуля sale не покрывали сценарии «2+1», подарок при покупке от суммы, комбинированные условия. Собрали визуальный конструктор: маркетолог создаёт правила через drag-and-drop, без тикетов в разработку. Календарь акций, автодеактивация через агенты, аналитика в привязке к b_sale_order — конверсия, средний чек, количество применений. Время запуска новой акции упало с двух дней до получаса.

Калькулятор для строителей. Параметры (площадь, материалы, этажность) → формула → предварительная смета → заявка в CRM через CRest::call('crm.lead.add'). Региональные коэффициенты и сезонные наценки — из Highload-блока, цены материалов — из обмена с 1С. Количество целевых заявок выросло на треть: клиенты видят разбивку по статьям до звонка менеджеру.

Бронирование для сети отелей. Real-time доступность через AJAX-запросы к кастомной таблице vendor_booking_slots, расчёт тарифов по сезону, синхронизация с Booking.com через channel manager API. Блокировка номера при одновременном бронировании — через SELECT ... FOR UPDATE в транзакции. Таймзоны обрабатываются через \DateTimeZone — гость из Владивостока и менеджер из Москвы видят одну картину.

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