Các cơ quan lãnh đạo và các nhà tiếp thị thu thập cơ sở dữ liệu công ty từ bản đồ, sớm hay muộn cũng sẽ gặp phải một câu hỏi giống nhau: thu thập 10.000 liên hệ thực sự "nặng" bao nhiêu và tại sao tài khoản và địa chỉ IP bắt đầu bị cấm ngay từ ngàn thứ ba. Chúng ta sẽ phân tích tính toán lưu lượng truy cập từng bước, so sánh Google Maps, 2GIS và Yandex.Maps, và chỉ ra proxy nào có thể chịu được khối lượng như vậy mà không bị chặn.
Lãnh đạo từ bản đồ là gì và tại sao cần tính toán lưu lượng truy cập
Lãnh đạo từ bản đồ là việc thu thập dữ liệu liên hệ của các công ty (tên, điện thoại, trang web, địa chỉ, xếp hạng, danh mục hoạt động) thông qua Google Maps, 2GIS hoặc Yandex.Maps để thực hiện các cuộc gọi lạnh, gửi email hoặc quảng cáo nhắm mục tiêu. Phương pháp này đặc biệt phổ biến trong các cơ quan cung cấp dịch vụ B2B: các studio web, nhà cung cấp CRM, các nhà thầu tiếp thị — họ cần cơ sở dữ liệu theo các lĩnh vực và thành phố: "nha khoa Kazan", "dịch vụ ô tô Novosibirsk", "salon làm đẹp Yekaterinburg".
Tính toán lưu lượng rất quan trọng vì ba lý do. Thứ nhất, khối lượng dữ liệu được truyền tải quyết định lượng proxy mà bạn sẽ tiêu tốn và chi phí khi mở rộng ra nhiều thành phố. Thứ hai, bản đồ ghi nhận hoạt động bất thường dựa trên số lượng yêu cầu, không chỉ theo IP — và nếu không hiểu được số lượng yêu cầu mà việc thu thập 10.000 thẻ tạo ra, bạn dễ dàng đánh giá thấp rủi ro bị cấm. Thứ ba, biết chính xác khối lượng dữ liệu giúp bạn dễ dàng chọn giữa việc thu thập trang HTML, sử dụng API nội bộ của bản đồ hoặc dịch vụ có sẵn — mỗi tùy chọn có sự khác biệt về lưu lượng.
Trên thực tế, 10.000 công ty không phải là một con số trừu tượng. Khối lượng này tương ứng với, ví dụ, toàn bộ cơ sở dữ liệu của các pháp nhân hoạt động trong lĩnh vực "sửa chữa thiết bị" tại 15-20 thành phố triệu dân ở Nga, hoặc tất cả các cơ sở ăn uống trong một thành phố lớn như Moscow hoặc St. Petersburg. Đây là một nhiệm vụ thực tế cho một cơ quan bán các liên hệ theo gói.
Một thẻ công ty nặng bao nhiêu
Trọng lượng của một thẻ công ty phụ thuộc vào những gì bạn đang thu thập và cách thức thu thập. Nếu chỉ thu thập danh sách kết quả tìm kiếm (tên, địa chỉ ngắn, xếp hạng), thì dữ liệu được truyền tải một cách gọn gàng — thường là phản hồi JSON từ API nội bộ của bản đồ nặng 3-8 KB cho mỗi công ty trong danh sách chung. Nếu bạn cần thẻ chi tiết — điện thoại, trang web, giờ làm việc, hình ảnh, đánh giá — bạn sẽ phải mở một trang riêng hoặc thực hiện yêu cầu bổ sung, và trọng lượng sẽ tăng lên 80-250 KB do hình ảnh và JSON mở rộng.
Dưới đây là sự so sánh về ba bản đồ chính mà các cơ quan lãnh đạo sử dụng ở CIS:
| Bản đồ | Trọng lượng thẻ trong danh sách | Trọng lượng thẻ chi tiết | Đặc điểm bảo vệ |
|---|---|---|---|
| Google Maps | 5-8 KB | 150-250 KB | Giới hạn tần suất nghiêm ngặt và captcha khi có nhiều yêu cầu từ một IP |
| 2GIS | 3-6 KB | 80-150 KB | Khóa theo tần suất yêu cầu đến API của danh bạ |
| Yandex.Maps | 4-7 KB | 100-200 KB | Hệ thống chống bot với phân tích hành vi và danh sách đen proxy |
Một điểm quan trọng: trọng lượng của danh sách không phải là toàn bộ thẻ. Để có được điện thoại và trang web của công ty, trong hầu hết các trường hợp cần một yêu cầu riêng đến trang chi tiết. Điều này làm tăng gấp đôi hoặc thậm chí gấp ba lưu lượng thực tế cho mỗi liên hệ, nếu bạn không chỉ thu thập tên mà còn các liên hệ đầy đủ cho việc bán hàng.
Tính toán lưu lượng truy cập cho 10.000 công ty từng bước
Hãy lấy một kịch bản thực tế: một cơ quan thu thập các thẻ đầy đủ (tên, điện thoại, trang web, địa chỉ, xếp hạng, danh mục) từ Google Maps cho 10.000 công ty ở một vài thành phố.
Bước 1. Tìm kiếm và liệt kê. Google Maps cung cấp khoảng 20 kết quả trên một trang kết quả. Để có được 10.000 vị trí, cần xử lý khoảng 500 trang kết quả. Mỗi trang, tính cả các yêu cầu dịch vụ, tải bản đồ và các script, nặng khoảng 600-900 KB. Tổng cộng: 500 × 750 KB ≈ 375 MB chỉ trong giai đoạn tìm kiếm.
Bước 2. Thẻ chi tiết. Đối với mỗi trong số 10.000 công ty, cần một yêu cầu riêng với điện thoại, trang web và hình ảnh. Với trọng lượng trung bình 180 KB cho mỗi thẻ: 10.000 × 180 KB ≈ 1,8 GB.
Bước 3. Các yêu cầu lặp lại và thử lại. Trong điều kiện thực tế, 10-20% yêu cầu không thành công ngay lần đầu do giới hạn tần suất, captcha hoặc thay đổi bố cục — chúng phải được lặp lại. Thêm 15% vào khối lượng: (375 MB + 1,8 GB) × 1,15 ≈ 2,5 GB.
Con số cuối cùng là khoảng 2,5 GB lưu lượng để thu thập 10.000 công ty từ Google Maps khi thu thập các thẻ chi tiết. Nếu chỉ thu thập danh sách mà không có điện thoại và trang web, lưu lượng giảm xuống còn 450-500 MB, nhưng cơ sở dữ liệu như vậy sẽ khó sử dụng cho việc bán hàng — không có điện thoại, liên hệ không chuyển đổi thành cuộc gọi.
Đối với 2GIS và Yandex.Maps, tính toán tương tự, nhưng khối lượng thường thấp hơn 20-30% nhờ vào định dạng API gọn gàng hơn — hãy dự kiến khoảng 1,7-2,2 GB cho cùng 10.000 thẻ.
Tại sao bản đồ bị cấm vì thu thập dữ liệu hàng loạt
Bản đồ là tài sản thương mại của chính các nền tảng, và việc thu thập dữ liệu tự động hàng loạt trực tiếp mâu thuẫn với mô hình kinh doanh của họ (bán quảng cáo trong các thẻ, quyền truy cập API cho các đối tác). Do đó, Google Maps, 2GIS và Yandex.Maps đều phản ứng một cách quyết liệt với hành vi không điển hình.
Ba yếu tố chính dẫn đến việc bị chặn: tần suất yêu cầu quá cao từ một IP (hơn 1 yêu cầu trong 2-3 giây), User-Agent và tiêu đề giống nhau mà không có sự biến đổi, thiếu cookies và dữ liệu phiên, yêu cầu không có tài nguyên đi kèm (hình ảnh, script), mà trình duyệt thông thường luôn tải lên. Khi đạt đến giới hạn, dịch vụ sẽ hiển thị captcha hoặc tạm thời chặn IP trong 15-60 phút, hoặc cấm IP vĩnh viễn nếu vi phạm lặp lại.
Đối với khối lượng tính toán 2,5 GB và 10.000+ yêu cầu từ một IP "sạch", khả năng bị cấm gần như đạt 100% ngay từ ngàn thẻ đầu tiên. Chính vì vậy, bất kỳ dự án nghiêm túc nào về lãnh đạo từ bản đồ đều được xây dựng xung quanh việc luân chuyển địa chỉ IP — nếu không có điều này, việc tính toán lưu lượng sẽ mất ý nghĩa, vì việc thu thập khối lượng dự kiến về mặt vật lý sẽ không thể thực hiện được.
Proxy dân cư, di động và trung tâm dữ liệu cho việc thu thập bản đồ
Việc chọn loại proxy ảnh hưởng trực tiếp đến số lượng yêu cầu bạn có thể thực hiện trước khi bị chặn và tỷ lệ lưu lượng mà bạn sẽ phải "tiêu tốn" cho các nỗ lực thử lại. Đối với việc thu thập dữ liệu từ bản đồ, độ tin cậy của IP là rất quan trọng — các bản đồ thường nghiêm ngặt hơn trong việc cấm các dải địa chỉ từ trung tâm dữ liệu, vì chính từ đó phát sinh phần lớn việc thu thập tự động.
| Loại proxy | Mức độ tin cậy của bản đồ | Khi nào nên áp dụng |
|---|---|---|
| Proxy dân cư | Cao — IP của người dùng thực | Công cụ chính để thu thập 5.000-50.000 thẻ với luân chuyển theo thành phố |
| Proxy di động | Rất cao — IP chung của các nhà mạng | Thu thập theo điểm theo lĩnh vực với bảo vệ chống bot nghiêm ngặt (Yandex.Maps) |
| Proxy trung tâm dữ liệu | Thấp-trung bình — thường có trong danh sách đen | Chạy thử nghiệm, kiểm tra script với khối lượng nhỏ mà không có xuất dữ liệu thực tế |
Trong thực tế, cho 10.000 công ty tính toán, sự kết hợp tối ưu là proxy dân cư với luân chuyển theo các subnet của thành phố: bạn nhận được IP từ cùng một khu vực mà đối tượng mục tiêu trong các thẻ, và giảm tỷ lệ captcha và các yêu cầu lặp lại mà chúng ta đã tính toán trong lưu lượng ở trên. Proxy trung tâm dữ liệu trong nhiệm vụ này chỉ có thể được sử dụng trong giai đoạn thử nghiệm script trên 50-100 thẻ, để không tiêu tốn ngân sách lưu lượng của proxy dân cư cho việc điều chỉnh.
Cài đặt thu thập dữ liệu: công cụ và sơ đồ từng bước
Để thu thập cơ sở dữ liệu công ty từ bản đồ, các cơ quan thường sử dụng các công cụ no-code và low-code có sẵn, thay vì viết parser từ đầu. Trong số các giải pháp phổ biến có A-Parser (cài đặt linh hoạt các mẫu cho Google Maps, 2GIS, Yandex.Maps mà không cần viết mã), Octoparse (trình tạo kịch bản thu thập trực quan) và ZennoPoster (mẫu tự động hóa với hỗ trợ proxy và hồ sơ chống phát hiện). Đối với khối lượng nhỏ, các dịch vụ thu thập dữ liệu từ đám mây với thanh toán theo số lượng thẻ sẽ phù hợp.
Sơ đồ từng bước để khởi động thu thập 10.000 công ty như sau:
- Xác định danh sách các thành phố và lĩnh vực mà bạn cần liên hệ — điều này xác định số lượng yêu cầu tìm kiếm và cho phép dự đoán chính xác lưu lượng theo công thức từ phần trên.
- Cài đặt trong parser danh sách proxy dân cư với luân chuyển theo IP mỗi 5-10 yêu cầu — hầu hết các công cụ hỗ trợ danh sách proxy theo định dạng login:mật khẩu@host:cổng.
- Bật độ trễ ngẫu nhiên giữa các yêu cầu 3-7 giây và luân chuyển User-Agent — điều này giảm tỷ lệ captcha xuống 30-40% so với các khoảng thời gian cố định.
- Khởi động chạy thử nghiệm trên 100-200 thẻ và ghi lại lưu lượng thực tế — so sánh với lưu lượng tính toán để điều chỉnh dự đoán cho khối lượng đầy đủ.
- Mở rộng thu thập đến 10.000 thẻ, chia nhiệm vụ thành các lô 1.000-1.500 bản ghi — điều này giúp dễ dàng kiểm soát lỗi và khởi động lại khi gặp sự cố.
- Xuất kết quả sang CSV hoặc trực tiếp vào CRM, loại bỏ các bản sao theo số điện thoại và trang web — trên bản đồ thường có các bản sao do các tổ chức mạng và chi nhánh.
Nếu nhiệm vụ thu thập lặp lại thường xuyên (ví dụ, cập nhật hàng tháng cơ sở dữ liệu theo lĩnh vực), có ý nghĩa để ngay lập tức thiết lập khởi động tự động theo lịch trình với một nhóm IP dân cư cố định — điều này tiết kiệm thời gian cho việc khởi động lại thủ công và giảm rủi ro bị cấm nhờ vào việc phân phối tải đều theo thời gian.
Cách giảm tiêu thụ lưu lượng mà không mất đi các liên hệ
2,5 GB tính toán cho 10.000 công ty có thể được giảm xuống 30-40% mà không làm mất chất lượng dữ liệu, nếu áp dụng một vài phương pháp thực tiễn.
Thứ nhất, tắt tải hình ảnh ở cấp độ yêu cầu — hình ảnh của các cơ sở chiếm đến một nửa trọng lượng của thẻ chi tiết, nhưng không cần thiết cho việc bán hàng. Thứ hai, sử dụng các yêu cầu trực tiếp đến API nội bộ của bản đồ thay vì toàn bộ việc kết xuất trang trong trình duyệt — điều này loại bỏ các script, kiểu dáng và phông chữ không cần thiết, không mang lại dữ liệu hữu ích. Thứ ba, lọc các bản sao trước khi thu thập các thẻ chi tiết: nếu công ty đã xuất hiện ở khu vực khác của cùng một thành phố, không thực hiện yêu cầu lặp lại đến trang của nó — hãy đối chiếu theo tên và địa chỉ trong giai đoạn danh sách. Thứ tư, thu thập trước các danh sách nhẹ cho tất cả các thành phố, và chỉ yêu cầu các thẻ chi tiết cho các công ty đã vượt qua bộ lọc theo xếp hạng hoặc danh mục — điều này đặc biệt hữu ích nếu bạn không cần tất cả 10.000, mà chỉ 30% hàng đầu theo độ liên quan.
Những phương pháp này không chỉ giảm khối lượng lưu lượng mà còn giảm số lượng yêu cầu đến các máy chủ bản đồ, và do đó — giảm rủi ro bị chặn. Đối với cơ quan, điều này có nghĩa là tiêu thụ lưu lượng proxy thấp hơn với cùng một mức giá và khả năng thu thập nhiều thành phố hơn với cùng ngân sách.
Những sai lầm thường gặp khi thu thập liên hệ từ bản đồ
Sai lầm đầu tiên là khởi động thu thập từ một IP tĩnh mà không có luân chuyển. Ngay cả khi tốc độ yêu cầu thấp, bản đồ ghi nhận hoạt động bất thường ngay sau 200-300 yêu cầu liên tiếp, và việc thu thập tiếp theo trở nên không thể nếu không thay đổi IP.
Sai lầm thứ hai là bỏ qua sự phù hợp khu vực giữa proxy và thành phố mục tiêu. Nếu bạn thu thập các công ty ở Kazan thông qua IP từ một quốc gia khác, bản đồ thường hiển thị kết quả không liên quan hoặc ngay lập tức chặn yêu cầu như nghi ngờ.
Sai lầm thứ ba là không tính toán lưu lượng trước khi khởi động. Các nhóm thường khởi động thu thập "theo cảm tính" và gặp phải giới hạn lưu lượng proxy giữa nhiệm vụ, mất dữ liệu đã thu thập do phiên bị ngắt.
Sai lầm thứ tư là thu thập mà không loại bỏ các bản sao ngay lập tức. Khi thu thập 10.000 vị trí từ nhiều yêu cầu giao nhau (ví dụ, "quán cà phê" và "nhà hàng" trong cùng một khu vực), các bản sao có thể chiếm 15-25% cơ sở dữ liệu, điều này làm tăng giả tạo lưu lượng tính toán và chi phí thực tế.
Sai lầm thứ năm là sử dụng cùng một User-Agent và tiêu đề cho tất cả các yêu cầu trong phiên. Các hệ thống chống bot của bản đồ phân tích không chỉ IP mà còn tính nhất quán của dấu vân tay kỹ thuật số của trình duyệt, vì vậy đối với khối lượng lớn, nên kết hợp luân chuyển proxy với trình duyệt chống phát hiện và thay đổi dấu vân tay cùng với IP.
Kết luận
Thu thập 10.000 công ty từ bản đồ là một nhiệm vụ có thể dự đoán về lưu lượng: khi thu thập các thẻ chi tiết từ Google Maps, tiêu thụ khoảng 2,5 GB với các yêu cầu lặp lại, và đối với 2GIS và Yandex.Maps, chỉ số này thấp hơn 20-30%. Biết con số này trước, bạn có thể lập kế hoạch ngân sách cho lưu lượng proxy một cách chính xác và tránh tình huống khi việc thu thập bị ngắt giữa chừng do hết giới hạn.
Yếu tố chính cho việc thu thập thành công không phải là tiết kiệm lưu lượng, mà là lựa chọn đúng proxy. Đối với khối lượng vài nghìn thẻ mỗi ngày, chúng tôi khuyên bạn nên sử dụng proxy dân cư với luân chuyển theo thành phố — chúng giảm tỷ lệ captcha và các yêu cầu lặp lại, mà tiêu tốn đến 15-20% lưu lượng. Nếu việc thu thập được thực hiện theo các lĩnh vực có bảo vệ chống bot đặc biệt nghiêm ngặt, nên xem xét các IP di động như một bổ sung cho nhóm chính — điều này nâng cao tính ổn định của phiên với mức tăng chi phí tối thiểu.