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

Парсер наявності товарів: де ламається збір даних

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

Щойно в ланцюжку «джерело → розбір → сховище → звіт» з’являється неузгодженість, дані стають небезпечнішими за їхню відсутність: за ними ухвалюють рішення.

Найчастіший збій — застарілі залишки в каталозі. Вивантаження забирається повністю й перезаписується раз на добу, хоча джерело оновлюється частіше; частина сторінок віддається з кешу, і збір даних про наявність фіксує вчорашній стан як поточний. Закупівельник бачить «в наявності», а позиція розібрана ще зранку.

Другий клас — порожні картки після зміни розмітки. Розбір тримається за конкретні елементи сторінки: під час редизайну блоку ціни або складу вузол зникає, і збирач мовчки повертає «немає в наявності» замість помилки розбору. Звіт виглядає валідним, але половина каталогу в ньому — хибні нулі.

Третій — розходження складу й вітрини. Товар лежить в обліковій системі (1С), але не опублікований, або навпаки: картка відкрита, а залишок не проведений.

Без звірки цих двох джерел моніторинг каталогу конкурента показує те, що бачить покупець, а не те, чим реально торгує постачальник.

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

Що дає постійний збір даних про наявність і ціни

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

Постійний збір знімає основну частину цієї роботи: частка ручних перевірок падає до розбору винятків — як правило, одиниці відсотків від попереднього обсягу.

Решту закриває моніторинг цін і наявності за розкладом: незмінені позиції не відволікають, а зміни одразу потрапляють у звіт із часом фіксації.

Швидкість реакції на зникнення товару з наявності перестає залежати від того, коли закупівельник дійде до картки.

Сигнал надходить у момент зміни, тому кількість пропущених дефіцитів скорочується до нуля, а рішення про підстраховку ухвалюється того самого дня, а не після того, як постачальник розпродав залишки.

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

Історія змін показує, коли позиція зникла й повернулася, скільки тривав дефіцит і як поводилася ціна в сусідів: це підстава для переговорів і для коригування асортименту, а не здогад.

Саме так автоматизація роботи закупівельника змінює роль людини: вона розбирає відхилення, а не шукає їх.

Методи збору даних: порівняння та обмеження

Вибір способу збору визначає не лише швидкість запуску, а й те, скільки часу піде на підтримку за пів року.

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

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

Дані з усіх джерел приводимо до єдиної схеми: артикул, майданчик, залишок, час заміру. Тоді збій одного каналу не завалює збір, а розходження між джерелами видно одразу.

Етапи розробки: від розбору задачі до запуску

Етапи розробки бота в нас ідуть у фіксованому порядку: спочатку домовляємося, що саме вважаємо наявністю, потім збираємо дані й лише після цього ставимо їх на розклад. Це знімає головний ризик — бота, який формально працює, але показує не те, що потрібно закупівлі.

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

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

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

• Вихідний код — репозиторій з історією змін, розділений на модулі: обхід джерел, розбір сторінок, зіставлення товарів, надсилання оповіщень.

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

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

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

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

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

• Зберігання історії — глибина зберігання знімків наявності та цін, розклад очищення, формат вивантаження для аналітики.

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

Кейс: контроль асортименту в роздрібній мережі

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

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

Що змінили

Зібрали парсер, який за розкладом обходить заданий список джерел — від сайтів постачальників до Яндекс Маркет — і порівнює наявність і ціну з попереднім знімком. Стан зберігаємо за кожною позицією: останнє значення, час зміни, джерело.

Розмітку описуємо конфігурацією селекторів окремо від логіки обходу, тому зміна верстки на боці джерела не завалює збір — виправляється один опис, без правок у коді.

Повтори невдалих запитів ідуть із наростаючою затримкою, а розходження між джерелами позначаються як підозрілі, а не як зміна наявності.

Що стало

Звірка займає 15–20 хвилин замість двох днів, а зведення надходить до відкриття зміни. Частка змін, спійманих за першу добу, зросла з 40% до 95% — закупівля реагує, поки конкурент ще не розібрав склад.

Ручних операцій стало в рази менше: менеджер розбирає лише підозрілі розходження, а не весь список. Коли в одного джерела двічі змінювалася розмітка, збір відновлювали за 20 хвилин правкою селекторів, без переписування логіки.

Чим відрізняється збір через програмний інтерфейс від обходу сторінок?

Якщо в магазину є програмний інтерфейс, наявність надходить готовими полями: залишок по складу, статус «в наявності» або «під замовлення», термін поставки.

Ми забираємо десятки й сотні позицій за один запит і отримуємо набір значень, який не залежить від того, як у цей момент відрендерена картка на сайті. Швидкість і стійкість збору тут максимальні, поки домовленість із джерелом не змінилася.

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

Тому стійкість збору тут тримається на правилах, прив’язаних до сенсу блоку й до сусідніх елементів, а не до конкретних назв класів, і на регулярній звірці з еталонними картками.

Програмний інтерфейс або обхід сторінок — це не вибір «або-або». Найчастіше основний канал — інтерфейс, а обхід працює страховкою: підтверджує наявність за точками продажів, які інтерфейс не покриває, і підстраховує, коли відповіді надходять із затримкою.

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

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

Сумніви щодо навантаження, блокувань і підтримки

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

Потік запитів тримаємо нижчим за той, що дає звичайний пошуковий робот, — навантаження на сайт конкурента залишається непомітним для його власника.

Нижче — сумніви, які найчастіше лунають до старту: блокування запитів, правові рамки збору, хибні спрацювання та підтримка після запуску.

Які правові рамки збору даних?

Працюємо лише з відкритими відомостями про наявність і ціну — без авторизації, особистих кабінетів і персональних даних. До кожного знімка зберігаємо адресу джерела та час отримання: це основа для звірки й розбору спірних випадків.

Як відсікаєте хибні спрацювання?

Зміна підтверджується повторним запитом за кілька хвилин і порівнянням із попереднім знімком. Якщо наявність повернулася до початкової, подія позначається шумом і в оповіщення не йде — у звіт потрапляють лише стійкі зміни.

Хто відповідає за роботу після запуску?

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

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

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

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

Із цим набором ми повертаємося з планом робіт: схема збору за кожним джерелом, етапи, склад команди, порядок перевірки даних на тестовій вибірці та умови супроводу після запуску. Опишіть задачу — надішлемо оцінку та план.