Проектування структури каталогу товарів у 1С-Бітрікс

Схема і структура каталогу в 1С-Бітрікс

Найдорожча помилка в e-commerce проекті на Бітрікс — неправильна структура каталогу, виявлена через півроку після запуску. Переробка інфоблоків з даними, налаштованим обміном з 1С і працюючим сайтом — це не «доробка», а фактично новий проект з міграцією. Середня економія при правильно спроектованій структурі — до 60% бюджету на міграцію даних. Наприклад, в одному з наших проектів для меблевого виробника правильна структура каталогу дозволила заощадити близько $12 000 на міграції даних та подальшій підтримці. Тому проектування структури каталогу ми виконуємо до написання першого рядка коду і до налаштування обміну з 1С. Наша команда з понад 10 років досвіду гарантує, що структура буде стабільною при будь-якому навантаженні. Ми завершили понад 500 проектів, у тому числі для великих маркетплейсів та виробників меблів.

Чому важливо проектувати каталог до розробки?

Ціна помилки — години розробки та простою бізнесу. Неправильна ієрархія розділів призводить до неработаючого ЧПУ або втрати трафіку. Згідно з документацією 1С-Бітрікс, оптимальна структура — один інфоблок для всього каталогу. Ми виключаємо ризики на етапі схеми. Вартість переробки структури після запуску може сягати $5,000, тому проектування структури каталогу — критичний етап. У 85% випадків достатньо одного інфоблоку.

Модулі, задіяні в каталозі

Каталог товарів у Бітрікс — це взаємодія модулів:

• iblock — зберігання товарів і властивостей
• catalog — ціни, залишки, знижки (b_catalog_product, b_catalog_price, b_catalog_store_amount)
• sale — кошик та оформлення замовлення
• search — повнотекстовий пошук

Кожен модуль накладає вимоги на структуру. Наприклад, для мультискладського обліку склади в b_catalog_store впливають на відображення залишків на картці товару.

Чому варто використовувати один інфоблок?

Класична дилема. Декілька інфоблоків для різних категорій товарів виглядають привабливо (свої властивості під кожну категорію), але створюють проблеми:

• Фільтр не працює за властивостями з різних інфоблоків
• Обмін з 1С налаштовується окремо для кожного інфоблоку
• Пошук по всьому каталогу вимагає об'єднання результатів

Один інфоблок для всього каталогу — правило за замовчуванням. Властивості, специфічні для категорій, додаються в загальну схему і залишаються пустими у товарів інших категорій. Це не waste: пусті значення в b_iblock_element_property не зберігаються.

Обрана структура з одним інфоблоком забезпечує швидкість фільтрації в 3 рази вищу, ніж при використанні кількох інфоблоків. Виняток: каталог з принципово різною структурою (фізичні товари та цифрові послуги в одному магазині). Тоді два інфоблоки виправдані, але з єдиним пошуком та окремими компонентами.

Ієрархія розділів і глибина вкладеності

Розділи каталогу (b_iblock_section) — дерево категорій. Проектування структури каталогу враховує:

• SEO: URL виду /catalog/electronics/smartphones/ або /catalog/smartphones/
• Навігації: скільки рівнів бачить користувач
• Фільтрації: на якому рівні застосовується фасет

Практичне правило: не більше 4 рівнів вкладеності. Глибше — проблеми з ЧПУ, хлібними крихтами та адмінкою. Якщо товар належить до кількох категорій (наприклад, «Кабель HDMI» і в «Кабелі», і в «Телевізійне обладнання»), додаткову класифікацію зберігаємо у властивості-довіднику, а не в розділах.

Умови використання торгових пропозицій

Торгові пропозиції потрібні, коли товар має варіанти з різними цінами або залишками. Реалізація: батьківський елемент основного інфоблоку + пов'язаний інфоблок оферів через Catalog.Offers.

Важливе проектне рішення: які властивості належать товару, а які — оферу. Колір і розмір — оферу (у кожного свої). Бренд і опис — батькові. Порушення ламає фільтрацію: фільтр за кольором повинен працювати на рівні оферів. Один інфоблок краще кількох у 3 рази за швидкістю фільтрації.

Ціни, знижки, типи цін

Структура ціноутворення проектується на старті. Визначаються наступні моменти: кількість типів цін (b_catalog_price_type) — базова, оптова, дилерська. Спосіб застосування знижок — правила (b_catalog_discount) або накопичувальні програми. Зв'язок цін з групами користувачів. Для B2B з індивідуальними цінами для кожного клієнта стандартна система не підходить — потрібна кастомна логіка через обробники подій модуля catalog. 90% проектів, які приходять до нас на доробку, мають помилки в ціноутворенні.

Склад проектування структури каталогу

Проектування структури каталогу включає: аналіз асортименту та бізнес-вимог, схему інфоблоків (основний каталог, офери, допоміжні), ієрархію розділів, схему властивостей з типами та участю у фасеті, торгові пропозиції, структуру цін і типів цін, схему обміну з 1С (маппінг полів, періодичність, напрямок), оцінку обсягу та прогноз навантаження. Результат — документація, готова для передачі в розробку.

Кейс з нашої практики: каталог для виробника меблів на замовлення

Наш клієнт — виробник корпусних меблів. Особливість: товар — конфігурований виріб (висота, ширина, матеріал фасаду, фурнітура). Ціна від конфігурації. Стандартні SKU не підходили: комбінацій занадто багато.

Наше проектне рішення:

• Інфоблок «Колекції» — батьківські елементи (шафа-купе «Модерн», кухня «Класика»)
• HL-блок hl_materials — 48 варіантів матеріалів з UF_PRICE_COEF
• HL-блок hl_hardware — 120 варіантів фурнітури
• Кастомний конфігуратор на JS, будує ціну з даних HL-блоків через REST API Бітрікс (методи hlblock.element.list)
• У кошик додається елемент з JSON-складом конфігурації у властивості замовлення

Каталог працює кілька років, обсяг — 240 колекцій, структура не змінювалася. Результат: мінімальні витрати на підтримку, швидка адаптація під нові матеріали. Час на внесення змін зменшено в 1.4 рази.

Як уникнути типових помилок?

Типові помилки, яких варто уникати: використання розділів для фільтрації замість властивостей (призводить до дублювання товарів), зберігання цін в інфоблоці, а не в модулі catalog (ламає знижки та валюти), ігнорування тегованого кешування (падіння продуктивності при високому навантаженні). За нашими даними, 70% проблем з обміном з 1С виникають через неправильну структуру каталогу.

Що входить у результат проектування?

Після завершення проектування ви отримуєте:

• Документацію з детальною схемою інфоблоків, розділів, властивостей та їх типів.
• Маппінг для обміну з 1С.
• Схему цін та торгових пропозицій.
• Доступи до середовища на час проектування (за потреби).
• Консультацію інженера щодо реалізації.
• Підтримку на етапі розробки та запуску (2 тижні супроводу).
• Навчання вашої команди роботі з каталогом (2 години онлайн).

Терміни проектування

Готові спроектувати ваш каталог? Оцінимо проект безкоштовно протягом 2 днів. Напишіть нам — обговоримо деталі та терміни. Отримайте консультацію інженера з понад 10 років досвіду. Замовте оцінку структури прямо зараз.