← 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 von 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 die Daten stimmen.

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

Jede Quelle bricht anders. Crunchbase liefert eine schwere Client-Side-App aus, die neu rendert, sobald sie einen Bot vermutet. LinkedIn betreibt aggressives Rate Limiting und ändert sein DOM schneller, als du Selektoren patchen kannst (ein bekannter Community-Beitrag beziffert das Limit eines einfachen Python-Scrapers auf etwa 50 Profile, bevor die Website Anfragen blockiert). Unternehmens-Websites reichen von statischem HTML bis hin zu Single-Page-Apps, die einen vollständigen Browser benötigen, um ihren Inhalt überhaupt anzuzeigen. Regionale Verzeichnisse ändern vierteljährlich ihre Layouts und sperren Zugriffe hinter länderspezifischen Blockaden. Laut einem Branchenbericht von GroupBWT aus dem Jahr 2026 benötigen 10 bis 15 % der Crawler in manchen Branchen wöchentliche Fixes, nur um mit Bot-Detection-Änderungen und DOM-Drift Schritt zu halten.

Deine Enrichment-Pipeline beginnt also als sauberer Entwurf mit fünf Quellen. Sechs Monate später ist sie ein Wirrwarr aus halb funktionierenden Scrapern, Retry-Queues und einem Slack-Kanal namens #scraper-alerts, den niemand mehr öffnet (wir haben bereits über die versteckten Kosten für die Wartung eigener Scraper geschrieben). Beschwerden über mangelhafte Datenqualität häufen sich im Support. Dein Team scherzt bereits, dass die Firma eigentlich "Five Scrapers and a Prayer" 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 direkt zu den drei Quellentypen passen, auf die du treffen wirst.

Statische HTML-Verzeichnisse und Register. Die meisten regionalen Handelsregister und viele ältere B2B-Verzeichnisse sind serverseitig gerendert. Sie erfordern einen schnellen HTTP-Request mit minimalem Overhead von einer sauberen IP. Genau dafür gibt es Single: eine URL rein, eine Response raus. Ergänze unblocker: true, und du umgehst Blockaden auf Handshake-Ebene, die einen standardmäßigen HTTP-Client sofort stoppen. Single leitet Requests automatisch über Proxy Finder weiter und liefert die Proxy-ID auf oberster Ebene der Response zurück (r.proxy). Folgeaufrufe können diese als proxy:"<id>" übergeben, um denselben Exit-Knoten beizubehalten, wenn du Session-Kontinuität brauchst.

JavaScript-lastige SPAs. Crunchbase, Apps im LinkedIn-Stil und selbst Websites mittelständischer Unternehmen liefern über eine reine HTTP-Response nicht die gewünschten Daten. Sie rendern auf dem Client. Genau dafür gibt es Browser: Ein vollständiger Browser führt die Seite aus, lässt das JS laufen und liefert dir das gerenderte HTML, Cookies und Screenshots zurück. Wie Single routet er unter der Haube über Proxy Finder, ohne separaten Auswahlschritt auf deiner Seite.

Gemischte Quellen mit Validierung. Jeder Request an die API von FourA akzeptiert einen validate-Block. Du kannst bestimmte Status-Codes, Header-Übereinstimmungen oder Substring-Matches im Body vorgeben. Handelt es sich bei der Response um einen Soft-Fail (eine 200-Seite mit Verifizierungsaufforderung, eine leere Datenhülle oder eine Entschuldigungs-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 Müll in deine Datenbank schreibt.

So sieht der Aufbau eines Single-Source-Calls aus:

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

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

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

Die Routing-Logik liegt in deiner eigenen Pipeline. Die Zuverlässigkeit liegt in unserer. Du entscheidest, welche deiner Quellen welches Tool erhält. Wir stellen sicher, dass das Tool tatsächlich durchkommt.

Ergebnisse

Wir haben während der Public Beta mehrere Teams beim Umstieg von internen Scrapern auf eine FourA-geroutete Pipeline begleitet. Das Muster ist konsistent (illustrative Zahlen basierend auf unseren Beobachtungen in der Beta-Kohorte):

  • Enrichment-Latenz sinkt von 3 bis 6 Sekunden pro Unternehmen auf unter 1,5 Sekunden im Median bei Routen mit Cached-Residential-Proxys
  • Silent-Failure-Rate (200-Responses mit leeren Daten) sinkt von etwa 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-Channel, der meistens still bleibt
  • First-Pass-Erfolgsrate bei geschützten Verzeichnissen steigt in den hohen 90er-Bereich, wenn unblocker: true mit einer sauberen Proxy-ID kombiniert wird

Eine weitere erwähnenswerte Zahl: Wir haben gesehen, dass die Korrektheit im ersten Versuch (richtige Daten, richtiges Unternehmen) der Erfolgsrate im ersten Versuch um etwa vier Prozentpunkte hinterherhinkt. Die Lehre daraus ist nicht, dass Scraping schwer ist. Sondern dass du den Datensatz immer noch mit dem tatsächlich angefragten Unternehmen abgleichen musst (wir haben über dieses Muster in warum dein Web Scraper ständig ausfällt geschrieben).

Die Zahlen, auf die es ankommt, sind nicht die Größe des Proxy-Pools oder die Anzahl der Requests. Es sind die Rate, mit der dein Enrichment-Endpoint beim ersten Versuch die richtigen Daten liefert, und der Verlauf deiner Scraper-Wartungskurve über die nächsten sechs Monate.

Fazit

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

Der Engpass war nie die Quelle. Es war das Routing: für jede URL jedes Mal das richtige Tool, den richtigen Proxy und die richtige Validierungsregel zu wählen. Baue diese Schicht einmal, übergib sie an etwas, das dies bereits erledigt, und dein Team kann den Dienstag am Produkt arbeiten, anstatt defekte Selektoren zu analysieren.