Чому парсер контактних даних ламається на живих джерелах
Живе відкрите джерело — не статична сторінка, а система, яка змінює розмітку без попередження: перейменували блок, додали обгортку, винесли пошту в підвантажуваний фрагмент.
Парсер контактних даних при цьому не падає — він повертає порожні картки, і обхід формально завершується успішно. Помилку помічають пізніше, на обдзвоні: у реєстрі не вистачає половини адрес, а логи виглядають чистими.
Далі починається нормалізація полів. Один і той самий номер приходить як «+7 (900) 000-00-00», «8 900 000 00 00» і «9000000000», пошта — з пробілом або великими літерами, посада злипається з назвою відділу в один рядок.
Без явних правил приведення значень дедуплікація за збігом рядків не працює, і одна людина потрапляє в базу два-три рази.
Блокування та ліміти додають другий шар відмов. Захист від автоматичного обходу ріже часті звернення, віддає замість сторінки заглушку або перевірку і змінює форму відповіді при тій самій адресі.
Парсер, який не розрізняє «контактів справді немає» і «нас відсікли на час», продовжує писати в реєстр порожні записи — на виході виходить обсяг, за яким немає даних.
Ціна таких відмов рахується не у відсотках, а в ручних годинах: оператор перевіряє записи, вичищає дублі та додзвонюється по неробочих каналах.
Стабільний збір контактів з відкритих джерел тримається не на одному вдалому запиті, а на контролі змін розмітки, явних правилах нормалізації та розборі відмов доступу. Далі розбираємо, як це закривається.
Що дає акуратний збір: швидкість, повнота, точність полів
Ручний обхід джерел впирається в арифметику: на картку йде хвилина-дві, за зміну набігає кілька сотень записів, і кожну переносять у таблицю руками. Звідти — одруки в номерах, різні формати запису одного телефону та дублі, які спливають вже на обдзвоні.
Список джерел і правила обходу задаються конфігурацією, а сторінки розбираються за структурою документа, а не за «приблизним» розташуванням блоків.
Якщо на сторінці є розмітка schema.org у структурованому вигляді, контакти беруться з неї напряму — без евристик по верстці, які ламаються при першому редизайні.
Зібране приводиться до єдиної схеми: телефони нормалізуються до одного формату і перевіряються за контрольною сумою, поштові адреси — за синтаксисом, дублі схлопуються за складеним ключем «організація + контакт».
На виході не сирий набір рядків, а реєстр, де запис валідний за побудовою. Повторний прогін оновлює лише змінені картки, тому актуальність підтримується без повного перезбирання.
За нашими вимірами виграш за швидкістю збору — восьми-десятикратний: обсяг, який при ручному обході розтягується на тижні, закривається за зміну.
До реєстру доходить понад дев'яносто відсотків карток, де контакти взагалі опубліковані, а ручних правок після імпорту залишаються одиниці відсотків — помилки введення перестають виникати на вході.
Режими збору: розбір розмітки, програмний інтерфейс, вивантаження
Три режими отримання даних не замінюють один одного: на одному наборі джерел працює один, на іншому — другий.
Вибір залежить від того, чи віддає джерело дані машинно, чи є в нього готове вивантаження і наскільки стабільна розмітка його сторінок — під кожен набір джерел підбирається свій режим.
Нижче — три режими і те, де кожен упирається в стелю.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Розбір розмітки | Джерело не віддає дані машинно, але контакти лежать на відкритих сторінках | Ламається при зміні верстки; потрібні свої правила обходу та обмеження частоти звернень на кожен шаблон сторінки |
| Програмний інтерфейс | Джерело публікує офіційний канал отримання даних і відкриває до нього доступ | Ліміти запитів і добові квоти, частина полів не віддається взагалі, схема відповіді змінюється з боку джерела |
| Готове вивантаження | Джерело саме публікує файл або архів з контактами | Періодичність задає джерело, формати та структура різні, вибрати тільки потрібні поля не можна — розбираємо весь обсяг |
На практиці набір джерел майже завжди змішаний, тому режими комбінуємо: де є програмний інтерфейс — ідемо через нього, решту закриваємо розбором розмітки, а рідкісні майданчики — готовим вивантаженням.
Ліміти запитів і правила обходу за кожним джерелом тримаємо в окремій конфігурації, а не в коді: правка при зміні верстки або квоти не вимагає перезбирання, а статистика за режимами показує, де просів відсоток зібраних контактів. Коли джерело змінює правила гри, режим за ним перемикається — інші продовжують працювати без змін.
Як ми ведемо впровадження: від аудиту джерел до передачі
Впровадження йде етапами, і кожен закінчується артефактом, який можна перевірити. Проєкт не перетворюється на чорну скриньку: видно, звідки приходять дані, за якими правилами збираються і як контролюється якість.
- Аудит джерел. Зводимо майданчики в таблицю: обсяг видачі, умови використання, наявність відкритого програмного інтерфейсу, стабільність верстки. Джерела без прав на збір відсіюємо відразу — інакше обхід доведеться переписувати.
- Схема обходу. Черга запитів з обмеженням частоти, обхід пагінації, повторні спроби при збоях. Для сторінок з динамічною відрисовкою — рендер, для каталогів — обхід за списками розділів і карток.
- Витяг полів. Контакти дістаємо за контекстом блоку, а не за всім текстом сторінки: значення з шапки картки і з рекламного блоку — різні сутності.
- Нормалізація. Телефони — до єдиного формату з кодом країни, пошти — до нижнього регістру, адреси — до структури регіон/місто/вулиця. Дублі склеюємо за складеним ключем.
- Перевірка на еталонній вибірці. Контрольний набір розмічаємо вручну і звіряємо: частка правильних значень, частка пропусків, хибні спрацювання. Нижче порогу правимо правила, а не добираємо обсяг.
- Передача в роботу. Віддаємо код, конфігурації джерел, розклад запусків і звіт за якістю. Показуємо вашим інженерам, як підключити нове джерело і розібрати збій.
Далі — підтримка: регулярні прогони, оповіщення при падінні частки валідних записів і оновлення правил під зміни верстки.
Що залишається у вас: конфігурації, схеми, регламенти, доступи
Передаємо не «працюючий скрипт», а набір артефактів, за якими парсер контактних даних можна запускати, перевіряти і розвивати без нас. Кожен пункт проходить приймання на вашій стороні: ми показуємо, де він лежить, як ним користуватися і що станеться при зміні розмітки джерела.
- Робочі конфігурації — правила розбору за кожним джерелом, розклад, затримки між запитами, обмеження паралелізму, повторні спроби при збоях і перелік адрес, з яких іде обхід.
- Схема джерел — карта, де за кожним джерелом вказано тип, спосіб доступу, частоту оновлення, набір полів, що витягуються, і типові зміни розмітки, які ламають розбір.
- Права доступу та правовий режим — які джерела відкриті для збору, обмеження за частотою звернень, окремі облікові записи для сервісу, ключі в захищеному сховищі, а не в коді і не в логах.
- Модель даних і нормалізація — приведення телефонів, пошти та адрес до єдиного вигляду, правило дедуплікації записів, пріоритет полів при розбіжності даних між джерелами.
- Регламент запуску — робота за розкладом або на вимогу, порядок перегляду звіту про прогін, дії при блокуванні джерела та точки ескалації всередині вашої команди.
- Документація — опис полів і форматів вивантаження, приклади запитів, інструкція з підключення нового джерела правкою конфігурації, без зміни коду.
- Перевірки та моніторинг — еталонна вибірка з очікуваним результатом, сигнал при падінні частки успішних розборів, журнал змін конфігурацій з можливістю відкату.
Далі сервіс живе за вашим регламентом: оновлення правил при зміні розмітки, додавання джерел, ротація доступів. Якщо знадобиться допомога — підключимося до вже задокументованої системи, а не до чужого коду без опису.
Кейс: реєстр за каталогом постачальників, метрики до та після
Що було і що змінили
У замовника — каталог постачальників промислового обладнання на кілька тисяч позицій, а контакти відділів закупівель збирали вручну: два співробітники обходили сайти і переносили дані в таблицю.
На сотню карток йшов майже робочий день, при повторному обході до третини записів виявлялися застарілими, а частина компаній у реєстр не потрапляла взагалі. Повноту ніхто не вимірював — втрачені позиції просто не помічали.
Зібрали парсер контактних даних з відкритих джерел: обхід каталогу за розділами та витяг полів з розмітки сторінок через Schema.org там, де вона є, і за контактними блоками — де її немає.
Кожен запис зберігає адресу джерела та дату збору, дублі склеюються за доменом і назвою компанії, спірні збіги йдуть у чергу на ручну перевірку. Обхід іде за розкладом, тому реєстр оновлюється, а не збирається заново щоразу.
Метрики до та після
Повний прогін за каталогом займає близько двох годин проти тижнів ручної вибірки, від співробітників залишається тільки перевірка звіту. Повнота реєстру виросла з 71% до 96% — різницю показав звіряльний прогін за контрольною вибіркою компаній.
Частка дублів впала з 18% до 2%, у 100% записів є підтверджене джерело, а зниження ручної праці видно за кількістю правок після кожного обходу.
Де парсер поступається програмному інтерфейсу і чому?
Програмний інтерфейс виграє там, де він є і покриває потрібні поля. Джерело віддає дані в узгодженому вигляді: структура відповіді описана, поля підписані, ліміти звернень відомі з документації. Поки це так, розбір розмітки — зайвий шар, який додає тільки точки відмови.
Розбір розмітки надійніший у зворотній ситуації: інтерфейсу немає взагалі, він закритий платним тарифом, обмежений за кількістю звернень або віддає урізаний набір полів. Тоді публічні сторінки — єдиний доступний канал, і дані знімаються звідти з приведенням до своєї схеми.
Ціна такого рішення — залежність від верстки джерела. Зміна шаблону або редизайн ламають правила розбору, тому потрібні регулярні перевірки, контроль порожніх вибірок і сигнал про падіння частки знайдених контактів. Інтерфейс ламається передбачувано — кодом помилки у відповіді, а не тихою втратою даних.
Обмеження джерел впливають на вибір не менше. Капча, блокування за адресою та за поведінкою, вимога авторизації змушують вести розбір повільно, з паузами, інакше джерело починає віддавати заглушки. У програмного інтерфейсу ті самі рамки виражені явно — лімітом звернень за одиницю часу.
Тому підхід обираємо від задачі. Спочатку перевіряємо, чи є програмний інтерфейс і чи закриває він потрібні поля; якщо так — будуємо на ньому. Якщо ні або він вузький — розбір розмітки, але з прошарком нормалізації, щоб зміна джерела не руйнувала весь контур. Найчастіше виходить гібрид: інтерфейс дає основний обсяг, розбір добирає те, чого не вистачає.
Технічні сумніви: якість полів, блокування, повтори
Сумніви щодо якості даних виникають раніше, ніж починається розробка, і це нормально: від відповідей залежить і схема зберігання, і обсяг підтримки. Нижче — три питання, які задають найчастіше, і як вони закриваються в коді, а не на словах.
Звідки беруться дублі та застарілі записи?
Порівнюємо не рядок цілком, а нормалізований ключ: телефон приводиться до єдиного вигляду, домен пошти — до нижнього регістру, компанія — до канонічної назви. Збіг за ключем плюс поріг схожості назви відправляє запис на злиття, а не в базу.
Застарілі записи не видаляються: у контакту з'являється позначка останнього підтвердження, і якщо він не зустрічається в джерелах за заданий період, позначається як неактуальний — історія зберігається.
Що буде при зміні розмітки сайту-джерела?
Правила витягу полів винесені в окремі конфігурації, тому правка займає години, а не переписування парсера.
Кожен прогін рахує частку розпізнаних полів — падіння нижче порогу піднімає сигнал, і про зміну ми дізнаємось раніше, ніж замовник відкриє вивантаження з порожніми колонками. Сторінки, які домальовуються скриптами, обробляються через Playwright.
Як обмежити охоплення та підтвердити точність?
Охоплення задається списком джерел, регіонами та тематикою — збір іде не по всьому інтернету. Точність підтверджується контрольною вибіркою: частина записів перевіряється вручну, і у звіт потрапляє частка підтверджених телефонів і адрес, а не загальна кількість рядків.
Обговоримо задачу: зберемо схему збору під ваші джерела
Щоб повернутися з оцінкою обсягу, а не із загальними словами, нам потрібні ввідні по вашій задачі. Нижче — перелік того, що знімає основну невизначеність: з ним ми відразу рахуємо трудовитрати, обираємо спосіб збору і збираємо план робіт під конкретні джерела та склад реєстру.
- Джерела: каталоги, майданчики оголошень, галузеві довідники, реєстри — і чи є у вас діючі доступи або підписки на них.
- Склад реєстру: які поля обов'язкові (назва, контактна особа, телефон, пошта, адреса, сфера діяльності), які — за можливості.
- Правила зведення дублів: за якою ознакою вважаємо два записи однією компанією — збіг телефону, адреси або назви.
- Обсяг і періодичність: потрібен разовий зріз або регулярне оновлення, скільки записів очікуєте на виході.
- Що вже напрацьовано: попередні вивантаження, таблиці, бази — щоб не перезбирати те, що працює.
- Межі допустимого: які джерела і поля ви не берете за своїми внутрішніми правилами.
- Що далі з даними: формат вивантаження, куди складаємо, хто і за якими полями шукає.
Надішліть те, що є, навіть у чернетковому вигляді, — повернемося з оцінкою обсягу, термінами за етапами та зрозумілим планом робіт. Якщо за частиною пунктів ясності немає, розберемо їх на обговоренні та зафіксуємо домовленості письмово.
