← 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 B2B SaaS. Twoi klienci przesyłają listę nazw firm. Oczekują w zamian czystego rekordu: przedziału przychodów, liczby pracowników, stosu technologicznego, rundy finansowania, kluczowych kontaktów, najnowszych wiadomości. Oczekują tego w ciągu kilku minut, a nie dni. I oczekują, że dane będą poprawne.

Dane istnieją. Znajdują się na Crunchbase, na stronach informacyjnych firm, na stronach firmowych LinkedIn, na Google Maps, na Glassdoor, w regionalnych rejestrach biznesowych, w archiwach TechCrunch. Problemem jest niezawodne dotarcie do nich.

Każde źródło psuje się inaczej. Crunchbase serwuje ciężką aplikację po stronie klienta, która renderuje się ponownie, jeśli podejrzewa bota. LinkedIn agresywnie ogranicza ruch i zmienia swój DOM szybciej, niż jesteś w stanie łatać selektory (jeden z popularnych postów społecznościowych ocenia prosty scraper w Pythonie na około 50 profili przed zablokowaniem). Strony firmowe to zarówno statyczny HTML, jak i aplikacje typu single-page, 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 dla określonych krajów. Według raportu branżowego 2026 od GroupBWT od 10 do 15% crawlerów w niektórych branżach potrzebuje cotygodniowych poprawek, aby nadążyć za aktualizacjami antybotowymi i zmianami w DOM.

Twój potok wzbogacania zaczyna się jako czysty projekt oparty na pięciu źródłach. Sześć miesięcy później to plątanina w połowie działających scraperów, kolejek ponownych prób i kanału na Slacku o nazwie #scraper-alerts, którego nikt już nie otwiera (pisaliśmy już o ukrytych kosztach utrzymania własnych scraperów). Skargi na jakość danych piętrzą się w kolejce wsparcia. Twój zespół zaczyna żartować, że nazwa firmy powinna brzmieć "Pięć Scraperów i Modlitwa".

Podejście

Zapomnij na chwilę o scraperach. Najtrudniejszą częścią wzbogacania nie jest ekstrakcja. Jest nią routing: decydowanie, które źródło potrzebuje jakiego narzędzia, jakiego proxy, jakiej polityki ponownych prób i co liczy się jako "dobra" odpowiedź.

Platforma taka jak FourA daje ci trzy produkty, które mapują się bezpośrednio na trzy klasy źródeł, do których będziesz uderzać.

Statyczne katalogi HTML i rejestry. Większość regionalnych rejestrów firmowych i wiele starszych katalogów B2B jest renderowanych na serwerze. Potrzebują szybkiego, lekkiego żądania HTTP z czystego IP. To zadanie dla Single: jeden URL na wejściu, jedna odpowiedź na wyjściu. Dodaj unblocker: true, a przejdziesz przez blokady na poziomie handshake, które całkowicie zatrzymują zwykłego klienta HTTP. Single automatycznie korzysta z Proxy Finder i zwraca id proxy na najwyższym poziomie odpowiedzi (r.proxy), więc kolejne żądania mogą przekazać je z powrotem jako proxy:"<id>", aby zachować ciągłość sesji, gdy jej potrzebujesz.

Ciężkie aplikacje SPA w JavaScript. Crunchbase, aplikacje w stylu LinkedIn, a nawet strony średnich firm nie zwrócą żądanych danych ze zwykłej odpowiedzi HTTP. Renderują się po stronie klienta. To zadanie dla Browser: pełna przeglądarka wykonuje stronę, uruchamia JS i zwraca wyrenderowany HTML, pliki cookie i zrzuty ekranu. Podobnie jak Single, Browser pod spodem kieruje ruch przez Proxy Finder, bez oddzielnego kroku wyboru po twojej stronie.

Mieszane źródła z walidacją. Każde żądanie do API FourA akceptuje blok validate. Możesz wymagać określonych kodów statusu, dopasowań nagłówków lub dopasowań podciągów w treści. Jeśli odpowiedź to miękki błąd (strona 200 z CAPTCHA, pusta struktura danych lub komunikat "przepraszamy"), walidator ją odrzuca. Twój potok może wtedy skierować ten sam URL do Browser. Ta jedna funkcja eliminuje najdroższą klasę błędów we wzbogacaniu: ciche błędy, które zapisują śmieci do bazy danych.

Oto kształt wywołania 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 to odpowiednik Browser dla strony firmowej silnie obciążonej JavaScriptem:

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 znajduje się w twoim własnym potoku. Niezawodność leży po naszej stronie. Ty decydujesz, które z twoich źródeł dostanie które narzędzie. My upewniamy się, że narzędzie faktycznie dotrze do celu.

Wyniki

Obserwowaliśmy, jak garstka zespołów przechodzi z własnych scraperów na potok kierowany przez FourA podczas publicznej bety. Wzorzec jest spójny (ilustracyjne liczby oparte na tym, co widzieliśmy w kohorcie beta):

  • Opóźnienie wzbogacania spada z 3 do 6 sekund na firmę do mediany poniżej 1.5 sekundy na buforowanych trasach domowych
  • Wskaźnik cichych błędów (odpowiedzi 200 z pustymi danymi) spada z około 8% do poniżej 1%, gdy blok validate wychwytuje miękkie błędy, zanim dotrą do bazy danych
  • Czas inżynierów poświęcony na utrzymanie scraperów spada z 1 do 2 pełnoetatowych inżynierów do kanału na Slacku, na którym zazwyczaj panuje cisza
  • Wskaźnik sukcesu pierwszego przejścia na chronionych katalogach rośnie do wysokich wartości rzędu 90%, gdy unblocker: true jest połączony z czystym id proxy

Jeszcze jedna liczba warta odnotowania: widzieliśmy, że poprawność pierwszego przejścia (właściwe dane, właściwa firma) pozostaje w tyle za sukcesem pierwszego przejścia o około cztery punkty. Z tego płynie nauka, że nie tyle scraping jest trudny. Po prostu nadal musisz zweryfikować rekord pod kątem firmy, o którą faktycznie pytałeś (pisaliśmy o tym wzorcu w dlaczego twój web scraper ciągle się psuje).

Liczby, które mają znaczenie, to nie rozmiar puli proxy ani liczba żądań. To wskaźnik, w jakim twój endpoint wzbogacający zwraca właściwe dane przy pierwszej próbie, oraz spadek krzywej na wykresie kosztów utrzymania scraperów w ciągu najbliższych sześciu miesięcy.

Kluczowe wnioski

Potoki wzbogacania psują się w zwolnionym tempie. Pierwszy napisany przez ciebie scraper we wtorek wygląda dobrze. Przy trzecim źródle łatasz selektory o 23:00. Przy dziesiątym ponosisz dług technologiczny, który skaluje się wraz z bazą klientów. Przy dwudziestym po cichu przestałeś wdrażać nowe źródła, ponieważ nikt w zespole nie chce brać na siebie kolejnego.

Wąskim gardłem nigdy nie było źródło. Był nim routing: wybór właściwego narzędzia, właściwego proxy, właściwej reguły walidacji dla każdego URL, za każdym razem. Zbuduj tę warstwę raz, przekaż ją czemuś, co już to robi, a twój zespół będzie mógł we wtorek zająć się produktem, zamiast analizować popsute selektory.