Розробка системи рейтингу продавців маркетплейсу

Розробка системи рейтингу продавців маркетплейсу

На маркетплейсі з 10 000 продавців і сотнями відгуків на день просте середнє арифметичне не працює: пара фейкових відгуків спотворює реальну картину. Тому ми розробляємо систему рейтингу, яка враховує не лише зірки, а й об’єктивні метрики виконання замовлень — відсоток доставок, швидкість обробки, скасування та повернення. Покупці приймають рішення за секунди: товар у продавця з рейтингом 4.8 продається значно краще, ніж той самий товар у продавця з 4.0. Якщо рейтинг не відображає реальність, довіра падає. Наша мета — дати чесний і прозорий механізм, що стимулює якісну роботу та захищає платформу від маніпуляцій. В основі — багатофакторна модель з різними вагами та ковзне вікно в 90 днів.

Складові рейтингу

Рейтинг не повинен зводитися лише до зірочок відгуків. Якісна система враховує кілька параметрів:

Підсумковий рейтинг — зважена сума нормалізованих показників, приведена до шкали 1–5. Кожен параметр нормалізується за формулою Z-оцінки або min-max. Це дозволяє враховувати різну природу метрик і уникнути домінування одного фактора. Такий підхід більш стабільний і менш схильний до маніпуляцій, ніж просте середнє.

Збір відгуків: процес і правила

Відгук можна залишити лише після підтвердження отримання замовлення. Це виключає відгуки від несправжніх покупців. Форма відгуку:

• Загальна оцінка (1–5 зірок)
• Оцінки за параметрами: відповідність опису, упаковка, швидкість відправки
• Текст (опціонально, з мінімальною довжиною)
• Фото до відгуку (завантаження через S3)

Нагадування про відгук: push/email через 3 дні після доставки, повторне через 7 днів.

Модерація відгуків

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

Чому ми використовуємо ковзне вікно?

Рейтинг перераховується не в реальному часі (дорого), а за розкладом:

• Раз на годину для активних продавців (>10 замовлень за 30 днів)
• Раз на добу для решти

SELECT
  seller_id,
  AVG(rating) as avg_rating,
  COUNT(*) as reviews_count,
  AVG(CASE WHEN status='delivered' THEN 1.0 ELSE 0.0 END) as delivery_rate
FROM orders
WHERE created_at >= now() - interval '90 days'
GROUP BY seller_id

Рейтинг розраховується ковзним: враховуються лише останні 90 днів. Це захищає від «гниючого» минулого та стимулює підтримувати якість.

Які наслідки низького рейтингу?

• Рейтинг < 4.0 — попередження в кабінеті, товари нижче у видачі
• Рейтинг < 3.5 протягом 30 днів — обмеження нових замовлень, повідомлення команди підтримки
• Рейтинг < 3.0 — автоматичне призупинення акаунту до розбору ситуації

Це мотивує продавців виправлятися, а не працювати з поганим рейтингом роками.

Процес розробки системи рейтингу

1. Аналітика — збір вимог, аналіз поточних метрик і архітектури.
2. Проєктування моделі — розрахунок ваг, нормалізація, логіка перерахунку.
3. Розробка API — створення ендпоінтів для відгуків, оцінок і модерації.
4. Панель адміністрування — інтерфейс для модераторів і менеджерів.
5. Інтеграція з чергами — обробка фонових завдань через Redis/Beanstalkd.
6. Тестування та документація — навантажувальне тестування, Swagger/OpenAPI.
7. Розгортання — на вашому сервері або в хмарі.

Ми гарантуємо, що система витримає навантаження до 100 000 відгуків на день без деградації. Для пікових навантажень (після розпродажів) використовується черга завдань на Redis і горизонтальне масштабування worker-ів. Досвід команди — понад 5 років, реалізовано 12 великих проєктів.

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

Розробка включає: проєктування моделі, API для відгуків і модерації, панель адміністрування, інтеграцію з чергами, навантажувальне тестування, документацію (Swagger/OpenAPI), навчання вашої команди, розгортання на вашому сервері або в хмарі, а також підтримку протягом місяця після запуску.

Порівняння підходів: просте середнє vs зважене

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

Докладніше про принципи репутаційних систем можна прочитати в Wikipedia.

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

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

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

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

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

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.