Розробка мультибрендової вітрини на 1С-Bitrix
Мультибрендова вітрина — це магазин, де кілька торгових марок представлені як окремі «міні-шопи» всередині однієї платформи. Покупець бачить розділ Nike, розділ Adidas, розділ Puma — кожен зі своїм візуальним стилем, своїми банерами та своєю навігацією. Але кошик, оформлення замовлення та акаунт користувача спільні. Це не просто категорії каталогу — це окремі простори всередині одного сайту.
Архітектура зберігання даних
Каталог мультибрендової вітрини будується на базі інфоблока каталогу Bitrix з ієрархією розділів. Структура:
b_iblock_section (каталог)
├── BRAND_ID: 1 (Nike)
│ ├── Кросівки
│ ├── Одяг
│ └── Аксесуари
├── BRAND_ID: 2 (Adidas)
│ ├── Кросівки
│ └── Одяг
Бренд — це верхній рівень розділу або окремий інфоблок брендів із прив'язкою до товарів. Другий варіант гнучкіший: один інфоблок «Бренди» містить метадані бренду (логотип, кольори, опис, банери), а кожен товар інфоблока каталогу має властивість BRAND_ID типу «Елемент».
Інфоблок «Бренди» (IBLOCK_BRANDS):
-
LOGO— SVG або PNG логотип -
BANNER_DESKTOP,BANNER_MOBILE— банери розділу бренду -
PRIMARY_COLOR,ACCENT_COLOR— кольори для CSS-змінних -
DESCRIPTION— історія бренду -
BRAND_URL— офіційний сайт -
OFFICIAL_DEALER— статус авторизованого дилера (прапорець)
Динамічний брендинг розділу
Коли користувач відкриває розділ бренду, шаблон змінює кольори, шапку та банер. Це реалізується через CSS-змінні, які генеруються на PHP та підставляються в <head>:
// В template.php розділу бренду
$brandId = $arResult['SECTION']['UF_BRAND_ID']; // кастомне поле розділу
$brand = BrandTable::getByPrimary($brandId)->fetch();
if ($brand) {
$APPLICATION->SetAdditionalCSS('
:root {
--brand-primary: ' . htmlspecialchars($brand['PRIMARY_COLOR']) . ';
--brand-accent: ' . htmlspecialchars($brand['ACCENT_COLOR']) . ';
}
');
}
Логотип бренду в шапці сторінки розділу підставляється замість основного логотипу сайту. В інших розділах — звичайний логотип. Це робиться через глобальну змінну в шаблоні:
// В header.php шаблону
global $currentBrand;
echo $currentBrand
? '<img src="' . $currentBrand['LOGO_URL'] . '" alt="' . $currentBrand['NAME'] . '">'
: '<img src="/local/templates/main/img/logo.svg" alt="Магазин">';
Фільтрація та навігація за брендом
Всередині розділу бренду фільтр каталогу працює тільки в рамках товарів даного бренду. Стандартний компонент розумного фільтра bitrix:catalog.smart.filter потрібно параметризувати:
$APPLICATION->IncludeComponent('bitrix:catalog.smart.filter', '', [
'IBLOCK_ID' => CATALOG_IBLOCK_ID,
'SECTION_ID' => $brandSectionId, // кореневий розділ бренду
'DEPTH_LEVEL' => 5, // вкладені підрозділи бренду
'HIDE_NOT_SELECTED' => 'Y',
// ...
]);
Розумний фільтр розраховує доступні значення (b_catalog_smart_filter) тільки для товарів зазначеного розділу — це коректно працює «з коробки».
Хлібні крихти показують шлях: «Головна → Nike → Кросівки». Компонент bitrix:breadcrumb працює автоматично при правильній структурі розділів.
Сторінка бренду: лендинг + каталог
Сторінка бренду — це не просто список товарів. Це вітрина з: банером бренду, історією марки, ключовими колекціями, новинками, хітами продажів.
Компонування сторінки бренду через $APPLICATION->IncludeComponent():
// brand.php — окремий шаблон сторінки
IncludeComponent('custom:brand.page', '', ['BRAND_ID' => $brandId]);
// Всередині компонента:
// - Банер бренду
// - Блок "Про бренд" із DESCRIPTION
// - Компонент catalog.section зі списком товарів
// - Блок новинок (фільтр за датою додавання)
// - Блок хітів (фільтр за кількістю продажів)
Порівняння товарів між брендами
Стандартний компонент порівняння bitrix:catalog.compare.buy працює в рамках одного інфоблока. Для мультибрендової вітрини порівняння повинно працювати між брендами при схожих характеристиках (наприклад, кросівки Nike vs Adidas vs Puma).
Технічно це реалізовується: список порівнюваних товарів зберігається в сесії, характеристики беруться з властивостей інфоблока. Складність — різні бренди можуть мати різний набір характеристик. Рішення: фіксований набір «загальних» властивостей для порівняння (матеріал верху, тип підошви, тип колодки), окремо — унікальні властивості кожного бренду.
Управління контентом брендових розділів
Якщо у кожного бренду є свій менеджер, потрібне розмежування прав:
// Група "Менеджер бренду Nike" має права тільки на елементи з BRAND_ID = 1
// Налаштовується через права доступу до інфоблока на рівні розділів
CIBlock::SetPermission(CATALOG_IBLOCK_ID, $nikeSectionId, $nikeManagerGroupId, 'W');
Стандартне розмежування прав Bitrix дозволяє давати доступ на рівні розділів інфоблока — менеджер Nike бачить і редагує тільки товари в розділі Nike.
Аналітика за брендами
Власникам вітрини потрібна розбивка продажів і трафіку за брендами:
-
Трафік: події сторінок за брендом передаються до Яндекс.Метрики через
dataLayerз параметромbrand_id -
Продажі: поле
BRAND_IDзаписується у властивості позицій замовлення (b_sale_order_props), агрегація через SQL - Конверсія: воронка за брендом у BI-інструменті (ClickHouse + Metabase або Power BI)
SEO мультибрендової вітрини
Кожен бренд — потенційна точка входу з пошуку. Сторінка бренду повинна оптимізуватися під запити типу «купити Nike у Києві»:
- SEO-опис розділу бренду в
b_iblock_section.DESCRIPTION - Окремі
META_TITLEтаMETA_DESCRIPTIONдля сторінки бренду - Розмітка
BreadcrumbListSchema.org - Canonical на сторінку бренду при фільтрації
Терміни
| Масштаб | Що входить | Термін |
|---|---|---|
| 3–5 брендів, базовий брендинг | Структура розділів, сторінки брендів, фільтр | 3–5 тижнів |
| 5–20 брендів | + динамічні кольори, ЛК бренд-менеджерів, аналітика | 6–10 тижнів |
| 20+ брендів, маркетплейс | + кабінет партнера, фінансовий розрахунок, API | 12–20 тижнів |
Мультибрендова вітрина ускладнює каталог, але створює конкурентну перевагу: покупець приходить не за конкретним товаром, а в «місце», де порівнюють кілька брендів одного типу продукту.