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

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

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

b2blead generationdata enrichmentcompany enrichmentuse case

Проблема

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

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

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

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

Подход

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

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

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

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

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

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

curl -X POST https://api.foura.ai/api/single \
  -H "X-API-Key: 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 "X-API-Key: pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

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

Результаты

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

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

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

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

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

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

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