← 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 danh sách tên công ty. Họ mong đợi nhận lại dữ liệu sạch: khung doanh thu, quy mô nhân sự, tech stack, vòng gọi vốn, liên hệ chính, tin tức gần đây. Họ muốn có kết quả trong vài phút chứ không phải vài ngày. Và dữ liệu phải chính xác.

Dữ liệu thực sự 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 LinkedIn công ty, trên Google Maps, trên Glassdoor, trên các cổng đăng ký kinh doanh theo 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 ổn định.

Mỗi nguồn dữ liệu lại gặp lỗi theo một cách khác nhau. Crunchbase sử dụng ứng dụng client-side nặng, tự động render lại nếu nghi ngờ có bot. LinkedIn áp dụng rate limit rất gắt và thay đổi DOM nhanh hơn tốc độ bạn vá selector (một bài viết phổ biến trong cộng đồng đo lường rằng một scraper Python cơ bản chỉ lấy được khoảng 50 profile trước khi trang web bắt đầu từ chối yêu cầu). Website công ty có đủ loại từ HTML tĩnh đến single-page app cần một trình duyệt đầy đủ mới hiển thị được nội dung. Danh bạ theo khu vực thay đổi giao diện hàng quý và chặn truy cập bằng rào cản theo quốc gia. Theo một báo cáo ngành năm 2026 từ GroupBWT, 10 đến 15% crawler trong một số lĩnh vực cần sửa lỗi hàng tuần chỉ để bắt kịp các thay đổi về phát hiện bot và biến động DOM.

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

Hướng tiếp cận

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

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 tới ba nhóm nguồn dữ liệu mà bạn sẽ gặp phải.

Danh bạ HTML tĩnh và cổng đăng ký doanh nghiệp. Phần lớn các cổng đăng ký kinh doanh theo khu vực và nhiều danh bạ B2B cũ hơn đều được server-rendered. Chúng cần một HTTP request nhanh, ít tiêu tốn tài nguyên từ một IP sạch. Đó chính là Single: một URL gửi vào, một response trả về. Thêm unblocker: true và nó sẽ vượt qua các lớp chặn ở cấp độ bắt tay (handshake-level) vốn chặn đứng các HTTP client thông thường. Single tự động định tuyến qua Proxy Finder 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 lại dưới dạng proxy:"<id>" nhằm giữ nguyên IP đầu ra khi bạn cần duy trì session.

Các SPA nặng JavaScript. Crunchbase, các ứng dụng kiểu LinkedIn, và thậm chí cả 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 HTTP response thông thường. Chúng render ở phía client. Đó là lý do có Browser: một trình duyệt đầy đủ sẽ thực thi trang, chạy JS, và trả lại cho bạn HTML đã render, cookie, cùng ảnh chụp màn hình. Tương tự như Single, nó tự động định tuyến qua Proxy Finder ở phía dưới, không cần bước chọn riêng từ phía bạn.

Nguồn hỗn hợp kèm xác thực. Mọi request gửi đế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 status code cụ thể, khớp header, hoặc khớp chuỗi con trong body. Nếu response bị lỗi mềm (một trang 200 yêu cầu xác minh, một khung dữ liệu trống, hoặc trang thông báo tạm thời "chúng tôi rất tiếc"), bộ 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 đó loại bỏ hoàn toàn loại lỗi tốn kém nhất trong quá trình làm giàu dữ liệu: lỗi âm thầm ghi dữ liệu rác vào cơ sở dữ liệu của bạn.

Dưới đây là cấu trúc của một lệnh gọi nguồn đơn:

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

Và đoạn mã Browser tương đương cho một trang web công ty sử dụng nhiều JavaScript:

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

Logic định tuyến nằm trong pipeline của chính bạn. Độ tin cậy nằm ở phía chúng tôi. Bạn quyết định nguồn nào của mình sử dụng công cụ nào. Chúng tôi đảm bảo công cụ đó thực sự truy cập thành công.

Kết quả

Chúng tôi đã theo dõi một số đội ngũ chuyển đổi từ scraper tự xây dựng sang pipeline định tuyến qua FourA trong giai đoạn public beta. Xu hướng này rất nhất quán (các con số minh họa dựa trên những gì chúng tôi ghi nhận trên nhóm người dùng beta):

  • Độ trễ làm giàu dữ liệu (Enrichment latency) giảm từ 3 đến 6 giây cho mỗi công ty xuống dưới mức trung vị 1.5 giây trên các tuyến residential có cache
  • Tỷ lệ lỗi âm thầm (Silent-failure rate) (phản hồi mã 200 nhưng dữ liệu trống) giảm từ khoảng 8% xuống dưới 1% khi khối validate bắt các lỗi mềm (soft-fail) trước khi chúng đi vào cơ sở dữ liệu
  • Thời gian kỹ thuật dành cho bảo trì scraper giảm từ 1 đến 2 kỹ sư toàn thời gian xuống mức kênh Slack hầu như luôn yên tĩnh
  • Tỷ lệ thành công ngay từ lần đầu (First-pass success rate) trên các danh bạ được bảo vệ tăng lên mức trên 90% khi unblocker: true được kết hợp với proxy id sạch

Thêm một con số đáng lưu ý: chúng tôi nhận thấy tính chính xác ngay từ lần đầu (đúng dữ liệu, đúng công ty) thấp hơn tỷ lệ thành công ngay từ lần đầu khoảng 4 điểm phần trăm. Bài học rút ra không phải là việc cào dữ liệu quá khó. Mà là bạn vẫn cần phải đối soát bản ghi với đúng công ty bạn thực sự đã yêu cầu (chúng tôi đã viết về mô hình đó trong bài lý do web scraper của bạn liên tục bị lỗi).

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

Điểm mấu chốt

Các pipeline làm giàu dữ liệu thường sụp đổ một cách từ từ. Scraper đầu tiên bạn viết có thể chạy rất ổn vào thứ Ba. Đến nguồn thứ ba, bạn phải vá các selector lúc 11 giờ đêm. Đến nguồn thứ mười, bạn phải gánh một khoản nợ bảo trì tăng dần theo quy mô khách hàng. Đến nguồn thứ hai mươi, bạn âm thầm ngừng tích hợp các nguồn mới vì không ai trong đội ngũ muốn chịu trách nhiệm cho nguồn tiếp theo.

Điểm nghẽn chưa bao giờ nằm ở nguồn dữ liệu. Nó nằm ở khâu định tuyến: chọn đúng công cụ, đúng proxy, đúng quy tắc xác thực cho từng URL, trong mọi thời điểm. Xây dựng tầng đó một lần, giao nó cho một hệ thống đã xử lý sẵn việc này, và đội ngũ của bạn có thể dành ngày thứ Ba để phát triển sản phẩm thay vì phải xử lý sự cố vỡ selector.