Регулярный мониторинг цен обычно представляют довольно просто: есть список товаров, есть площадки, нужно собрать данные и сравнить результаты.
Но эта схема перестаёт быть простой, когда товаров около 300, проверять их нужно в 11 городах и пяти сервисах, а для каждой позиции ещё необходимо подобрать корректный аналог.
В таком случае недостаточно один раз написать парсер и настроить выгрузку.
Именно с такой задачей к нам пришёл клиент.
Каждый месяц он передавал новый файл примерно с 300 товарами. Эти позиции нужно было мониторить в Ozon, «ВкусВилле», «Яндекс Лавке», «Пятёрочке» и «Магните».
Только сочетаний товара, города и сервиса получалось до 16 500 за один цикл:
300 товаров × 11 городов × 5 сервисов.
Но сама задача начиналась не с запуска сбора.
Сначала нужно было понять, что именно и с чем мы будем сравнивать.
Клиенту было важно сравнивать собственный ассортимент с аналогичными позициями на рынке.
Поэтому для каждой исходной позиции нужно было сопоставить подходящий аналог в конкретном сервисе.
И здесь быстро выяснилось, что универсального правила не существует.
Товар, который подходит для сравнения в одном сервисе, может не подойти в другом. Отличаться могут состав, упаковка, объём или артикул. А также иначе могут быть записаны название или бренд.
Поэтому нельзя было один раз выбрать аналог и автоматически использовать его для всех площадок.
Кроме того, один и тот же сервис мог показывать разный ассортимент в разных городах.
Товар может быть доступен в одном городе и отсутствовать в другом. Может отличаться ассортимент, карточка, цена или выбранный для сравнения аналог.
Значит, система должна была учитывать не просто товар и сервис, а конкретную комбинацию условий, в которых выполняется мониторинг.
Не всегда.
Например, исходный товар может продаваться в упаковке 500 мл, а найденный аналог — в упаковке 1 литр.
Если просто поставить рядом две цены, сравнение получится некорректным.
Стоимость нужно привести к сопоставимому объёму.
Поэтому для работы с каждой позицией требовалось учитывать не только сам товар и его аналог, но и объём упаковки.
Для запуска использовались данные по исходному товару и выбранному аналогу: названия, объёмы, ссылки и артикулы.
И только после этого данные можно было использовать для корректного ценового сравнения.
Мониторинг был регулярным.
Каждый месяц появлялся новый файл ТОП-300. В нём могли быть новые товары, а часть прежних позиций могла больше не входить в текущий список.
По новым товарам нужно было добавлять данные для мониторинга.
По уже знакомым — использовать ранее выбранные аналоги.
При этом возник важный вопрос: что делать, если ранее найденный аналог исчез из текущей выдачи?
Удалять его из общей базы было нельзя.
Карточка могла временно пропасть из продажи, сменить ссылку или вернуться позже. Если полностью удалить информацию, пришлось бы снова искать и согласовывать аналог.
Поэтому мы разделили хранение накопленных данных и данные конкретного запуска.
В базе сохраняются все ранее выбранные заказчиком аналоги.
А из текущего файла исключаются только позиции, которые сейчас не нужно мониторить.
Так временное исчезновение товара не приводит к потере уже согласованных данных.
Нужно было автоматизировать не только сбор цен, но и весь процесс подготовки и управления мониторингом.
Мы сделали систему, которая работает с ежемесячными файлами товаров.
При загрузке нового списка можно определить, какие товары появились впервые, какие уже участвовали в предыдущих периодах и по каким позициям существуют ранее выбранные аналоги.
На основе актуального списка и сохранённых данных формируются данные для запуска.
При этом мониторинг не обязательно запускать сразу по всем товарам, городам и сервисам.
Можно выбрать нужный город, сервис, период и набор товаров.
Это позволяет запускать мониторинг точечно, например повторить сбор по нужному направлению без повторной ручной подготовки всех исходных данных.
При тысячах возможных сочетаний недостаточно просто дождаться итогового файла.
Нужно понимать, какой запуск выполнялся, по каким городам и сервисам проходил сбор, какие товары были обработаны, где возникли ошибки и какие позиции не удалось найти.
Для этого в системе предусмотрено логирование запусков и сохранение их истории.
Также нами было реализовано обновления мониторинга по расписанию.
На выходе формируются структурированные данные для сравнения товаров с аналогами по городам и сервисам. Они используются для дальнейшего ценового анализа и формирования ценовых ориентиров, включая РРЦ и PI-цены по правилам клиента.
До автоматизации каждый новый цикл требовал последовательности ручных действий: обработать новый список товаров, добавить новые позиции, использовать ранее выбранные аналоги, подготовить данные для запуска, проверить их и затем запускать мониторинг.
После автоматизации процесс сократился до загрузки списка товаров и настройки расписания.
В результате клиент получил систему для регулярного мониторинга примерно 300 товаров в 11 городах и пяти сервисах.
В этом проекте парсинг был лишь малой частью задачи.
Основная работа заключалась в том, чтобы собрать вокруг регулярного мониторинга понятный процесс: сохранить уже согласованные аналоги, учитывать различия между городами и сервисами, корректно сравнивать товары разного объёма и сделать так, чтобы каждый следующий запуск не требовал ручной подготовки всего с нуля, как это было раньше.
Материал подготовил: Поповичук Д.В. - менеджер компании ParsingSite