Блок спільних покупок на 1С-Бітрікс: розробка та інтеграція

Пустота на картці товару або блок «схожі» за властивостями — конверсія падає. Покупець не бачить цінності: товари зі схожими характеристиками не відображають реальну поведінку. Блок спільних покупок вирішує завдання інакше — він спирається на статистику замовлень. Такий підхід дає в 2–3 рази більше кліків і на 15–30% збільшує середній чек. Ми реалізували його на 1С-Бітрікс для десятків проєктів — від каталогів у 500 товарів до маркетплейсів із мільйоном позицій. Рішення підходить для будь-якої редакції: «Малий бізнес», «Бізнес» або «Ентерпрайз». Хочете оцінити ефект на своєму каталозі? Зв'яжіться з нами — покажемо демо.

Як працює блок «з цим товаром купують»?

Логіка: для кожного товару A знаходимо всі замовлення, де він куплений, і дивимося, які інші товари зустрічаються в тих самих замовленнях. Чим частіше пара зустрічається — тим вищий recommendation score. Ми використовуємо поріг у 3 спільні покупки за останні 90 днів, щоб відсікти випадкові збіги.

Джерела даних і SQL

Основна інформація лежить у таблицях b_sale_order (замовлення) та b_sale_basket (позиції). Запит збирає товари, куплені разом, за останні 90 днів — цього достатньо, щоб асортиментні зміни швидко відображалися.

SELECT b2.product_id AS recommended_id, COUNT(DISTINCT b2.order_id) AS co_purchase_count FROM b_sale_basket b1 JOIN b_sale_order o ON b1.order_id = o.id AND o.canceled = 'N' AND o.status_id NOT IN ('F') JOIN b_sale_basket b2 ON b1.order_id = b2.order_id AND b2.product_id != b1.product_id AND b2.product_id IS NOT NULL WHERE b1.product_id = :productId AND o.date_insert >= DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY b2.product_id HAVING co_purchase_count >= 3 ORDER BY co_purchase_count DESC LIMIT 20; 

Результати зберігаються в окрему таблицю custom_co_purchases із первинним ключем (product_id, recommended_id). Це дозволяє робити швидкий lookup без важких запитів щоразу. Детальніше про структуру таблиць модуля sale можна дізнатися в документації Бітрікс.

Попередній розрахунок через агент

Запускати такий SQL при кожному перегляді картки — вбивчо для продуктивності. Тому ми робимо попередній розрахунок для топ-500 товарів за допомогою агента, який запускається вночі.

// Агент в local/php_interface/init.php function RecalcCoPurchasesAgent(): string { $topProducts = getTopSellingProducts(500); foreach ($topProducts as $productId) { $recs = calcCoPurchases($productId); saveToCoPurchases($productId, $recs); } return 'RecalcCoPurchasesAgent();'; } 

Агент перераховує дані раз на добу. Для не топових товарів використовуємо fallback.

Компонент із тегованим кешуванням

Виведення блоку реалізовано через компонент company:catalog.co_purchases. Компонент використовує тегований кеш, щоб сторінки карток не перераховувалися при кожному відкритті. Кеш прив'язується до тегу co_purchases, що дозволяє скидати його при зміні замовлень.

// component.php if (!\Bitrix\Main\Loader::includeModule('iblock') || !\Bitrix\Main\Loader::includeModule('catalog')) { return; } $productId = (int)$arParams['PRODUCT_ID']; $limit = (int)($arParams['LIMIT'] ?? 8); $cache = \Bitrix\Main\Data\Cache::createInstance(); if ($cache->initCache(3600, "co_purchases_{$productId}_{$limit}", '/co_purchases')) { $arResult = $cache->getVars(); } elseif ($cache->startDataCache()) { $cache->registerTag('co_purchases'); $recommendedIds = getFromCoPurchasesTable($productId, $limit); $arResult = getProductsByIds($recommendedIds); $cache->endDataCache($arResult); } $this->IncludeComponentTemplate(); 

Фільтрація та cold start

Перед відображенням рекомендації проходять фільтр: лише активні товари з ненульовим залишком. Якщо для товару мало даних (новий товар або магазин щойно запущено), використовуємо content-based fallback — показуємо товари з тієї ж категорії. Це вирішує проблему cold start.

function getRecommendations(int $productId, int $limit): array { $coPurchases = getFromCoPurchasesTable($productId, $limit); if (count($coPurchases) >= $limit) { return $coPurchases; } $needed = $limit - count($coPurchases); $exclude = array_merge([$productId], $coPurchases); $categoryFill = getSameCategoryProducts($productId, $needed, $exclude); return array_merge($coPurchases, $categoryFill); } 

Блок у кошику

Цей же механізм можна застосувати для кошика: показати «до товарів у вашому кошику часто купують». Беремо всі товари з кошика, збираємо їхні рекомендації, підсумовуємо score та виключаємо вже додані.

$basketItems = \Bitrix\Sale\Basket::loadItemsForFUser(\Bitrix\Sale\Fuser::getId()); $basketIds = []; foreach ($basketItems as $item) { $basketIds[] = $item->getProductId(); } $allRecs = []; foreach ($basketIds as $id) { $recs = getFromCoPurchasesTable($id, 20); foreach ($recs as $rec) { $allRecs[$rec['recommended_id']] = ($allRecs[$rec['recommended_id']] ?? 0) + $rec['score']; } } foreach ($basketIds as $id) unset($allRecs[$id]); arsort($allRecs); $topRecs = array_slice(array_keys($allRecs), 0, 8); 

Чому спільні покупки ефективніші за схожі товари?

Порівняння підходів у таблиці нижче. Блок спільних покупок спирається на реальну поведінку покупців, а не на формальні властивості. Ми гарантуємо стабільну роботу на будь-яких версіях Бітрікс (починаючи з 17.0) та надаємо гарантію на код.

Рекомендуємо проводити A/B тест: на половині трафіку показувати спільні покупки, на іншій — стандартні рекомендації. У 80% проєктів блок спільних покупок виграє за CTR на 30–50%.

Що входить у роботу?

1. Аналіз поточних замовлень та структури даних
2. SQL-запит з оптимізацією під ваш обсяг
3. Розробка агента попереднього розрахунку
4. Компонент із кешуванням та fallback
5. Інтеграція блоку в кошик
6. Документація з розгортання та налаштування
7. Консультації після релізу

Строки розробки

Приклад розрахунку: при збільшенні середнього чека на 20% додатковий виторг з кожних 1000 відвідувачів суттєво зростає. За рік на трафіку 10 000 відвідувачів на місяць це дає значний приріст.

Замовте розробку блоку «з цим товаром купують» — отримайте готовий компонент з документацією та консультацію після релізу. Зв'яжіться з нами для оцінки вашого проєкту.