← Wszystkie wpisy
Zastosowanie 5 min czytania

Budowa potoku wzbogacania danych firm B2B

Musisz codziennie wzbogacać dane tysięcy firm na podstawie katalogów, stron internetowych i prasy? Oto jak zbudować potok wzbogacania B2B, który nie psuje się co tydzień.

b2blead generationdata enrichmentcompany enrichmentuse case

Wyzwanie

Budujesz produkt SaaS B2B. Twoi klienci przesyłają listę nazw firm. Oczekują w zamian uporządkowanego rekordu: przedziału przychodów, liczby pracowników, stosu technologicznego, rundy finansowania, kluczowych kontaktów, ostatnich wiadomości. Oczekują tego w kilka minut, nie dni. I oczekują, że dane będą poprawne.

Dane istnieją. Znajdują się na Crunchbase, na stronach firmowych "O nas", na profilach firmowych na LinkedIn, w Google Maps, na Glassdoor, w regionalnych rejestrach działalności gospodarczej, w archiwach TechCrunch. Problem polega na ich niezawodnym pozyskaniu.

Każde źródło psuje się inaczej. Crunchbase serwuje ciężką aplikację po stronie klienta, która renderuje się ponownie przy podejrzeniu bota. LinkedIn agresywnie nakłada rate limit i zmienia swój DOM szybciej, niż zdążysz poprawić selektory (jeden z popularnych postów społeczności wskazuje w testach, że zwykły scraper w Pythonie radzi sobie ze średnio 50 profilami, zanim strona zacznie odrzucać żądania). Strony firmowe wahają się od statycznego HTML po aplikacje Single Page App, które wymagają pełnej przeglądarki, aby w ogóle wyświetlić treść. Regionalne katalogi zmieniają układy co kwartał i blokują dostęp na poziomie konkretnych krajów. Według raportu branżowego GroupBWT z 2026 roku, 10-15% crawlerów w niektórych branżach wymaga cotygodniowych poprawek tylko po to, by nadążyć za zmianami w wykrywaniu botów i dryfem DOM.

Twój pipeline wzbogacania danych zaczyna się więc jako czysty projekt oparty na pięciu źródłach. Sześć miesięcy później to plątanina w połowie niedziałających scraperów, kolejek retry i kanału na Slacku o nazwie #scraper-alerts, którego nikt już nie otwiera (pisaliśmy już wcześniej o ukrytych kosztach utrzymywania własnych scraperów). Zgłoszenia dotyczące jakości danych piętrzą się w systemie wsparcia. Twój zespół zaczyna żartować, że firma powinna nazywać się "Pięć scraperów i modlitwa".

Podejście

Zapomnij na chwilę o scraperach. Trudna część wzbogacania danych to nie ekstrakcja. To routing: decydowanie, które źródło wymaga jakiego narzędzia, jakiego proxy, jakiej polityki ponawiania i co uznaje się za "poprawną" odpowiedź.

Platforma taka jak FourA daje Ci trzy produkty, które mapują się bezpośrednio na trzy klasy źródeł, z którymi będziesz mieć do czynienia.

Statyczne katalogi HTML i rejestry. Większość regionalnych rejestrów działalności gospodarczej i wiele starszych katalogów B2B jest renderowanych po stronie serwera. Wymagają szybkiego requestu HTTP o niskim narzucie z czystego adresu IP. Do tego służy Single: jeden URL na wejściu, jedna odpowiedź na wyjściu. Dodaj unblocker: true, a ominie blokady na poziomie handshake'a, które natychmiast zatrzymują standardowego klienta HTTP. Single automatycznie kieruje ruch przez Proxy Finder i zwraca identyfikator proxy na najwyższym poziomie odpowiedzi (r.proxy), dzięki czemu kolejne wywołania mogą przekazać go jako proxy:"<id>", aby zachować ten sam węzeł wyjściowy, gdy potrzebujesz ciągłości sesji.

Aplikacje SPA oparte na JavaScript. Crunchbase, serwisy w stylu LinkedIn, a nawet strony średnich firm nie zwrócą potrzebnych danych ze zwykłej odpowiedzi HTTP. Renderują się one po stronie klienta. Do tego służy Browser: pełna przeglądarka uruchamia stronę, wykonuje JS i zwraca wyrenderowany HTML, pliki cookie oraz zrzuty ekranu. Podobnie jak Single, pod maską korzysta z Proxy Finder, bez konieczności ręcznego dobierania proxy po Twojej stronie.

Mieszane źródła z walidacją. Każde żądanie do API FourA przyjmuje blok validate. Możesz wymagać określonych kodów statusu, dopasowań nagłówków lub podciągów znaków w treści. Jeśli odpowiedź to pozorny sukces (strona 200 z prośbą o weryfikację, pusty szablon danych lub komunikat "przepraszamy"), walidator ją odrzuca. Twój pipeline może wtedy przekierować ten sam URL przez Browser. Ta jedna funkcja eliminuje najbardziej kosztowną klasę błędów we wzbogacaniu danych: cichą awarię, która zapisuje śmieci w bazie danych.

Oto struktura wywołania z pojedynczego źródła:

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"] }
    }
  }'

Oraz odpowiednik w Browser dla witryny firmowej intensywnie korzystającej z 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
  }'

Logika routingu działa w Twoim własnym pipeline. Niezawodność leży po naszej stronie. Ty decydujesz, które z Twoich źródeł otrzymuje dane narzędzie. My dbamy o to, aby narzędzie faktycznie dotarło do celu.

Wyniki

Obserwowaliśmy kilka zespołów przechodzących z własnych scraperów na pipeline oparty na FourA podczas publicznej bety. Wzorzec jest spójny (dane poglądowe na podstawie wyników z kohorty beta):

  • Opóźnienie wzbogacania danych (enrichment latency) spada z 3-6 sekund na firmę do mediany poniżej 1,5 sekundy na trasach cached-residential
  • Wskaźnik cichych błędów (silent-failure rate) (odpowiedzi 200 z pustymi danymi) spada z około 8% do poniżej 1%, gdy blok validate wyłapuje soft-faile przed trafieniem do bazy danych
  • Czas inżynierów poświęcany na utrzymanie scraperów spada z 1-2 pełnoetatowych inżynierów do kanału na Slacku, na którym panuje głównie cisza
  • Wskaźnik sukcesu przy pierwszej próbie (first-pass success rate) w chronionych katalogach rośnie do wysokich wartości rzędu 90+%, gdy unblocker: true jest połączone z czystym proxy id

Jeszcze jedna liczba warta uwagi: zaobserwowaliśmy, że poprawność przy pierwszej próbie (właściwe dane, właściwa firma) odstaje od sukcesu przy pierwszej próbie o około cztery punkty procentowe. Wniosek nie jest taki, że scraping jest trudny. Chodzi o to, że nadal musisz weryfikować rekord pod kątem firmy, o którą faktycznie pytałeś (pisaliśmy o tym wzorcu w artykule dlaczego Twój web scraper ciągle się psuje).

Liczby, które mają znaczenie, to nie wielkość puli proxy ani liczba requestów. To odsetek sytuacji, w których Twój endpoint do wzbogacania danych zwraca właściwe dane za pierwszym razem, oraz nachylenie wykresu utrzymania scraperów w ciągu kolejnych sześciu miesięcy.

Kluczowy wniosek

Pipeline'y wzbogacania danych zawodzą powoli. Pierwszy scraper, który napiszesz, wygląda świetnie we wtorek. Przy trzecim źródle łatasz selektory o 23:00. Przy dziesiątym dźwigasz dług techniczny utrzymania, który rośnie wraz z bazą klientów. Przy dwudziestym po cichu przestajesz dodawać nowe źródła, bo nikt w zespole nie chce brać odpowiedzialności za kolejne.

Wąskim gardłem nigdy nie było samo źródło. Był nim routing: dobór odpowiedniego narzędzia, odpowiedniego proxy i właściwej reguły walidacji dla każdego adresu URL, za każdym razem. Zbuduj tę warstwę raz, przekaż ją systemowi, który już to robi, a Twój zespół będzie mógł spędzić wtorek nad produktem zamiast diagnozować uszkodzone selektory.