← Все статьи
Вариант использования 5 минут чтения

Создание пайплайна обогащения B2B-данных

Нужно ежедневно обогащать данные о тысячах компаний из каталогов, сайтов и прессы? Рассказываем, как построить пайплайн обогащения B2B-данных, который не будет ломаться каждую неделю.

b2blead generationdata enrichmentcompany enrichmentuse case

Проблема

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

Данные существуют. Они находятся на Crunchbase, на страницах компаний «О нас», на страницах компаний в LinkedIn, в Google Maps, на Glassdoor, в региональных реестрах юридических лиц, в архивах TechCrunch. Проблема заключается в том, чтобы получать их надежно.

Каждый источник ломается по-своему. Crunchbase отдает тяжелое клиентское приложение, которое выполняет повторный рендеринг, если подозревает бота. LinkedIn агрессивно применяет rate limit и меняет DOM быстрее, чем вы успеваете обновлять селекторы (в одном популярном посте сообщества производительность стандартного парсера на Python оценивается примерно в 50 профилей до того, как сработает защита от ботов). Сайты компаний варьируются от статического HTML до одностраничных приложений, которым требуется полноценный браузер даже для отображения контента. Региональные каталоги меняют макеты каждый квартал и закрывают доступ с помощью блокировок по странам. Согласно отчету индустрии за 2026 год от GroupBWT, от 10 до 15% краулеров в некоторых вертикалях требуют еженедельных исправлений только для того, чтобы справляться с обновлениями систем защиты от ботов и изменениями DOM.

В итоге ваш конвейер обогащения начинается с аккуратной архитектуры на пять источников. Через шесть месяцев он превращается в клубок полурабочих парсеров, очередей повторных попыток и Slack-канала #scraper-alerts, который больше никто не открывает (ранее мы уже писали про скрытую стоимость поддержки собственных парсеров). Жалобы на качество данных копятся в очереди поддержки. Ваша команда начинает шутить, что компанию следовало назвать «Пять парсеров и одна молитва».

Подход

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

Платформа вроде FourA предлагает три продукта, которые напрямую соответствуют трем классам источников, с которыми вы столкнетесь.

Статические HTML-каталоги и реестры. Большинство региональных реестров юридических лиц и многие старые B2B-каталоги рендерятся на стороне сервера. Им требуется быстрый HTTP-request с низкими накладными расходами с чистого IP. Для этого подходит Single: один URL на входе, один response на выходе. Добавьте unblocker: true, и запрос обойдет блокировки на уровне рукопожатия (handshake), которые полностью останавливают стандартный HTTP-клиент. Single автоматически маршрутизирует запросы через Proxy Finder и возвращает proxy id на верхнем уровне ответа (r.proxy), чтобы ваши последующие вызовы могли передавать его обратно как proxy:"<id>" для сохранения того же выходного узла, когда требуется непрерывность сессии.

SPA с обилием JavaScript. Crunchbase, приложения в стиле LinkedIn и даже сайты средних компаний не вернут нужные данные в обычном HTTP-ответе. Они рендерятся на клиенте. Для этого подходит Browser: полноценный браузер загружает страницу, выполняет JS и возвращает вам отрендеренный HTML, cookies и скриншоты. Как и Single, он под капотом маршрутизирует запросы через Proxy Finder, исключая необходимость отдельного шага выбора с вашей стороны.

Смешанные источники с валидацией. Каждый request к API FourA принимает блок validate. Вы можете требовать определенные коды состояния, совпадения header или подстрок в теле ответа. Если response возвращает мягкую ошибку (страница с кодом 200 и CAPTCHA, пустая структура данных или промежуточная страница с извинениями), валидатор отклоняет его. После этого ваш конвейер может направить тот же URL через Browser. Эта единственная функция устраняет самый дорогой класс ошибок при обогащении: незаметный сбой, который записывает мусор в вашу базу данных.

Вот как выглядит вызов для одного источника:

curl -X POST https://api.foura.ai/api/single \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://registry.example.com/company/123",
    "unblocker": true,
    "followRedirects": 5,
    "validate": {
      "status": { "accept": [200] },
      "data":   { "fail":   ["captcha", "blocked", "access denied"] }
    }
  }'

И эквивалент для Browser для сайта компании с обилием JavaScript:

curl -X POST https://api.foura.ai/api/browser \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

Логика маршрутизации находится в вашем конвейере. Надежность обеспечивается на нашей стороне. Вы решаете, какой из ваших источников получает конкретный инструмент. Мы заботимся о том, чтобы инструмент действительно сработал.

Результаты

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

  • Задержка обогащения снижается с 3-6 секунд на компанию до медианы менее 1.5 секунд на маршрутах с кэшированными резидентными прокси
  • Частота незаметных сбоев (ответы с кодом 200 и пустыми данными) снижается с примерно 8% до менее 1%, как только блок validate начинает перехватывать мягкие ошибки до их попадания в базу данных
  • Время инженеров на поддержку парсеров сокращается с 1-2 штатных специалистов до Slack-канала, который большую часть времени молчит
  • Доля успешных запросов с первой попытки на защищенных каталогах возрастает до уровня выше 90%, когда параметр unblocker: true сочетается с чистым proxy id

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

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

Главный вывод

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

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