← Всички публикации
Случай на употреба 6 мин. четене

Изграждане на B2B pipeline за обогатяване на данни за компании

Трябва ли да обогатявате данни за хиляди компании ежедневно от директории, уебсайтове и пресата? Ето как да изградите B2B pipeline за обогатяване, който не се чупи всяка седмица.

b2blead generationdata enrichmentcompany enrichmentuse case

Предизвикателството

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

Данните съществуват. Те се намират в Crunchbase, на страниците „За нас“ на компаниите, на фирмените страници в LinkedIn, в Google Maps, в Glassdoor, в регионалните търговски регистри, в архивите на TechCrunch. Проблемът е в надеждното им извличане.

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

Така вашият pipeline за обогатяване започва като чист дизайн с пет източника. Шест месеца по-късно той е плетеница от наполовина счупени scrapers, опашки за повторни опити и Slack канал, наречен #scraper-alerts, който никой вече не отваря (вече сме писали за скритата цена на поддръжката на собствени scrapers). Оплакванията за качеството на данните се трупат в опашката за поддръжка. Екипът ви започва да се шегува, че името на компанията е трябвало да бъде „Пет scrapers и една молитва“.

Подходът

Забравете за scrapers за момент. Трудната част на обогатяването не е извличането. Тя е маршрутизирането: вземането на решение кой източник от кой инструмент, proxy, политика за повторен опит се нуждае и какво се счита за „добър“ response.

Платформа като FourA ви предоставя три продукта, които съответстват директно на трите класа източници, с които ще се сблъскате.

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

SPAs с интензивно използване на JavaScript. Приложения от типа на Crunchbase и LinkedIn, както и уебсайтове на средни по размер компании, няма да върнат желаните от вас данни от обикновен HTTP response. Те се рендерират на клиента. Това е Browser: пълен браузър изпълнява страницата, стартира JS и ви връща рендерирания HTML, cookies и екранни снимки. Подобно на Single, то маршрутизира през Proxy Finder под капака, без да е необходима отделна стъпка за избор от ваша страна.

Смесени източници с валидация. Всеки request към API на FourA приема validate блок. Можете да изисквате конкретни кодове за статус, съвпадения на header или съвпадения на поднизове в тялото. Ако response е soft-fail (страница с код 200, но с CAPTCHA, празна структура за данни или съобщение „съжаляваме“), валидаторът го отхвърля. След това вашият pipeline може да маршрутизира същия 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
  }'

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

Резултати

Наблюдавахме как няколко екипа преминаха от собствени scrapers към маршрутизиран през FourA pipeline по време на публичната бета версия. Моделът е постоянен (примерните числа са базирани на това, което видяхме в бета кохортата):

  • Enrichment latency спада от 3-6 секунди на компания до под 1.5 секунди медиана при cached-residential маршрути
  • Silent-failure rate (responses с код 200 и празни данни) спада от около 8% до под 1%, след като validate блокът улови soft-fails, преди да достигнат до базата данни
  • Инженерното време за поддръжка на scrapers спада от 1-2 инженери на пълно работно време до Slack канал, който през по-голямата част от времето мълчи
  • First-pass success rate при защитени директории се покачва до над 90%, когато unblocker: true е комбиниран с чист proxy id

Още едно число, което си струва да отбележим: видяхме, че коректността при първо преминаване (correctness) (правилните данни за правилната компания) изостава от успеха при първо преминаване (success) с около четири пункта. Изводът не е, че извличането на данни (scraping) е трудно. А че все още трябва да валидирате записа спрямо компанията, която действително сте поискали (писахме за този модел в защо вашият web scraper продължава да се чупи).

Числата, които имат значение, не са размерът на proxy pool или броят на requests. Това са процентът, при който вашият enrichment endpoint връща правилните данни от първия опит, и кривата на графиката за поддръжка на вашите scrapers през следващите шест месеца.

Основен извод

Pipelines за обогатяване се сриват бавно. Първият scraper, който напишете, изглежда добре във вторник. При третия източник вече пачвате селектори в 23:00 часа. При десетия вече носите дълг за поддръжка, който нараства пропорционално на вашата клиентска база. При двадесетия тихомълком сте спрели да добавяте нови източници, защото никой в екипа не иска да поеме отговорност за следващия.

Тясното място никога не е било в източника. То беше в маршрутизирането: изборът на правилния инструмент, правилното proxy, правилното правило за валидация за всеки URL, всеки път. Изградете този слой веднъж, поверете го на решение, което вече го прави, и вашият екип ще може да прекара вторник в работа по продукта, вместо да анализира счупени селектори.