← Alle Beiträge
Use Case 5 Min. Lesezeit

Aufbau einer B2B-Company-Enrichment-Pipeline

Du musst täglich Tausende von Unternehmen aus Verzeichnissen, Websites und der Presse anreichern? So baust du eine B2B-Enrichment-Pipeline, die nicht jede Woche kaputtgeht.

b2blead generationdata enrichmentcompany enrichmentuse case

Die Herausforderung

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

Die Daten existieren. Sie liegen auf Crunchbase, auf den Über-uns-Seiten der 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 geht auf andere Weise kaputt. Crunchbase liefert eine schwere clientseitige App, die neu rendert, wenn sie einen Bot vermutet. LinkedIn hat ein aggressives Rate Limit und ändert seinen DOM schneller, als du Selektoren patchen kannst (ein bekannter Community-Beitrag bencht einen einfachen Python-Scraper bei etwa 50 Profilen, bevor die Anti-Bot-Wand fällt). Unternehmenswebsites reichen von statischem HTML bis zu Single-Page-Apps, die einen vollständigen Browser benötigen, um überhaupt Inhalte anzuzeigen. Regionale Verzeichnisse rotieren ihre Layouts jedes Quartal und nutzen länderspezifische Blockaden. Laut einem 2026 Branchenbericht von GroupBWT benötigen 10 bis 15 % der Crawler in manchen Branchen wöchentliche Fixes, nur um mit Anti-Bot-Updates und DOM-Drift Schritt zu halten.

Deine Enrichment-Pipeline beginnt also als sauberes Design mit fünf Quellen. Sechs Monate später ist es ein Gewirr aus halb kaputten 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 macht Witze, dass der Firmenname "Five Scrapers and a Prayer" hätte lauten sollen.

Der Ansatz

Vergiss die Scraper für einen Moment. Der schwierige Teil des Enrichments ist nicht die Extraktion. Es ist das Routing: die Entscheidung, welche Quelle welches Tool, welchen Proxy und welche Retry-Policy benötigt und was als "gute" Response zählt.

Eine Plattform wie FourA bietet dir drei Produkte, die direkt auf die drei Quellklassen abbilden, auf die du treffen wirst.

Statische HTML-Verzeichnisse und Register. Die meisten regionalen Handelsregister und viele ältere B2B-Verzeichnisse sind server-rendered. Sie erwarten einen schnellen, ressourcenschonenden HTTP-Request von einer sauberen IP. Das ist Single: eine URL rein, eine Response raus. Füge unblocker: true hinzu, und es kommt durch Blockaden auf Handshake-Ebene, die einen einfachen HTTP-Client kalt stoppen. Single leitet automatisch durch den Proxy Finder weiter und gibt die Proxy-ID auf der obersten Ebene der Response (r.proxy) zurück, sodass deine Folgeaufrufe sie als proxy:"<id>" übergeben können, um beim selben Exit zu bleiben, wenn du Session-Kontinuität benötigst.

JavaScript-lastige SPAs. Crunchbase, LinkedIn-ähnliche Apps und selbst Websites mittelständischer Unternehmen liefern nicht die gewünschten Daten auf eine einfache HTTP-Response. Sie rendern auf dem Client. Das ist Browser: ein vollständiger Browser führt die Seite aus, lässt das JS laufen und gibt dir das gerenderte HTML, Cookies und Screenshots zurück. Wie Single routet es im Hintergrund durch den Proxy Finder (kein separater Auswahlschritt auf deiner Seite).

Gemischte Quellen mit Validierung. Jeder Request an die API von FourA akzeptiert einen validate Block. Du kannst spezifische Statuscodes, Header-Matches oder Substring-Matches im Body verlangen. Wenn die Response ein Soft-Fail ist (eine 200er-Seite mit einem CAPTCHA, eine leere Datenhülle oder ein "We're sorry"-Interstitial), lehnt der Validator sie ab. Deine Pipeline kann dann dieselbe URL stattdessen über Browser routen. Genau dieses Feature eliminiert die teuerste Fehlerklasse beim Enrichment: den Silent Failure, der Müll 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 sitzt in deiner eigenen Pipeline. Die Zuverlässigkeit liegt bei uns. Du entscheidest, welche deiner Quellen welches Tool erhält. Wir stellen sicher, dass das Tool auch wirklich durchkommt.

Ergebnisse

Wir haben beobachtet, wie eine Handvoll Teams während der Public Beta von Inhouse-Scrapern auf eine über FourA geroutete Pipeline umgestiegen sind. Das Muster ist konsistent (illustrative Zahlen basierend auf dem, was wir in der Beta-Kohorte gesehen haben):

  • Enrichment-Latenz sinkt von 3 bis 6 Sekunden pro Unternehmen auf einen Median von unter 1,5 Sekunden auf Cached-Residential-Routen
  • 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
  • Engineering-Zeit für Scraper-Wartung sinkt von 1 bis 2 Vollzeit-Entwicklern auf einen Slack-Kanal, der meistens still bleibt
  • First-Pass Success Rate bei geschützten Verzeichnissen klettert in die hohen 90er, wenn unblocker: true mit einer sauberen Proxy-ID kombiniert wird

Eine weitere erwähnenswerte Zahl: Wir haben gesehen, dass die Korrektheit im ersten Durchlauf (richtige Daten, richtiges Unternehmen) der Erfolgsquote im ersten Durchlauf um etwa vier Prozentpunkte hinterherhinkt. Die Lektion ist nicht, dass Scraping schwer ist. Es ist die Tatsache, dass du den Datensatz immer noch gegen das Unternehmen validieren musst, das du eigentlich angefragt hast (wir haben über dieses Muster in warum dein Web-Scraper ständig kaputtgeht geschrieben).

Die Zahlen, die zählen, sind nicht die Größe des Proxy-Pools oder die Request-Anzahl. Es sind die Rate, mit der dein Enrichment-Endpoint beim ersten Versuch die richtigen Daten zurückgibt, und die Steigung deines Graphen für die Scraper-Wartung in den nächsten sechs Monaten.

Fazit

Enrichment-Pipelines scheitern in Zeitlupe. Der erste Scraper, den du schreibst, sieht an einem Dienstag noch gut aus. Bei der dritten Quelle patchst du um 23 Uhr Selektoren. Bei der zehnten trägst du Wartungsschulden mit dir herum, die mit deiner Kundenbasis skalieren. Bei der zwanzigsten hast du klammheimlich aufgehört, neue Quellen anzubinden, weil niemand im Team die nächste übernehmen will.

Der Engpass war nie die Quelle. Es war das Routing: die Auswahl des richtigen Tools, des richtigen Proxys, der richtigen Validierungsregel für jede URL, jedes Mal. Baue diese Schicht einmal, übergib sie an etwas, das dies bereits tut, und dein Team kann den Dienstag für das Produkt nutzen, anstatt kaputte Selektoren zu triagieren.