Мониторинг цен конкурентов и сбор данных

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

Мониторинг можно использовать для нескольких практических сценариев:

• собирать цены и наличие по согласованному списку товаров;
• сопоставлять собственные позиции с предложениями конкурентов;
• отслеживать появление, исчезновение и изменение карточек;
• видеть историю изменений за выбранный период;
• передавать данные в таблицу, дашборд, API или внутреннюю систему;
• получать сигнал, если источник перестал отдавать данные или структура страницы изменилась.

Перед разработкой важно определить не только сайты-источники, но и правила сопоставления. Один и тот же товар может называться по-разному, иметь разные комплектации, объёмы и артикулы. Без этих правил даже технически корректный сбор создаёт таблицу, которой нельзя доверять при принятии решений.

Рабочее решение включает больше, чем сам скрипт для загрузки страниц. Сначала формируется перечень источников и полей: цена, старая цена, наличие, продавец, артикул, характеристика или другая нужная бизнесу информация. Затем для каждого источника настраивается способ получения данных и единая схема результата.

После сбора данные проходят обработку. Система удаляет технические дубли, нормализует значения и сохраняет время наблюдения. Если требуется сопоставление товаров, отдельно задаются ключи и правила, по которым позиции считаются одинаковыми. Спорные совпадения лучше выделять для проверки, а не автоматически превращать в достоверный результат.

Следующий слой — доставка результата. Для периодического анализа может быть достаточно таблицы. Для регулярной работы удобнее дашборд с фильтрами и историей. Если данные должны участвовать в ценообразовании или других процессах, их можно передавать через API — программный интерфейс, то есть способ обмена данными с другой системой, — или записывать в существующую базу. Выбор формата зависит от того, кто использует данные и какое решение принимается после обновления.

Источник может изменить разметку, ограничить частоту обращений или временно вернуть неполный ответ. Поэтому система должна отличать реальное изменение цены от технической ошибки. Для этого используются проверки обязательных полей, допустимых форматов, числа полученных записей и резких отклонений от предыдущего запуска.

Полезно фиксировать для каждой записи источник и время получения. Тогда команда понимает, насколько свежи данные и откуда взялось конкретное значение. Ошибки сбора не должны незаметно смешиваться с рабочими результатами: их нужно показывать отдельно и передавать в контрольный контур.

Периодичность обновления выбирается под задачу. Чем чаще требуется сбор и чем больше источников, тем выше нагрузка на инфраструктуру и требования к устойчивости. Поэтому частота определяется после разбора источников, допустимых способов получения данных и того, насколько быстро изменение должно попасть к пользователю.