← Wszystkie wpisy
Zastosowanie 5 min czytania

Budowanie pipeline'u do wzbogacania danych firm B2B

Musisz codziennie wzbogacać dane tysięcy firm z katalogów, stron WWW i prasy? Oto jak zbudować pipeline do enrichmentu B2B, który nie sypie się co tydzień.

b2blead generationdata enrichmentcompany enrichmentuse case

Wyzwanie

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

Te dane istnieją. Znajdziesz je na Crunchbase, podstronach „O nas”, profilach firmowych na LinkedIn, w Google Maps, na Glassdoor, w krajowych rejestrach handlowych i archiwach TechCrunch. Problem polega na ich stabilnym pozyskiwaniu.

Każde źródło sypie się inaczej. Crunchbase serwuje ciężką aplikację kliencką, która renderuje się ponownie, jeśli podejrzewa bota. LinkedIn agresywnie nakłada rate limit i zmienia swój DOM szybciej, niż nadążasz z poprawianiem selektorów (jeden z popularnych postów społecznościowych wskazuje w benchmarku, że zwykły scraper w Pythonie wyciąga około 50 profili, zanim uderzy w ścianę zabezpieczeń anty-botowych). Strony firmowe to przekrój od statycznego HTML po aplikacje SPA, które wymagają pełnej przeglądarki, żeby w ogóle wyświetlić zawartość. Lokalne rejestry zmieniają układy stron co kwartał i blokują ruch spoza danego kraju. 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 aktualizacjami systemów anty-botowych i zmianami w DOM.

Twój pipeline do enrichmentu zaczyna więc jako elegancki projekt oparty na pięciu źródłach. Pół roku później to już plątanina na wpół działających scraperów, kolejek retry i kanału na Slacku o nazwie #scraper-alerts, którego nikt już nawet nie otwiera (pisaliśmy już wcześniej o ukrytych kosztach utrzymywania własnych scraperów). Skargi na jakość danych piętrzą się w kolejce zgłoszeń wsparcia. Twój zespół zaczyna żartować, że firma powinna nazywać się „Pięć scraperów i zdrowaśka”.

Podejście

Zapomnij na chwilę o scraperach. Najtrudniejszą częścią enrichmentu nie jest ekstrakcja danych. Jest nią routing: decydowanie, które źródło wymaga jakiego narzędzia, jakiego proxy, jakiej polityki ponawiania prób (retry policy) i co właściwie uznajemy za „dobrą” odpowiedź.

Platforma taka jak FourA daje Ci trzy produkty, które bezpośrednio odpowiadają trzem klasom źródeł, na jakie natrafisz.

Statyczne katalogi i rejestry HTML. Większość lokalnych rejestrów działalności gospodarczej i wiele starszych katalogów B2B jest renderowanych po stronie serwera. Wymagają szybkiego, lekkiego żądania HTTP z czystego IP. Do tego służy Single: jeden URL na wejściu, jedna odpowiedź na wyjściu. Dodaj unblocker: true, a ominiesz blokady na poziomie handshake'u, które natychmiast zatrzymują zwykłego 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 z powrotem jako proxy:"<id>", aby zachować ten sam punkt wyjścia, gdy potrzebujesz ciągłości sesji.

Aplikacje SPA przeładowane JavaScriptem. Crunchbase, platformy typu LinkedIn, a nawet witryny ś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 przetwarza stronę, uruchamia JS i zwraca wyrenderowany HTML, pliki cookie oraz zrzuty ekranu. Podobnie jak Single, pod maską korzysta z Proxy Finder, więc nie musisz samodzielnie wybierać proxy.

Mieszane źródła z walidacją. Każde zapytanie do API FourA przyjmuje blok validate. Możesz wymagać konkretnych kodów statusu, dopasowań nagłówków lub podciągów znaków w treści. Jeśli odpowiedź to soft-fail (strona z kodem 200, ale z CAPTCHA, pusty szablon danych lub komunikat „przepraszamy”), walidator ją odrzuci. Twój pipeline może wtedy skierować ten sam URL do modułu Browser. Ta jedna funkcja eliminuje najbardziej kosztowną klasę błędów w enrichmencie: cichy błąd (silent failure), który zapisuje śmieci w Twojej bazie danych.

Tak wygląda wywołanie dla pojedynczego źródła:

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

A oto odpowiednik Browser dla strony firmowej opartej na 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
  }'

Logika routingu leży po Twojej stronie. Niezawodność po naszej. Ty decydujesz, które ze źródeł trafia do jakiego narzędzia. My dbamy o to, by narzędzie rzeczywiście się przebiło.

Wyniki

W trakcie publicznej bety obserwowaliśmy, jak kilka zespołów przeszło z własnych scraperów na pipeline sterowany przez FourA. Schemat jest powtarzalny (poniższe liczby mają charakter poglądowy i bazują na danych z grupy beta):

  • Opóźnienie enrichmentu (latency) spada z 3–6 sekund na firmę do mediany poniżej 1,5 sekundy na trasach typu 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 wychwytuje soft-faile, zanim trafią do bazy danych
  • Czas inżynieryjny poświęcany na utrzymanie scraperów spada z 1–2 etatów programistów do kanału na Slacku, na którym panuje niemal całkowita cisza
  • Wskaźnik sukcesu przy pierwszej próbie (first-pass success rate) na zabezpieczonych katalogach rośnie do ponad 90%, gdy unblocker: true jest połączony z czystym identyfikatorem proxy

Warto wspomnieć o jeszcze jednej liczbie: zauważyliśmy, że poprawność przy pierwszej próbie (właściwe dane, właściwa firma) zostaje w tyle za sukcesem przy pierwszej próbie o około cztery punkty procentowe. Wniosek nie jest taki, że scraping jest trudny. Chodzi o to, że nadal musisz zweryfikować rekord pod kątem firmy, o którą faktycznie pytałeś (opisaliśmy ten schemat w artykule dlaczego Twój scraper ciągle się psuje).

Liczby, które naprawdę się liczą, to nie wielkość puli proxy czy liczba żądań. To odsetek sytuacji, w których Twój endpoint do enrichmentu zwraca właściwe dane przy pierwszej próbie, oraz nachylenie wykresu czasu poświęcanego na utrzymanie scraperów w ciągu kolejnych sześciu miesięcy.

Kluczowy wniosek

Pipeline'y do enrichmentu psują się powoli. Pierwszy scraper, którego napiszesz, we wtorek wygląda świetnie. Przy trzecim źródle łatasz selektory o 23:00. Przy dziesiątym dźwigasz dług technologiczny związany z utrzymaniem, 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ć za nie odpowiedzialności.

Wąskim gardłem nigdy nie było samo źródło. Był nim routing: wybó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ą rozwiązaniu, które już to robi, a Twój zespół będzie mógł spędzić wtorek na pracy nad produktem zamiast na analizowaniu, dlaczego znowu posypały się selektory.