Все статьиТехническоеСбор данных и Scraper API8 мин

Динамические товарные фиды: сбор и нормализация

Архитектура получения публичных товарных фидов: API, JavaScript-рендеринг, варианты товаров, дедупликация и контроль изменений.

Команда InfraProxy

18 февраля 2026 г.обновлено 18 августа 2026 г.

#товарный фид#JavaScript#варианты товаров#ETL#контроль качества

Динамический каталог нельзя считать одним HTML-документом. Цена, наличие и варианты товара могут приходить отдельными запросами, поэтому сначала ищите официальный фид или API, а затем моделируйте связи между товаром и вариантом.

Товар и вариант — разные сущности

Одна карточка может содержать несколько размеров, цветов или комплектов. Если хранить только URL страницы, изменения одного варианта перезапишут другой.

{
  "product_id": "p-100",
  "variant_id": "p-100-blue-m",
  "title": "Футболка",
  "attributes": {
    "color": "blue",
    "size": "M"
  },
  "price": 1490,
  "currency": "RUB",
  "available": true,
  "observed_at": "2026-08-18T07:00:00Z"
}

Ключом снимка должна быть пара product_id + variant_id.

Где искать данные

Проверяйте источники по порядку:

  1. Официальный API или экспорт.
  2. Публичный XML/CSV/JSON-фид.
  3. JSON-LD в исходном HTML.
  4. Публичные XHR/Fetch-ответы, если их использование разрешено.
  5. Рендеринг страницы в браузере.

Браузер — самый дорогой и хрупкий слой. Не включайте его для всех URL, если большая часть полей доступна в структурированном ответе.

Двухэтапная загрузка

Практичная схема:

  • дешёвый запрос получает исходный HTML;
  • валидатор ищет обязательные поля;
  • только неполные страницы переходят в очередь JavaScript-рендеринга;
  • итоговые записи проходят одну схему нормализации.

Это снижает время и стоимость без выдуманных «процентов успеха».

Ожидание полезного состояния

Событие load не гарантирует, что варианты товара уже появились. Для браузерного режима ждите конкретный элемент или сетевой ответ, но задавайте верхний таймаут.

Плохой критерий: «подождать 10 секунд».
Рабочий критерий: «ждать контейнер вариантов до 10 секунд, затем вернуть диагностическую ошибку».

Дедупликация и история

Сохраняйте:

  • стабильные идентификаторы товара и варианта;
  • хеш значимых полей;
  • first_seen_at и last_seen_at;
  • источник и способ получения;
  • причину неполной записи.

Не помечайте вариант удалённым после одного неуспешного запроса. Подтвердите исчезновение повторным корректным снимком.

Наблюдаемость

Метрика Что диагностирует
Доля ответов без вариантов Изменение схемы или незавершённый рендеринг
Время HTML / JS отдельно Стоимость браузерного слоя
Дубликаты variant_id Ошибку ключа или пагинации
Неизвестная валюта Ошибку нормализации
429/503 Слишком высокую частоту
Изменения цены на 1000 записей Аномалии данных

Этичность и ограничения

Используйте официальный фид или API, если он есть. Проверяйте robots.txt, Disallow, Crawl-delay и условия использования. Ограничивайте параллельность, применяйте backoff на 429/503 и кэшируйте ответы. Не обходите авторизацию и paywall, не собирайте персональные данные и не копируйте чужие описания целиком.

Для регулярной коммерческой интеграции согласованный фид надёжнее парсинга интерфейса.

Если браузерный слой и повторы не хочется поддерживать самостоятельно, проверьте Scraper API на разрешённом каталоге.

Ключевые выводы

  • Товар и вариант требуют разных идентификаторов.
  • Браузерный рендеринг включается только после дешёвой проверки HTML/API.
  • Ожидайте конкретное состояние страницы, а не фиксированную паузу.
  • Удаление товара подтверждается корректным повторным снимком.

Краткий ответ: сначала ищите фид или API, затем храните варианты отдельно и используйте браузер только для страниц без достаточных структурированных данных.

Нужно получать публичные данные без поддержки собственной инфраструктуры?

Посмотрите возможности Scraper API, условия теста и примеры интеграции.

Перейти к Scraper API