← Tất cả bài viết
Ứng dụng thực tế 8 phút đọc

Xây dựng pipeline làm giàu dữ liệu công ty B2B

Bạn cần làm giàu dữ liệu hàng ngàn công ty mỗi ngày từ các danh bạ, trang web và báo chí? Đây là cách xây dựng một pipeline làm giàu dữ liệu B2B không bị lỗi hàng tuần.

b2blead generationdata enrichmentcompany enrichmentuse case

Thách thức

Bạn đang xây dựng một sản phẩm B2B SaaS. Khách hàng của bạn tải lên một danh sách tên công ty. Họ mong đợi nhận lại một bản ghi sạch: quy mô doanh thu, số lượng nhân viên, tech stack, vòng gọi vốn, các liên hệ chính, tin tức gần đây. Họ mong đợi điều đó trong vài phút, không phải vài ngày. Và họ mong đợi dữ liệu đó chính xác.

Dữ liệu đã tồn tại. Nó nằm trên Crunchbase, trên trang Giới thiệu của công ty, trên trang công ty LinkedIn, trên Google Maps, trên Glassdoor, trên các cơ quan đăng ký kinh doanh khu vực, trên kho lưu trữ TechCrunch. Vấn đề là làm sao truy cập dữ liệu đó một cách đáng tin cậy.

Mỗi nguồn bị lỗi theo một cách khác nhau. Crunchbase phục vụ một ứng dụng client-side nặng nề và sẽ rerender lại nếu nó nghi ngờ là bot. LinkedIn áp dụng rate limit gắt gao và thay đổi DOM của nó nhanh hơn mức bạn có thể vá các selector (một bài đăng cộng đồng phổ biến đánh giá một scraper Python thông thường ở mức khoảng 50 hồ sơ trước khi hệ thống chặn bot được kích hoạt). Các trang web công ty đa dạng từ HTML tĩnh đến các ứng dụng trang đơn (single-page app) cần một trình duyệt đầy đủ để có thể hiển thị nội dung của chúng. Các danh bạ khu vực xoay vòng bố cục mỗi quý và bị chặn theo quốc gia. Theo một báo cáo ngành năm 2026 từ GroupBWT, 10-15% các crawler trong một số ngành dọc cần các bản sửa lỗi hàng tuần chỉ để theo kịp các bản cập nhật chống bot và sự thay đổi của DOM.

Vì vậy, pipeline làm giàu dữ liệu của bạn bắt đầu với một thiết kế năm nguồn gọn gàng. Sáu tháng sau, nó trở thành một mớ bòng bong các scraper bị hỏng một nửa, các hàng đợi thử lại và một kênh Slack tên là #scraper-alerts mà không ai mở ra nữa (trước đây chúng tôi đã viết về chi phí ẩn của việc duy trì các scraper của riêng bạn). Các khiếu nại về chất lượng dữ liệu chất đống trong hàng đợi hỗ trợ của bạn. Nhóm của bạn bắt đầu nói đùa rằng tên công ty đáng lẽ ra phải là "Năm Scraper và một Lời cầu nguyện".

Cách tiếp cận

Hãy quên các scraper đi một phút. Phần khó của việc làm giàu dữ liệu không phải là trích xuất. Nó là định tuyến: quyết định nguồn nào cần công cụ nào, proxy nào, chính sách thử lại nào và thế nào được coi là một response "tốt".

Một nền tảng như FourA cung cấp cho bạn ba sản phẩm ánh xạ trực tiếp đến ba loại nguồn mà bạn sẽ truy cập.

Danh bạ HTML tĩnh và cơ quan đăng ký. Hầu hết các cơ quan đăng ký kinh doanh khu vực và rất nhiều danh bạ B2B cũ được render trên máy chủ. Chúng muốn một request HTTP nhanh, ít chi phí từ một IP sạch. Đó là Single: một URL đầu vào, một response đầu ra. Thêm unblocker: true và nó vượt qua các chặn ở cấp độ handshake vốn làm tê liệt một HTTP client thông thường. Single định tuyến qua Proxy Finder một cách tự động và trả về proxy id ở cấp cao nhất của response (r.proxy) để các lệnh gọi tiếp theo của bạn có thể truyền nó trở lại dưới dạng proxy:"<id>" nhằm duy trì cùng một đường ra khi bạn cần tính liên tục của phiên.

Các SPA nặng JavaScript. Crunchbase, các ứng dụng kiểu LinkedIn và thậm chí các trang web của công ty quy mô vừa sẽ không trả về dữ liệu bạn muốn từ một request HTTP thông thường. Chúng render trên client. Đó là Browser: một trình duyệt đầy đủ thực thi trang, chạy JS và trả về cho bạn HTML đã render, cookie và ảnh chụp màn hình. Giống như Single, nó định tuyến ngầm qua Proxy Finder, bạn không cần thực hiện bước chọn riêng.

Nguồn hỗn hợp có xác thực. Mọi request đến API của FourA đều chấp nhận một khối validate. Bạn có thể yêu cầu các mã trạng thái cụ thể, đối sánh header hoặc đối sánh chuỗi con trong phần thân. Nếu response là soft-fail (một trang 200 có CAPTCHA, hoặc một vỏ dữ liệu trống, hoặc một trang trung gian "chúng tôi xin lỗi"), trình xác thực sẽ từ chối nó. Pipeline của bạn sau đó có thể định tuyến cùng một URL qua Browser. Tính năng duy nhất đó đã tiêu diệt loại lỗi đắt giá nhất trong quá trình làm giàu dữ liệu: lỗi âm thầm ghi rác vào cơ sở dữ liệu của bạn.

Dưới đây là hình dạng của một lệnh gọi nguồn đơn:

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

Và cấu hình Browser tương đương cho một trang web công ty nặng 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
  }'

Logic định tuyến nằm trong pipeline của riêng bạn. Độ tin cậy nằm trong tay chúng tôi. Bạn quyết định nguồn nào của mình nhận được công cụ nào. Chúng tôi đảm bảo công cụ đó thực sự xuyên suốt được.

Kết quả

Chúng tôi đã chứng kiến một số nhóm chuyển từ các scraper nội bộ sang một pipeline được định tuyến bởi FourA trong giai đoạn public beta. Mô hình này rất nhất quán (các số liệu minh họa dựa trên những gì chúng tôi đã thấy trên toàn bộ nhóm beta):

  • Độ trễ làm giàu dữ liệu giảm từ 3-6 giây mỗi công ty xuống mức trung bình dưới 1.5 giây trên các route cached-residential
  • Tỷ lệ lỗi âm thầm (các response 200 với dữ liệu trống) giảm từ khoảng 8% xuống dưới 1% khi khối validate bắt các soft-fail trước khi chúng đến được cơ sở dữ liệu
  • Thời gian của kỹ sư bảo trì scraper giảm từ 1-2 kỹ sư toàn thời gian xuống còn một kênh Slack hầu như im ắng
  • Tỷ lệ thành công ngay lần đầu trên các danh bạ được bảo vệ leo lên mức cao 90% khi unblocker: true được ghép nối với một proxy id sạch

Một con số nữa đáng chú ý: chúng tôi đã thấy độ chính xác ngay lần đầu (đúng dữ liệu, đúng công ty) đi sau tỷ lệ thành công ngay lần đầu khoảng bốn điểm. Bài học không phải là việc scraping khó khăn. Bài học là bạn vẫn cần đối chiếu chéo bản ghi với công ty mà bạn thực sự yêu cầu (chúng tôi đã viết về mô hình đó trong bài tại sao web scraper của bạn liên tục bị lỗi).

Các con số quan trọng không phải là kích thước proxy pool hay số lượng request. Chúng là tỷ lệ mà endpoint làm giàu dữ liệu của bạn trả về đúng dữ liệu trong lần thử đầu tiên, và độ dốc của biểu đồ bảo trì scraper của bạn trong sáu tháng tiếp theo.

Bài học cốt lõi

Các pipeline làm giàu dữ liệu thất bại trong một quá trình chậm chạp. Cái scraper đầu tiên bạn viết trông ổn vào thứ Ba. Đến nguồn thứ ba, bạn đang vá các selector vào lúc 11 giờ tối. Đến nguồn thứ mười, bạn đang mang một khoản nợ bảo trì tăng theo quy mô cơ sở khách hàng của bạn. Đến nguồn thứ hai mươi, bạn lặng lẽ ngừng tích hợp các nguồn mới vì không ai trong nhóm muốn đảm nhận nguồn tiếp theo.

Nút thắt cổ chai chưa bao giờ là nguồn dữ liệu. Nó là quá trình định tuyến: chọn đúng công cụ, đúng proxy, đúng quy tắc xác thực cho mọi URL ở mỗi lần chạy. Xây dựng layer đó một lần, giao nó cho một hệ thống đã có sẵn chức năng đó, và nhóm của bạn sẽ dành ngày thứ Ba cho sản phẩm thay vì phải đi xử lý sự cố đứt gãy selector.