Розробка дошки оголошень (Classifieds) під ключ

Розробка дошки оголошень (Classifieds)

Припустимо, ви запускаєте класифайд для продажу вживаних авто. За місяць ви виявляєте: пошук за маркою та моделлю не фільтрує детально (немає року випуску, пробігу), модератори вручну перевіряють кожне оголошення, а покупці скаржаться, що не бачать оголошень поруч із собою. Знайома ситуація? Ми будуємо класифайди, в яких геопошук працює за мілісекунди, модерація відсікає 90% сміття автоматично, а монетизація окупає розробку за пів року. Наші замовники — від нішевих барахолок до федеральних дошок оголошень із мільйонами лістингів. Розробка дошки оголошень — комплексне завдання, що потребує збалансованих рішень. У цій статті розберемо, як побудувати класифайд, який не гальмує при мільйоні оголошень, модерується сам і приносить прибуток. Розглянемо ключові технічні рішення: динамічні атрибути, геопошук, месенджер, модерацію та ескроу.

Що важливо при розробці дошки оголошень?

Почнемо з архітектури. Кожне оголошення містить мінімум: тип угоди, заголовок, опис, категорію, ціну, фото, контакти, локацію та термін активності. Але головна фішка — динамічні атрибути. Для авто — марка, модель, рік; для нерухомості — площа, поверх, матеріал стін. Атрибути зберігаються гнучко:

CREATE TABLE category_attributes (
  id INT PRIMARY KEY,
  category_id INT,
  name VARCHAR(255),
  type ENUM('text','number','select','boolean'),
  options JSONB,
  required BOOLEAN,
  searchable BOOLEAN
);

CREATE TABLE listing_attributes (
  listing_id INT,
  attribute_id INT,
  value_text TEXT,
  value_number NUMERIC,
  value_boolean BOOLEAN
);

Форма оголошення будується динамічно — підвантаження атрибутів категорії через AJAX. Користувач заповнює лише релевантні поля, що підвищує конверсію.

Чому геолокаційний пошук — ключова фіча?

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

SELECT l.*, ST_Distance(l.location::geography, $1::geography) AS dist
FROM listings l
WHERE ST_DWithin(l.location::geography, $1::geography, 10000)
  AND l.category_id = $2
  AND l.status = 'active'
ORDER BY dist;

Для прискорення додаємо кеш Redis на популярні запити. Типовий час відповіді — <50 мс на 100 000 оголошень. Геопошук на PostGIS дає приріст швидкості в 10 разів порівняно зі звичайним LIKE-пошуком за координатами. Це особливо важливо для дошок оголошень у сфері нерухомості та авто.

Як ми організовуємо спілкування: вбудований месенджер?

Покупець пише продавцю прямо в оголошенні — контакти приховані до готовності до угоди. Чат привʼязаний до лістингу (наприклад, «Ваше оголошення "iPhone 14"»). Стек: WebSocket (Laravel Reverb) + PostgreSQL для історії + Redis для статусів «онлайн». Повідомлення зберігаються в партиціонованій таблиці — не гальмує при зростанні.

Як обрати модерацію: pre vs post?

Ми комбінуємо: pre-moderation для дорогих категорій (авто, нерухомість), post-moderation — для дешевих. Автоматика детектує дублі (однаковий title + телефон за 7 днів), спам-патерни та заборонені товари через ML-модель. Автоматична модерація знижує навантаження на операторів до 70%, що економить до 60% бюджету на модерацію.

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

• Аналітика: аудит конкурентів, прототип, user flow.
• Дизайн: адаптивний UI під ключ, 5 екранів.
• Фронтенд: React/Next.js або Vue/Nuxt (вибір за вами).
• Бекенд: Laravel або Node.js, адмін-панель.
• Модерація: автоматичний фільтр + кабінет модератора.
• Монетизація: платіжний шлюз, пакети просування.
• Документація: API (OpenAPI), інструкція адміністратора.
• Навчання: 2 години для команди замовника.
• Гарантія: 6 місяців безкоштовних виправлень багів.

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

1. Аналітика та прототип (1-2 тижні). Визначаємо MVP, малюємо User Story Mapping.
2. Проектування архітектури (1 тиждень). ER-модель, API-специфікація.
3. Реалізація (6-20 тижнів). Ітерації по 2 тижні, кожен спринт — демо.
4. Тестування (2 тижні). Навантажувальні тести (k6), e2e (Cypress), безпека.
5. Деплой та запуск (1 тиждень). CI/CD, моніторинг (Sentry, Grafana).

Строки орієнтовно

Вартість розраховується індивідуально після брифінгу. Замовте консультацію — ми оцінимо ваш проєкт за 1-2 дні.

Безпека угод: ескроу-рахунок

Для дорогих категорій (авто, техніка) впроваджуємо «Безпечну угоду»: покупець платить на ескроу-рахунок платформи, продавець відправляє товар, після підтвердження отримання гроші перераховуються. Інтеграція з ЮKassa або Stripe; кошти зберігаються на окремому рахунку, не змішуючись з оборотами.

Наші інженери мають досвід у класифайдах — 20+ запущених проєктів. Працюємо під ключ з гарантією результату. Отримайте безкоштовну консультацію з розробки дошки оголошень прямо зараз.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 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+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.