← Alle Beiträge
Use Case 5 Min. Lesezeit

Aufbau einer B2B-Company-Enrichment-Pipeline

Du musst täglich Tausende Unternehmen aus Verzeichnissen, Websites und Presseberichten anreichern? Hier erfährst du, wie du eine B2B-Enrichment-Pipeline aufbaust, die nicht jede Woche ausfällt.

b2blead generationdata enrichmentcompany enrichmentuse case

Die Herausforderung

Du baust ein B2B-SaaS-Produkt. Deine Kunden laden eine Liste mit Unternehmensnamen hoch. Sie erwarten einen sauberen Datensatz zurück: Umsatzspanne, Mitarbeiterzahl, Tech-Stack, Finanzierungsrunde, wichtige Kontakte, aktuelle News. Sie erwarten das innerhalb von Minuten, nicht Tagen. Und sie erwarten, dass es stimmt.

Die Daten existieren. Sie liegen auf Crunchbase, auf Über-uns-Seiten von Unternehmen, auf LinkedIn-Unternehmensseiten, auf Google Maps, auf Glassdoor, in regionalen Handelsregistern, in TechCrunch-Archiven. Das Problem ist, zuverlässig an sie heranzukommen.

Jede Quelle verhält sich bei Fehlern anders. Crunchbase liefert eine schwere clientseitige App aus, die neu rendert, sobald sie einen Bot vermutet. LinkedIn nutzt aggressives Rate-Limiting und ändert sein DOM schneller, als du Selectors patchen kannst (ein bekannter Community-Post beziffert einen Standard-Python-Scraper auf etwa 50 Profile, bevor die Anti-Bot-Sperre greift). Unternehmenswebsites reichen von statischem HTML bis hin zu Single-Page-Apps, die einen vollwertigen Browser benötigen, um überhaupt Inhalte anzuzeigen. Regionale Verzeichnisse ändern vierteljährlich ihr Layout und sperren Zugriffe über länderspezifische Blockaden. Laut einem Branchenbericht von GroupBWT aus dem Jahr 2026 benötigen 10–15 % der Crawler in bestimmten Branchen wöchentliche Anpassungen, um mit Anti-Bot-Updates und DOM-Drift Schritt zu halten.

Deine Enrichment-Pipeline startet also als sauberes Design mit fünf Quellen. Sechs Monate später ist sie ein Geflecht aus halb defekten Scrapern, Retry-Queues und einem Slack-Kanal namens #scraper-alerts, den niemand mehr öffnet (wir haben bereits über die versteckten Kosten der Wartung eigener Scraper geschrieben). Beschwerden über die Datenqualität häufen sich in deiner Support-Queue. Dein Team scherzt bereits, dass das Unternehmen eigentlich „Fünf Scraper und ein Stoßgebet“ heißen müsste.

Der Ansatz

Vergiss die Scraper für einen Moment. Der schwierige Teil beim Enrichment ist nicht die Extraktion. Es ist das Routing: die Entscheidung, welche Quelle welches Tool, welchen Proxy, welche Retry-Policy benötigt und was als „gute“ Response gilt.

Eine Plattform wie FourA bietet dir drei Produkte, die genau zu den drei Quellklassen passen, auf die du stoßen wirst.

Statische HTML-Verzeichnisse und Register. Die meisten regionalen Handelsregister und viele ältere B2B-Verzeichnisse sind serverseitig gerendert. Sie verlangen einen schnellen, ressourcenschonenden HTTP-Request von einer sauberen IP. Das ist Single: eine URL rein, eine Response raus. Mit unblocker: true umgehst du Blockaden auf Handshake-Ebene, die einen Standard-HTTP-Client sofort stoppen. Single leitet automatisch über den Proxy Finder weiter und gibt die Proxy-ID auf der obersten Ebene der Response (r.proxy) zurück. So können deine Folgeaufrufe sie als proxy:"<id>" übergeben, um bei benötigter Sitzungskontinuität denselben Exit-Knoten zu nutzen.

JavaScript-lastige SPAs. Crunchbase, Apps im Stil von LinkedIn und selbst mittelgroße Unternehmenswebsites liefern bei einem einfachen HTTP-Request nicht die gewünschten Daten. Sie rendern auf dem Client. Das ist Browser: Ein vollwertiger Browser führt die Seite aus, lässt das JS laufen und liefert dir das gerenderte HTML, Cookies und Screenshots zurück. Wie Single leitet er im Hintergrund über den Proxy Finder weiter, ohne dass du einen separaten Auswahlschritt durchführen musst.

Gemischte Quellen mit Validierung. Jeder Request an die API von FourA akzeptiert einen validate-Block. Du kannst bestimmte Statuscodes, Header-Übereinstimmungen oder Substring-Treffer im Body vorschreiben. Wenn die Response ein Soft-Fail ist (eine 200er-Seite mit CAPTCHA, ein leeres Datengerüst oder eine „Es tut uns leid“-Zwischenseite), lehnt der Validator sie ab. Deine Pipeline kann dieselbe URL dann stattdessen über Browser leiten. Dieses eine Feature eliminiert die teuerste Fehlerklasse beim Enrichment: den Silent Failure, der fehlerhafte Daten in deine Datenbank schreibt.

So sieht ein Single-Source-Aufruf aus:

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

Und das Browser-Äquivalent für eine JavaScript-lastige Unternehmenswebsite:

curl -X POST https://api.foura.ai/api/browser \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

Die Routing-Logik liegt in deiner eigenen Pipeline. Die Zuverlässigkeit liegt in unserer. Du entscheidest, welche deiner Quellen welches Tool erhält. Wir sorgen dafür, dass das Tool auch wirklich durchkommt.

Ergebnisse

Wir haben während der öffentlichen Beta-Phase beobachtet, wie einige Teams von internen Scrapern auf eine über FourA geroutete Pipeline umgestellt haben. Das Muster ist konsistent (beispielhafte Zahlen basierend auf unseren Beobachtungen in der Beta-Kohorte):

  • Enrichment-Latenz sinkt von 3–6 Sekunden pro Unternehmen auf einen Median von unter 1,5 Sekunden bei Routen mit Cached-Residential-Proxys
  • Silent-Failure-Rate (200er-Responses mit leeren Daten) sinkt von rund 8 % auf unter 1 %, sobald der validate-Block Soft-Fails abfängt, bevor sie die Datenbank erreichen
  • Entwicklungszeit für die Scraper-Wartung sinkt von 1–2 Vollzeit-Entwicklern auf einen Slack-Kanal, der meistens ruhig bleibt
  • Erfolgsquote im ersten Versuch bei geschützten Verzeichnissen steigt auf über 90 %, wenn unblocker: true mit einer sauberen Proxy-ID kombiniert wird

Eine weitere Zahl, die man im Blick behalten sollte: Wir haben festgestellt, dass die Korrektheit im ersten Versuch (richtige Daten, richtiges Unternehmen) um etwa vier Prozentpunkte hinter dem Erfolg im ersten Versuch zurückbleibt. Die Lehre daraus ist nicht, dass Scraping schwer ist. Sondern dass du den Datensatz immer noch mit dem Unternehmen abgleichen musst, das du tatsächlich angefragt hast (wir haben über dieses Muster in Warum dein Web-Scraper ständig kaputtgeht geschrieben).

Die Zahlen, auf die es ankommt, sind nicht die Größe des Proxy-Pools oder die Anzahl der Requests. Es ist die Quote, mit der dein Enrichment-Endpoint beim ersten Versuch die richtigen Daten zurückgibt, und der Verlauf deiner Kurve für die Scraper-Wartung in den nächsten sechs Monaten.

Wichtigste Erkenntnis

Enrichment-Pipelines fallen in Zeitlupe aus. Der erste Scraper, den du schreibst, sieht an einem Dienstag noch gut aus. Bei der dritten Quelle patchst du um 23 Uhr Selectors. Bei der zehnten schleppst du eine Wartungsschuld mit dir herum, die mit deinem Kundenstamm wächst. Bei der zwanzigsten bindest du stillschweigend keine neuen Quellen mehr an, weil niemand im Team für die nächste verantwortlich sein will.

Der Flaschenhals war nie die Quelle. Es war das Routing: für jede URL und jedes Mal das richtige Tool, den richtigen Proxy und die richtige Validierungsregel auszuwählen. Baue diese Ebene einmal auf, übergib sie an einen Dienst, der das bereits erledigt, und dein Team kann den Dienstag für das Produkt nutzen, anstatt defekte Selectors zu analysieren.