Уявіть: продавці вивантажують до 10 000 товарів на день на маркетплейсі на 1С-Бітрікс. Без системи модерації — дублікати (до 30%), товари без фото, ціни «0 гривень», заборонені категорії. Стандартний модуль Інтернет-магазину не надає гнучких статусів — тільки активність товару (Y/N). Для повноцінного маркетплейсу потрібне розширення з кастомними UF-полями, подіями та автоматичними перевірками. Ми автоматизуємо процес так, щоб 80% перевірок виконувалися без участі людини, а продавець бачив статус в особистому кабінеті та отримував сповіщення про причини відмови. Наш досвід — понад 7 років розробки на 1С-Бітрікс, 50+ проєктів, сертифіковані спеціалісти. Розглянемо детально: які статуси використовувати, як налаштувати обробники подій, які перевірки впровадити для зниження навантаження на модераторів.
Статусна модель модерації
Кожен товар в інфоблоці отримує UF-поле статусу модерації: UF_MODERATION_STATUS (тип — рядок або довідник). Значення:
-
draft— продавець не надіслав на перевірку -
pending— очікує перевірки модератором -
approved— схвалено, товар активний (ACTIVE = Y) -
rejected— відхилено із зазначенням причини -
revision— потрібні правки (м'яка відмова)
При додаванні товару продавцем встановлюється ACTIVE = N, UF_MODERATION_STATUS = 'pending'. Обробник події OnAfterIBlockElementAdd фіксує час надсилання та створює сповіщення для модераторів. Якщо потрібна асинхронна обробка, використовуємо агента з CAgent::AddAgent().
Приклад обробника:
AddEventHandler("iblock", "OnAfterIBlockElementAdd", function(&$arFields) { if ($arFields["IBLOCK_ID"] == CATALOG_IBLOCK_ID) { CIBlockElement::SetPropertyValuesEx($arFields["ID"], CATALOG_IBLOCK_ID, array( "UF_MODERATION_STATUS" => "pending" )); // сповіщення модераторам CEvent::Send("MODERATION_NEW_ITEM", SITE_ID, array( "ITEM_ID" => $arFields["ID"], "NAME" => $arFields["NAME"] )); } }); Чому автоматичні перевірки критичні?
Ручна модерація кожного товару — вузьке місце. Ми впроваджуємо автоматичні перевірки, які працюють в 3 рази швидше та допускають менше 1% помилок (проти 5-10% вручну). Продавець отримує миттєву відповідь та може виправити помилки без очікування модератора.
| Тип перевірки | Що перевіряємо | Результат при помилці |
|---|---|---|
| Наявність зображень | Мінімум 1 фото (PREVIEW_PICTURE або DETAIL_PICTURE) | Статус auto_rejected з причиною |
| Обов'язкові властивості | Ціна, опис, категорія | Статус auto_rejected із зазначенням поля |
| Дублікати за артикулом | PROPERTY_ARTICLE серед активних | Статус auto_rejected — товар існує |
| Заборонені символи | Наявність <script>, <?php |
Статус auto_rejected — потенційна XSS-вразливість |
Додатково можна перевіряти відповідність вимогам категорії (наприклад, обов'язкова властивість "Бренд" для електроніки). Автоматична перевірка скорочує час модерації до 0.1 секунди на товар.
Які перевірки варто автоматизувати?
Крім базових перевірок, описаних вище, варто автоматизувати:
- Валідацію ціни: не менше мінімального порогу та не більше максимального.
- Перевірку унікальності назви в межах категорії.
- Фільтрацію нецензурних слів в описі.
- Відповідність зображень формату та розміру (наприклад, JPEG, не більше 2 МБ).
Кожна перевірка реалізується як окремий клас-обробник, який запускається після додавання або оновлення товару. Це спрощує додавання нових правил без зміни ядра.
Як налаштувати сповіщення продавців?
Використовуємо подійну модель Бітрікс: CEvent::Send() з шаблонами поштових подій. При схваленні — лист з активним посиланням на товар. При відмові — причина та список помилок. Можна додати сповіщення через SMS або месенджери через REST API. Також налаштовуємо сповіщення в особистому кабінеті продавця: статус товару оновлюється в реальному часі через BX.Pull.
Приклад: продавець додає товар, через 1 секунду отримує листа "Товар очікує модерації". Після перевірки — другий лист "Товар схвалено" або "Товар відхилено: відсутня ціна". Такий підхід знижує кількість звернень до підтримки.
Покрокове налаштування модерації
- Створити UF-поле
UF_MODERATION_STATUSдля інфоблоку каталогу. - Написати обробник
OnAfterIBlockElementAddдля встановлення статусуpendingтаACTIVE=N. - Розробити автоматичні перевірки у вигляді агента або обробника
OnBeforeIBlockElementUpdate. - Налаштувати поштові події та шаблони для сповіщень.
- Реалізувати інтерфейс модератора: черга товарів з фільтрацією за статусом, кнопки "Схвалити", "Відхилити", "Запросити правки".
Що входить у налаштування під ключ?
Ми надаємо повний цикл робіт:
- Проектування статусної моделі під ваш каталог з урахуванням номенклатури та категорій
- Розробка інтерфейсу модератора (черга, картка товару, історія рішень)
- Система сповіщень продавців (пошта, особистий кабінет, опціонально SMS через REST API)
- Автоматичні перевірки (зображення, обов'язкові поля, дублікати, безпека)
- Інтеграція з REST API для обміну даними із зовнішніми системами
- Документація з налаштування та інструкції для модераторів
- Навчання команди (2 години онлайн)
- Підтримка 2 тижні після запуску
Результати впровадження: зниження навантаження на модераторів на 70%, прискорення публікації товарів у 5 разів. Ми даємо гарантію на стабільну роботу: всі статуси коректно оновлюються, сповіщення доставляються, дублікати блокуються. Досвід 7+ років та 50+ проєктів дозволяє передбачити типові проблеми. Офіційна документація Бітрікс з подій підтверджує надійність такого підходу.
Для оцінки вашого проєкту зв'яжіться з нами — отримайте консультацію інженера. Ми розрахуємо вартість та терміни індивідуально.