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

Ми розробляємо системи моніторингу цін конкурентів, які вирішують конкретне завдання: знати, коли і наскільки конкурент змінив ціну, раніше ніж це помітять покупці. Без автоматизації моніторингу ви ризикуєте пропустити момент зниження ціни на ключовий товар. Ручна перевірка десятків тисяч позицій нереальна, а разовий аудит дає лише миттєвий зріз. За час роботи ми запустили понад 30 таких проектів для e-commerce — від невеликих магазинів до великих маркетплейсів. Наш досвід дозволяє гарантувати стабільну роботу парсера навіть при зміні структури сайту. Якщо вам потрібен надійний інструмент, зв'яжіться з нами — ми оцінимо ваш проект і запропонуємо оптимальне рішення.

Архітектура системи моніторингу

Ключова відмінність від разового парсера — пріоритизація товарів. Популярні позиції потрібно перевіряти раз на годину, довгий хвіст каталогу — раз на добу. Це знижує навантаження на джерело і прискорює реакцію на важливі зміни. Черга завдань розподіляється за пріоритетами, що дозволяє обробляти до 10 000 товарів на хвилину без перевантаження.

[Scheduler]
  ├── High priority queue (топ-товари, щогодини)
  └── Low priority queue  (інші, раз на добу)
        ↓
[Fetcher] → [Parser] → [Change Detector] → [Alert Engine]
                              ↓
                       [price_history table]

Change Detector порівнює нову ціну з останнім записом в історії. При зміні — запис у price_history і подія в чергу алертів. Без змін — лише оновлення last_checked_at, щоб не роздувати історію. Такий підхід дозволяє зберігати до 5 років історії при мінімальному обсязі даних.

Чому JSON-LD — найкраще джерело для парсингу цін?

Ціни на сайтах бувають представлені по-різному. В HTML — CSS-селектор .product-price або атрибут data-price. В Schema.org — надійно, не ламається при редизайні. Через XHR API — перехоплення мережевих запитів через Playwright. Динамічно через JS після завантаження — потрібен headless browser. JSON-LD — найбільш стабільне джерело: багато SEO-оптимізованих магазинів додають мікророзмітку для пошукових роботів. Помилка при парсингу через HTML може сягати 10%, а через JSON-LD — менше 0.5%.

import * as cheerio from 'cheerio';

interface PriceData {
  price: number;
  priceSale?: number;
  currency: string;
  inStock: boolean;
}

function extractPriceFromJsonLd(html: string): PriceData | null {
  const $ = cheerio.load(html);

  for (const scriptEl of $('script[type="application/ld+json"]').toArray()) {
    try {
      const data = JSON.parse($(scriptEl).html() ?? '{}');
      const product = data['@type'] === 'Product' ? data :
        (Array.isArray(data['@graph'])
          ? data['@graph'].find((n: { '@type': string }) => n['@type'] === 'Product')
          : null);

      if (product?.offers) {
        const offer = Array.isArray(product.offers) ? product.offers[0] : product.offers;
        return {
          price: parseFloat(offer.price),
          currency: offer.priceCurrency ?? 'RUB',
          inStock: offer.availability?.includes('InStock') ?? true,
        };
      }
    } catch { continue; }
  }

  return null;
}

Обробка форматів цін у тексті: "1 299,00 ₽", "$12.99", "€ 9,90" — нормалізація через regex. Зберігати як DECIMAL(10,2) з окремим полем currency. Слідкувати за трьома рівнями: ціна без знижки (price_original), ціна зі знижкою (price_sale), ціна за карткою лояльності (часто третя прихована ціна).

Механізм детектора змін

CREATE TABLE monitored_products (
  id              SERIAL PRIMARY KEY,
  source          VARCHAR(100) NOT NULL,
  external_id     VARCHAR(255) NOT NULL,
  title           TEXT,
  url             TEXT NOT NULL,
  priority        SMALLINT DEFAULT 5,  -- 1=найвищий, 10=найнижчий
  check_interval  INT DEFAULT 360,     -- хвилини
  last_checked_at TIMESTAMPTZ,
  UNIQUE(source, external_id)
);

CREATE TABLE price_history (
  id             BIGSERIAL PRIMARY KEY,
  product_id     INT REFERENCES monitored_products(id),
  price          DECIMAL(10,2),
  price_original DECIMAL(10,2),
  in_stock       BOOLEAN,
  currency       VARCHAR(3) DEFAULT 'RUB',
  recorded_at    TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX ON price_history(product_id, recorded_at DESC);

-- Швидкий доступ до актуальної ціни без JOIN з історією
ALTER TABLE monitored_products
  ADD COLUMN current_price DECIMAL(10,2),
  ADD COLUMN current_in_stock BOOLEAN;

async function processNewPrice(
  productId: number,
  newPrice: number,
  newInStock: boolean
): Promise<{ changed: boolean; delta?: number }> {
  const product = await db.monitoredProducts.findById(productId);

  const priceChanged = product.currentPrice !== newPrice;
  const stockChanged = product.currentInStock !== newInStock;

  if (!priceChanged && !stockChanged) {
    // Тільки оновити час перевірки
    await db.monitoredProducts.update(productId, { lastCheckedAt: new Date() });
    return { changed: false };
  }

  // Записати в історію
  await db.priceHistory.create({
    productId,
    price: newPrice,
    inStock: newInStock,
    recordedAt: new Date(),
  });

  // Оновити поточні значення
  await db.monitoredProducts.update(productId, {
    currentPrice: newPrice,
    currentInStock: newInStock,
    lastCheckedAt: new Date(),
  });

  const delta = product.currentPrice
    ? ((newPrice - product.currentPrice) / product.currentPrice) * 100
    : 0;

  return { changed: true, delta };
}

Налаштування алертів та порогів

Конфігуровані правила спрацювання:

• Ціна знизилася більше ніж на X% (наприклад, 5% або 10%)
• Ціна опустилася нижче вашої ціни на аналогічний товар
• Товар з'явився або зник з наявності
• Ціна змінилася у N+ конкурентів одночасно (ознака ринкового зсуву)
• Ціна досягла історичного мінімуму за останні 90 днів

async function checkAlertRules(productId: number, delta: number): Promise<void> {
  const rules = await db.alertRules.findAll({ productId, active: true });

  for (const rule of rules) {
    const triggered =
      (rule.type === 'price_drop_percent' && delta < -rule.threshold) ||
      (rule.type === 'below_my_price' && await isPriceBelowMyPrice(productId)) ||
      (rule.type === 'out_of_stock' && newInStock === false);

    if (triggered) {
      await sendAlert(rule, productId, delta);
    }
  }
}

Доставка: Telegram-бот (миттєво через Bot API), email-дайджест (раз на день), webhook у систему управління цінами (для автоматичної реакції). Пороги можна змінювати в реальному часі через дашборд.

Що всередині дашборду аналітики?

Мінімально необхідні екрани:

Таблиця моніторингу — всі відстежувані товари з поточною ціною конкурента, вашою ціною, різницею у відсотках і трендом (стрілка вгору/вниз).

Графік цін — ціна конкурента vs ваша ціна за вибраний період. Recharts LineChart з двома лініями та маркерами змін.

Стрічка алертів — останні 50 змін з фільтрацією за джерелом і типом зміни.

Швидка реалізація дашборду — Metabase, підключений до PostgreSQL. Кастомний React-інтерфейс з Recharts потрібен, якщо дашборд вбудовується в існуючу систему управління асортиментом.

Процес розробки

1. Аналітика — вивчаємо цільові сайти, визначаємо пріоритети товарів, погоджуємо алерти та дашборд.
2. Проектування — проектуємо архітектуру парсера, базу даних, правила алертів.
3. Реалізація — пишемо код, налаштовуємо черги, інтеграції.
4. Тестування — запускаємо на реальних даних, перевіряємо точність та стабільність.
5. Деплой і підтримка — розгортаємо на вашому сервері або хмарі, передаємо документацію, навчаємо.

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

• Вихідний код парсера з відкритою документацією
• Доступ до дашборду та API
• Інструкція з експлуатації
• Гарантія стабільної роботи 3 місяці
• Підтримка при змінах структури сайтів (до 5 адаптацій на місяць)

Строки та масштаб

Для 100k+ товарів з історією за рік — ClickHouse замість PostgreSQL для зберігання price_history: аналітичні запити (агрегація за період, пошук мінімуму) на великих обсягах працюють на порядок швидше. PostgreSQL залишається для оперативних даних і конфігурації.

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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.