Бот для моніторингу відгуків товарів на маркетплейсах

Негативний відгук на Ozon або Wildberries може висіти без відповіді добу. За цей час він встигає відштовхнути десятки потенційних покупців. Ми розробили бота, який сканує відгуки в реальному часі та миттєво сповіщає команду в Telegram. За нашими даними, 70% покупців змінюють думку про бренд після швидкої відповіді на негатив. Наш бот скорочує час реакції з годин до хвилин. За роки ми реалізували 30+ проектів з репутаційного моніторингу — від простих парсерів до Enterprise-систем. Економія часу на обробку відгуків сягає 40%.

Чому бот окупається за місяць?

Ручна перевірка 1000 карток товарів на кількох майданчиках може займати до 4 годин щодня. При вартості години оператора в X гривень щомісячні витрати становлять десятки тисяч. Бот виконує ту саму роботу за хвилини та обходиться в одноразову інвестицію, яка окупається за 1–2 місяці за рахунок зниження трудовитрат та підвищення конверсії. В одному з проектів для великого продавця електроніки ми замінили ручний моніторинг 500 карток на автоматизований. Час реакції на негатив скоротився з 4 годин до 2 хвилин, а конверсія в лояльність зросла на 15%.

Бот швидший за ручний моніторинг

Ручна перевірка десятків карток товарів на кількох майданчиках займає години. Бот перевіряє кожен майданчик за розкладом: для API-майданчиків — раз на годину, для парсингу — раз на 4 години. Повідомлення надходить у Telegram за 1–2 хвилини після появи відгуку. Це в 10–20 разів швидше за ручний підхід.

Як налаштувати бота за 3 кроки?

1. Підготовка джерел. Ви передаєте список посилань на товари або API-ключі (для Яндекс.Маркет). Ми створюємо записи в review_sources.
2. Запуск адаптерів. Бот запускає команди reviews:check --platform=... за розкладом. Кожен адаптер реалізує інтерфейс ReviewAdapterInterface і повертає масив ReviewDTO.
3. Налаштування повідомлень. Вказуєте Telegram-чат для звичайних відгуків та окремий чат для термінових (негативних). Все готово до роботи.

Архітектура адаптерів для майданчиків

Кожен майданчик — окремий адаптер. Для платформ з API (Яндекс.Маркет) використовуємо прямі запити, для інших — парсинг HTML через Playwright. Всі адаптери реалізують єдиний інтерфейс ReviewAdapterInterface, що спрощує додавання нових майданчиків.

Схема даних включає дві основні таблиці: review_sources (посилання на товари) та reviews (самі відгуки). Індекси прискорюють вибірку непрочитаних відгуків. Ось структура:

CREATE TABLE review_sources (
    id              BIGSERIAL PRIMARY KEY,
    platform        VARCHAR(50) NOT NULL,    -- 'yandex_market', 'ozon', 'google', 'otzovik'
    product_id      BIGINT REFERENCES products(id),
    external_url    TEXT NOT NULL,
    external_id     VARCHAR(255),            -- ID карточки на площадке
    scrape_config   JSONB,
    is_active       BOOLEAN DEFAULT TRUE,
    UNIQUE(platform, external_url)
);

CREATE TABLE reviews (
    id              BIGSERIAL PRIMARY KEY,
    source_id       BIGINT REFERENCES review_sources(id),
    external_id     VARCHAR(255),            -- ID отзыва на площадке
    author          VARCHAR(255),
    rating          SMALLINT,               -- 1–5
    text            TEXT,
    pros            TEXT,
    cons            TEXT,
    published_at    TIMESTAMP,
    discovered_at   TIMESTAMP DEFAULT NOW(),
    sentiment       VARCHAR(20),            -- 'positive', 'negative', 'neutral' (ML)
    is_notified     BOOLEAN DEFAULT FALSE,
    UNIQUE(source_id, external_id)
);

CREATE INDEX idx_reviews_rating ON reviews(source_id, rating);
CREATE INDEX idx_reviews_notified ON reviews(source_id) WHERE is_notified = FALSE;

API чи парсинг: порівняння

API стабільніше, але не у всіх майданчиків відкритий. Яндекс.Маркет надає API партнерам — без блокувань і з повними даними. Ozon і Wildberries API для відгуків не дають, тому використовуємо Playwright: браузер рендерить сторінку та витягує відгуки. Це повільніше, але надійно.

Ось порівняння підходів:

Адаптери для Яндекс.Маркет та Ozon:

class YandexMarketReviewAdapter implements ReviewAdapterInterface
{
    public function fetchReviews(ReviewSource $source): array
    {
        $modelId = $source->external_id;

        $response = Http::withHeaders([
            'Authorization' => 'Bearer ' . config('services.yandex_market.token'),
        ])->get("https://api.partner.market.yandex.ru/v2/models/{$modelId}/reviews", [
            'count'  => 30,
            'page'   => 1,
        ]);

        return collect($response->json('result.reviews', []))
            ->map(fn($r) => new ReviewDTO(
                externalId:  (string) $r['id'],
                author:      $r['author']['name'] ?? 'Аноним',
                rating:      (int) $r['grade'],
                text:        $r['text'] ?? '',
                pros:        $r['pros'] ?? null,
                cons:        $r['cons'] ?? null,
                publishedAt: Carbon::parse($r['date']),
            ))
            ->toArray();
    }
}

class OzonReviewAdapter implements ReviewAdapterInterface
{
    public function fetchReviews(ReviewSource $source): array
    {
        $data = $this->playwright->evaluate($source->external_url, <<<JS
            await page.waitForSelector('[data-widget="webReviewProductScore"]', {timeout: 10000});
            const items = document.querySelectorAll('[data-widget="webSingleReview"]');
            return Array.from(items).map(el => ({
                id:        el.dataset.reviewId,
                rating:    parseInt(el.querySelector('[data-rating]')?.dataset.rating) || 0,
                text:      el.querySelector('.review-text')?.textContent?.trim() || '',
                pros:      el.querySelector('.pros')?.textContent?.trim() || null,
                cons:      el.querySelector('.cons')?.textContent?.trim() || null,
                author:    el.querySelector('.author-name')?.textContent?.trim() || 'Аноним',
                date:      el.querySelector('time')?.getAttribute('datetime'),
            }));
        JS);

        return collect($data)->map(fn($r) => new ReviewDTO(
            externalId:  $r['id'],
            author:      $r['author'],
            rating:      $r['rating'],
            text:        $r['text'],
            pros:        $r['pros'],
            cons:        $r['cons'],
            publishedAt: $r['date'] ? Carbon::parse($r['date']) : now(),
        ))->toArray();
    }
}

Механізм аналізу тональності

Використовуємо два рівні. Якщо рейтинг 1–2 або 4–5 — тональність очевидна. При рейтингу 3 запускаємо аналіз за ключовими словами або AI:

class SentimentAnalyzer
{
    private array $negativeKeywords = [
        'брак', 'сломан', 'не работает', 'возврат', 'обман',
        'разочарован', 'ужас', 'кошмар', 'мусор', 'дрянь',
    ];

    private array $positiveKeywords = [
        'отлично', 'супер', 'доволен', 'рекомендую', 'превзошёл',
        'быстро', 'качественно', 'спасибо',
    ];

    public function analyze(ReviewDTO $review): string
    {
        if ($review->rating <= 2) return 'negative';
        if ($review->rating >= 4) return 'positive';

        $text = mb_strtolower($review->text . ' ' . $review->cons);

        foreach ($this->negativeKeywords as $kw) {
            if (str_contains($text, $kw)) return 'negative';
        }

        return 'neutral';
    }

    public function analyzeWithAI(string $text): string
    {
        $response = $this->openai->chat()->create([
            'model'    => 'gpt-4o-mini',
            'messages' => [
                ['role' => 'system', 'content' => 'Определи тональность отзыва. Ответь одним словом: positive, negative или neutral.'],
                ['role' => 'user',   'content' => $text],
            ],
            'max_tokens' => 10,
        ]);

        return in_array($response->choices[0]->message->content, ['positive', 'negative', 'neutral'])
            ? $response->choices[0]->message->content
            : 'neutral';
    }
}

Повідомлення надсилаються в Telegram: для негативних відгуків — в окремий чат термінової підтримки, для інших — в загальний. Повідомлення містить рейтинг, текст відгуку та посилання.

class ReviewNotifier
{
    public function notifyNew(Review $review): void
    {
        $emoji   = match ($review->sentiment) {
            'positive' => '⭐',
            'negative' => '🚨',
            default    => '💬',
        };

        $stars = str_repeat('★', $review->rating) . str_repeat('☆', 5 - $review->rating);

        $text = "{$emoji} *Новий відгук* — {$review->source->platform}\n"
            . "{$stars} {$review->rating}/5\n"
            . "*{$review->author}*\n\n"
            . mb_substr($review->text, 0, 300)
            . (mb_strlen($review->text) > 300 ? '...' : '') . "\n\n"
            . "[Відкрити відгук]({$review->source->external_url})";

        $chatId = $review->sentiment === 'negative'
            ? config('telegram.urgent_reviews_chat')
            : config('telegram.reviews_chat');

        $this->telegram->sendMessage([
            'chat_id'    => $chatId,
            'text'       => $text,
            'parse_mode' => 'Markdown',
        ]);

        $review->update(['is_notified' => true]);
    }
}

Аналітика рейтингу та розклад перевірки:

-- Агрегат рейтингу по платформах за останні 30 днів
SELECT
    rs.platform,
    COUNT(*) AS total_reviews,
    ROUND(AVG(r.rating), 2) AS avg_rating,
    COUNT(*) FILTER (WHERE r.rating <= 2) AS negative_count,
    COUNT(*) FILTER (WHERE r.rating >= 4) AS positive_count
FROM reviews r
JOIN review_sources rs ON r.source_id = rs.id
WHERE r.published_at >= NOW() - INTERVAL '30 days'
GROUP BY rs.platform
ORDER BY avg_rating;

-- Швидкі платформи з API — щогодини
$schedule->command('reviews:check --platform=yandex_market')->hourly();

-- Парсинг через браузер — кожні 4 години (ресурсомістко)
$schedule->command('reviews:check --platform=ozon')->everyFourHours();
$schedule->command('reviews:check --platform=wildberries')->everyFourHours();

-- Щотижневий зведений звіт з трендом рейтингу
$schedule->job(new WeeklyReviewsReportJob)->weekly()->mondays()->at('09:00');

Що робити, якщо майданчик змінює HTML-структуру?

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

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

Проект під ключ включає: проектування схеми даних, розробку адаптерів для трьох майданчиків, налаштування розкладу, реалізацію аналізу тональності, Telegram-повідомлення, дашборд аналітики в адмінці. Терміни: базова версія — 2 дні, повний комплект — до 5 робочих днів. Вартість розраховується індивідуально під ваш стек та кількість майданчиків. Ми гарантуємо стабільну роботу бота при дотриманні лімітів майданчиків.

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

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в e-commerce виникає на стику цих підсистем. Наш досвід — понад 50 реалізованих проектів — показує, що правильна архітектура на старті економить до 40% бюджету на доробках.

Чому продуктивність каталогу деградує при зростанні SKU?

Найчастіша технічна проблема e-commerce — деградація сторінок категорій при збільшенні асортименту. Сторінка працює добре на 500 товарах і починає гальмувати на 10 000. Причини майже завжди одні й ті ж.

N+1 на атрибутах. Завантажуєте список товарів — 50 елементів. Для кожного потрібні категорія, головне фото, ціна з урахуванням знижки, наявність на складі, рейтинг. Без правильного eager loading це 250+ запитів на сторінку. В Laravel вирішується через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) та withAvg('reviews', 'rating'). Але варто з'явитися персональним цінам (b2b) або складським залишкам по регіонах — і одного with() недостатньо. Потрібні Query Object або виділений ReadModel.

Фасетна фільтрація без індексів. Фільтр за кольором + розміром + брендом + діапазоном цін на таблиці в 500 000 записів без складених індексів — це seq scan при кожному запиті. PostgreSQL з правильними індексами тримає фасетну фільтрацію до кількох мільйонів товарів. Для великих каталогів — Elasticsearch або OpenSearch з агрегаціями: вони рахують кількість товарів на фільтр (facet counts) значно швидше.

Пагінація через OFFSET. LIMIT 50 OFFSET 10000 на великій таблиці — погана ідея: PostgreSQL все одно читає перші 10 050 рядків. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 працює за постійний час незалежно від сторінки. Як зазначено в документації PostgreSQL, cursor-based pagination гарантує O(log n) при будь-якому зміщенні, що особливо важливо для каталогів із сотнями тисяч товарів.

Конкретний кейс: каталог будівельних матеріалів, 180 000 SKU, фасетна фільтрація по 12 атрибутах. Після переходу з OFFSET-пагінації на курсорну та додавання partial index по (category_id, is_active, price) час відповіді сторінки каталогу знизився з 4,2 с до 280 мс. Економія на серверних ресурсах склала близько 30 000 ₽ на місяць. В іншому проекті (ювелірний маркетплейс) впровадження агрегацій через Elasticsearch скоротило час фільтрації з 8 до 200 мс та заощадило 50 000 ₽ на місяць на інфраструктурі — ще один приклад, як правильна архітектура знижує TCO.

Що таке race condition у кошику та як його уникнути?

Checkout — місце, де гроші або потрапляють на рахунок, або ні. Технічні проблеми тут коштують дорого.

Race condition при резервуванні товару. Два покупці одночасно додають останній екземпляр у кошик і обоє натискають «Оплатити». Без песимістичного блокування або атомарного UPDATE з перевіркою залишку обидва замовлення проходять, інвентар іде в мінус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Якщо RETURNING повернув 0 рядків — товару немає, показуємо помилку до списання грошей.

Ідемпотентність платіжних вебхуків. payment.succeeded від Stripe або ЮКассы може прийти двічі через мережеві збої або retry-логіку на стороні шлюзу. Без перевірки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублювання замовлення або подвійне зарахування. Webhook idempotency — обов'язковий патерн для будь-якого платіжного інтегратора. Ми включаємо тест на ідемпотентність у стандартний чек-лист кожного проекту.

Checkout у кілька кроків. Multi-step checkout (адреса → доставка → оплата → підтвердження) vs single-page checkout. Дослідження показують, що single-page з прогрес-індикатором конвертує на 15–20% краще на мобільних. Стан між кроками — або localStorage + server-side сесія, або повністю server-side з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на Vercel / Docker / виділеному сервері, підключаємо Sentry та Uptime.

SEO для e-commerce

Canonical та дублювання. Фасетна фільтрація генерує тисячі URL (?color=red&size=M&sort=price). Без canonical або noindex на фільтрованих сторінках краулінговий бюджет витрачається на дублі, а основні сторінки індексуються гірше.

Structured data. Product schema з offers, aggregateRating, availability — це rich snippets у видачі: зірочки рейтингу, ціна, наявність. Впливає на CTR.

Core Web Vitals на сторінках товарів. Hero image товару — це LCP element. fetchpriority="high" на першому зображенні, правильні srcset з WebP, width та height атрибути для запобігання CLS.

Що входить у результат роботи

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

• Вихідний код та повну документацію (API, архітектура, інфраструктура);
• Доступи до репозиторію, хостингу, моніторингу (Sentry, Uptime);
• Навчання команди роботі з адмін-панеллю та кастомізаціями;
• Гарантійну підтримку 3 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

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

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

Гарантуємо — кожен проект проходить цей чек-лист перед релізом. Зв'яжіться з нами — підберемо оптимальну архітектуру під ваш бюджет та терміни.