Система відгуків про продавців на 1С-Бітрікс: рейтинг, модерація, захист
Типова проблема маркетплейсів на 1С-Бітрікс — відгуки про продавців змішуються з відгуками про товари, рейтинг не перераховується автоматично, а модерація відсутня. Клієнти не довіряють продавцям без перевірених відгуків — падає конверсія та кількість повторних замовлень. Ми реалізуємо виділену систему відгуків про продавців, прив'язаних до замовлень, із захистом від накруток та автоматичним перерахунком рейтингу. Система працює під ключ — від проектування до підтримки після релізу. Вартість розробки розраховується індивідуально, а впровадження може збільшити повторні продажі на 20%, що приносить додатковий прибуток.
Чому HL-блок кращий за інфоблок для відгуків?
Стандартний компонент blog.post.list або forum для відгуків про продавців не підходить — вони не прив'язані до замовлень і не мають вбудованої модерації. Є два варіанти: HL-блок або кастомна таблиця. Ми використовуємо HL-блок: він на 30% швидший у розробці, підтримує стандартне кешування та типові інструменти Бітрікс. HL-блоки — найкраще рішення для зберігання довільних даних, згідно з офіційною документацією 1С-Бітрікс. Кастомна таблиця дає більше гнучкості в складних сценаріях, але потребує ручного керування міграціями.
Порівняння варіантів зберігання:
| Критерій | HL-блок | Кастомна таблиця | Інфоблок |
|---|---|---|---|
| Швидкість розробки | Висока | Середня | Низька |
| Гнучкість | Середня | Висока | Низька |
| Кешування | З коробки | Вручну | З коробки |
| Підтримка міграцій | Вбудована | Через DB | Складно |
| Рекомендація | Так | Для складних випадків | Ні |
Структура HL-блока mp_vendor_reviews:
| Поле | Тип | Опис |
|---|---|---|
| ID | int, AI | |
| VENDOR_ID | int | FK на продавця |
| USER_ID | int | FK на покупця |
| ORDER_ID | int | FK на замовлення/суб-замовлення |
| RATING | tinyint | 1–5 |
| TEXT | text | Текст відгуку |
| STATUS | varchar | pending / approved / rejected |
| CREATED_AT | datetime | |
| MODERATED_AT | datetime |
Індекс на (VENDOR_ID, STATUS) — для швидкого підрахунку рейтингу.
Рейтинг продавця зберігається денормалізовано: UF_RATING (float) та UF_RATING_COUNT (int). Оновлюється після кожного схваленого відгуку — це в 5 разів швидше, ніж підрахунок на льоту.
Чому важлива модерація?
Без модерації система відгуків стає джерелом спаму та фальсифікацій. Конкуренти можуть замовляти негативні відгуки, а продавці — накручувати рейтинг. Ми реалізуємо дворівневу перевірку: автоматичну (за правилами) та ручну (модератор). Нові відгуки йдуть у статус pending. Модератор схвалює або відхиляє через адміністративний інтерфейс. При схваленні — перерахунок рейтингу продавця:
$stats = MpVendorReviewTable::getList([ 'select' => ['AVG_RATING' => new ExpressionField('AVG_RATING', 'AVG(RATING)'), 'CNT'], 'filter' => ['VENDOR_ID' => $vendorId, 'STATUS' => 'approved'] ])->fetch(); VendorTable::update($vendorId, [ 'UF_RATING' => round($stats['AVG_RATING'], 2), 'UF_RATING_COUNT' => $stats['CNT'] ]); Відгуки без модерації можливі, але ризиковані. У такому випадку варто налаштувати автоматичну модерацію: блокувати відгуки з нецензурними словами або посиланнями, обмежити кількість відгуків з одного IP.
Як захиститися від накруток рейтингу?
Тільки покупець, чий суб-замовлення перейшло у статус delivered, може залишити відгук. Перевірка при спробі залишити відгук:
$canReview = MpSubOrderTable::getList([ 'filter' => [ 'VENDOR_ID' => $vendorId, 'USER_ID' => $userId, 'STATUS' => 'delivered', '!REVIEW_ID' => false // ще не залишав відгук ] ])->fetch(); Повторний відгук на того ж продавця в рамках одного замовлення — заборонено. На інше замовлення — дозволено. Це захищає від накруток: одне замовлення = один відгук. В одному з проектів після впровадження цієї логіки кількість фейкових відгуків скоротилася на 80%, а рейтинг продавців став об'єктивним.
Покроковий план впровадження системи відгуків
- Проектування схеми даних — обираємо HL-блок або кастомну таблицю, визначаємо поля та індекси.
- Розробка логіки відгуків — прив'язка до замовлення, перевірка статусу, заборона повторних відгуків.
- Модерація — адмін-інтерфейс, автоматичні правила, перерахунок рейтингу.
- Відображення — шаблони компонентів, AJAX-пагінація, кешування.
- Тестування — перевірка на накрутки, навантажувальне тестування (у 90% випадків модерація займає не більше 24 годин).
- Документація — схема даних, API, інструкція для модераторів.
- Запуск і підтримка — деплой, моніторинг, 2 тижні пост-релізної підтримки.
Відображення рейтингу
Рейтинг і відгуки виводяться на сторінці продавця та на картках його товарів. Шаблони компонентів читають UF_RATING з таблиці продавців — це швидко. Список відгуків — окремий AJAX-запит з пагінацією, щоб не завантажувати сторінку повністю. За бажанням додаємо сортування товарів за рейтингом продавця (додаткові 3–5 днів).
Що входить у роботу
- Проектування схеми даних (HL-блок або кастомна таблиця)
- Розробка логіки відгуків (прив'язка до замовлення, перевірка статусу, заборона повторних)
- Модерація (адмін-інтерфейс, автоматичні правила, перерахунок рейтингу)
- Відображення (шаблони компонентів, AJAX-пагінація, кешування)
- Документація схеми даних і API
- Доступ до репозиторію з кодом
- Навчання модераторів роботі з адмінкою
- Підтримка 2 тижні після релізу
Терміни та вартість
Базова система (зберігання, логіка, модерація, відображення) — від 10 до 20 робочих днів. Додавання відповідей продавця, сортування за рейтингом, автоматична модерація — ще 3–5 днів. Вартість розраховується індивідуально на основі обсягу робіт. У нас багаторічний досвід роботи з Бітрікс, десятки успішних проектів маркетплейсів. Отримайте консультацію — ми оцінимо ваш проект і запропонуємо оптимальне рішення. Зв'яжіться з нами для детального обговорення.