Разработка бота-парсера наличия товаров у конкурентов

Парсер наличия товаров: где ломается сбор данных

Парсер наличия товаров решает одну задачу — регулярно отдавать актуальную картину по чужому каталогу: что есть на складе, что ушло, что вернулось. Пока выборка чистая, закупщик работает по факту. Как только в цепочке «источник → разбор → хранилище → отчёт» появляется рассогласование, данные становятся опаснее их отсутствия: по ним принимают решения.

Самый частый сбой — устаревшие остатки в каталоге. Выгрузка забирается целиком и перезаписывается раз в сутки, хотя источник обновляется чаще; часть страниц отдаётся из кэша, и сбор данных о наличии фиксирует вчерашнее состояние как текущее. Закупщик видит «в наличии», а позиция разобрана ещё утром.

Второй класс — пустые карточки после смены разметки. Разбор держится за конкретные элементы страницы: при редизайне блока цены или склада узел пропадает, и сборщик молча возвращает «нет в наличии» вместо ошибки разбора. Отчёт выглядит валидным, но половина каталога в нём — ложные нули.

Третий — расхождение склада и витрины. Товар лежит в учётной системе (1С), но не опубликован, или наоборот: карточка открыта, а остаток не проведён. Без сверки этих двух источников мониторинг каталога конкурента показывает то, что видит покупатель, а не то, чем реально торгует поставщик.

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

Что даёт постоянный сбор данных о наличии и ценах

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

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

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

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

Методы сбора данных: сравнение и ограничения

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

На практике методы почти всегда комбинируются: где есть интерфейс — работаем через него, остальное закрываем обходом каталога, а выгрузка поставщика идёт резервным каналом на случай недоступности. Данные из всех источников приводим к единой схеме: артикул, площадка, остаток, время замера. Тогда сбой одного канала не роняет сбор, а расхождения между источниками видно сразу.

Этапы разработки: от разбора задачи до запуска

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

1. Аудит источников данных. Разбираем каждый сайт: есть ли открытый программный интерфейс или только разметка карточек, как устроена пагинация, нужен ли обход региональных поддоменов. На выходе — перечень источников с частотой обновления и правилами сопоставления товаров.
2. Схема сбора и ключ сопоставления. Берём стабильный идентификатор — артикул или штрихкод, — чтобы переименование карточки не давало ложное «нет в наличии». Поведение при смене разметки описываем заранее: сигнал об ошибке вместо тихой пустой выгрузки.
3. Сборка ядра на одном-двух источниках. Обкатываем хранение и сравнение цен на простых сайтах, прежде чем подключать остальные. Так ошибки логики всплывают до того, как в схеме появится десяток источников.
4. Расписание обновлений. Интервал подбираем под задачу, запуски разносим по времени, ограничиваем число одновременных обращений и ставим повторы при сетевых сбоях, чтобы чужие серверы не видели в нас нагрузку.
5. Тестовый прогон. Сверяем результат с ручной выборкой по нескольким десяткам карточек, считаем долю расхождений и смотрим, что бот делает с позициями, снятыми с продажи или скрытыми из каталога.
6. Приёмка. Проверяем на реальном наборе: полнота по каждому источнику, свежесть данных к моменту отчёта, число ложных срабатываний. Критерии согласуем до запуска, чтобы приёмка была формальностью, а не спором.
7. Передача и обучение. Отдаём конфигурации, документацию и инструкцию по подключению нового источника, показываем, как читать журнал ошибок. Дальше цикл обновления бота команда заказчика ведёт сама.

Комплект поставки: код, схемы, регламенты обновления

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

• Исходный код — репозиторий с историей изменений, разделённый на модули: обход источников, разбор страниц, сопоставление товаров, отправка оповещений.

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

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

• Документация на бота — инструкция запуска с нуля, состав окружения, где хранятся ключи доступа и как их менять без правки кода.

• Регламент обновления — периодичность ревизии источников, порядок подключения нового магазина, действия при смене разметки страниц у источника.

• Передача доступов — учётные записи, роли, порядок ротации ключей при уходе сотрудника, за кем закреплён каждый доступ.

• Хранение истории — глубина хранения снимков наличия и цен, расписание очистки, формат выгрузки для аналитики.

• Регламент поддержки — время реакции на сбой сбора, порядок восстановления и контроль, при котором молчание бота не читается как «товар есть».

Кейс: контроль ассортимента в розничной сети

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

Что изменили

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

Что стало

Сверка занимает 15–20 минут вместо двух дней, а сводка приходит до открытия смены. Доля изменений, пойманных в первые сутки, выросла с 40% до 95% — закупка реагирует, пока конкурент ещё не разобрал склад. Ручных операций стало в разы меньше: менеджер разбирает только подозрительные расхождения, а не весь список. Когда на одном источнике дважды менялась разметка, сбор восстанавливали за 20 минут правкой селекторов, без переписывания логики.

Чем отличается сбор через программный интерфейс от обхода страниц?

Если у магазина есть программный интерфейс, наличие приходит готовыми полями: остаток по складу, статус «в наличии» или «под заказ», срок поставки. Мы забираем десятки и сотни позиций за один запрос и получаем набор значений, который не зависит от того, как в этот момент отрисована карточка на сайте. Скорость и устойчивость сбора здесь максимальные, пока договорённость с источником не поменялась.

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

Программный интерфейс или обход страниц — это не выбор «или-или». Чаще основной канал — интерфейс, а обход работает страховкой: подтверждает наличие по точкам продаж, которые интерфейс не покрывает, и подстраховывает, когда ответы приходят с задержкой. В обратную сторону это тоже работает: при отсутствии интерфейса обход закрывает всё, а интерфейс подключается позже, если магазин его открывает.

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

Сомнения по нагрузке, блокировкам и поддержке

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

Ниже — сомнения, которые чаще всего звучат до старта: блокировка запросов, правовые рамки сбора, ложные срабатывания и поддержка после запуска.

Какие правовые рамки сбора данных?

Работаем только с открытыми сведениями о наличии и цене — без авторизации, личных кабинетов и персональных данных. К каждому снимку сохраняем адрес источника и время получения: это основа для сверки и разбора спорных случаев.

Как отсекаете ложные срабатывания?

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

Кто отвечает за работу после запуска?

Разметка чужих страниц меняется, поэтому после передачи остаётся регламент: контроль доли успешных снимков, оповещение о падении и о смене структуры, плановое обновление правил разбора. Отдаём документацию по полям и порядок самостоятельного запуска.

Обсудим задачу: схема сбора и план запуска

Чтобы вернуться с оценкой и планом, а не с уточняющими вопросами, нужен минимум исходных данных. Ниже — что прислать на обсуждение задачи: этого достаточно, чтобы посчитать объём работ, собрать схему сбора и назвать сроки.

• Список источников — площадки и разделы, где нужно отслеживать наличие: адреса каталогов, категорий, страниц товаров.
• Списки товаров — артикулы, названия или ссылки на карточки, по которым сверяем позиции; если списков несколько, укажите, чем они отличаются.
• Требуемые поля — что именно фиксируем в выгрузке: статус наличия, остаток, срок поставки, адрес карточки, время замера.
• Частота обновления — раз в сутки, раз в час или по событию; от этого зависит схема обхода и объём хранения истории.
• Формат выгрузки — таблица, файл или запись в вашу учётную систему, а также нужна ли история изменений и на какую глубину.
• Доступы и ограничения — где требуется авторизация, есть ли ограничения на число обращений и требуется ли работать через ваш прокси-контур.
• Правила реакции — кому и как сообщать об изменении: письмо, уведомление в мессенджере или отдельная сводка.

С этим набором мы возвращаемся с планом работ: схема сбора по каждому источнику, этапы, состав команды, порядок проверки данных на тестовой выборке и условия сопровождения после запуска. Опишите задачу — пришлём оценку и план.