Thu thập dữ liệu trong trạng thái đăng nhập thường cần nhiều tài khoản, trong khi giới hạn truy cập không phải lúc nào cũng do script. Tách rủi ro liên kết thành đặc điểm thiết bị, đầu ra mạng, trạng thái phiên và nhịp yêu cầu giúp xác định rõ các biến có thể kiểm soát lâu dài.
Thu thập dữ liệu thương mại điện tử thường có thể chia thành hai loại: thu thập các trang công khai không cần đăng nhập và thu thập trong trạng thái đã đăng nhập, chẳng hạn xem dữ liệu back-office của đối thủ hoặc lấy kết quả hiển thị sau khi cá nhân hóa.
Với loại thứ nhất, thông thường chỉ cần kiểm soát tần suất. Khi loại thứ hai liên quan đến nhiều tài khoản, yếu tố quyết định không còn là script thông minh đến đâu mà là các tài khoản có thể tồn tại độc lập với nhau hay không. Nếu lớp này không được xử lý tốt, giới hạn tốc độ và khóa tài khoản sẽ có vẻ ngẫu nhiên; sửa script, giảm tần suất hoặc đổi selector cũng không cải thiện được tình hình.
Rủi ro đến từ đâu
Nền tảng xác định nhiều tài khoản có do cùng một bên vận hành hay không bằng cách đối chiếu chéo: địa chỉ mạng, đặc điểm trình duyệt và thiết bị, dữ liệu Cookie và phiên, cùng mẫu hành vi. Chỉ cần mức độ trùng lặp cao ở một nhóm tín hiệu cũng có thể khiến các tài khoản bị xếp về cùng một người vận hành.
Cần xác định một ranh giới rõ ràng ở đây. Logic phát hiện liên tục được cập nhật, nên dựa vào các mẹo tạm thời để đối phó chỉ đem lại lợi ích ngắn hạn với chi phí cao. Vì vậy, nội dung dưới đây không bàn cách vượt qua kiểm soát rủi ro. Câu hỏi đáng quan tâm hơn là: sau khi làm rõ nguồn rủi ro, biến nào chúng ta có thể kiểm soát và duy trì ổn định lâu dài? Chính những biến này quyết định nhiều tài khoản hợp lệ có ảnh hưởng lẫn nhau hay không.
Đặc điểm thiết bị và trình duyệt
Một trong những cách dễ gây vấn đề nhất là mở nhiều cửa sổ trên cùng một máy và đăng nhập các tài khoản khác nhau. Ngay cả khi xóa cache hoặc dùng chế độ ẩn danh, các cửa sổ này vẫn chia sẻ cùng môi trường hệ thống và dữ liệu trình duyệt. Các đặc điểm vẫn chồng lấn, nên nền tảng nhìn thấy một thiết bị liên tục thay đổi danh tính.
Cách có thể kiểm soát là cấp cho mỗi tài khoản một môi trường riêng: một tài khoản tương ứng với một môi trường độc lập, có fingerprint, Cookies và bộ nhớ cục bộ tách biệt. Điểm quan trọng là cố định môi trường đó cho tài khoản, thay vì tạo ngẫu nhiên một bộ mới mỗi lần khởi động. Các tổ hợp ngẫu nhiên thường tự mâu thuẫn: múi giờ, ngôn ngữ, độ phân giải và UA có thể không khớp nhau, khiến chúng trông bất thường hơn một cấu hình ổn định.
Nói ngắn gọn, sự ổn định đến từ tính nhất quán, không phải tính ngẫu nhiên.
Đầu ra mạng
Đầu ra phải được gắn với tài khoản: một môi trường, một đầu ra, đồng thời khu vực của đầu ra phải phù hợp với hồ sơ tài khoản, múi giờ và ngôn ngữ. Nếu nhiều tài khoản có môi trường riêng nhưng lại dùng chung một đầu ra, phần lớn tác dụng của việc cô lập trước đó sẽ mất đi.
Đầu ra cũng cần tương đối ổn định. Thay đổi khu vực liên tục khiến tín hiệu vị trí của tài khoản khó giải thích. Khi chọn đầu ra, địa chỉ dân cư thường giống truy cập của người dùng bình thường hơn địa chỉ trung tâm dữ liệu. Đồng thời cần tránh những địa chỉ đã bị sử dụng với khối lượng lớn, vì bản thân chúng có thể đã được giám sát chặt hơn.
Cookies và phiên
Trạng thái phiên tự nó đã là một hồ sơ danh tính. Nếu nhiều tài khoản dùng chung Cookies hoặc bộ nhớ cục bộ, một liên kết trực tiếp sẽ hình thành giữa chúng, bất kể các môi trường còn lại được tách biệt sạch đến đâu.
Phiên trong một môi trường mới cũng không nên được dùng với cường độ cao ngay từ đầu. Hãy tích lũy một khoảng lịch sử duyệt web bình thường trước, rồi tăng dần khối lượng nhiệm vụ. Nguyên tắc này cũng đúng ngoài việc thu thập dữ liệu: tài khoản có lịch sử sử dụng hay không ảnh hưởng trực tiếp đến mức hoạt động mà nó có thể duy trì hợp lý.
Nhịp yêu cầu
Mật độ yêu cầu là một tín hiệu hành vi. Script thường có tính đều đặn rất rõ: khoảng cách truy cập cố định, thứ tự trang cố định và không có hành vi nào ngoài nhiệm vụ thu thập. Chỉ thêm số ngẫu nhiên không giải quyết được kiểu đều đặn này, vì vấn đề chính nằm ở tổng khối lượng.
Hướng có thể kiểm soát là giữ khối lượng công việc trong phạm vi hợp lý: giãn thời gian chạy giữa các tài khoản, không để tất cả tài khoản cùng đạt tải tối đa, chừa khoảng nghỉ hợp lý giữa các trang và tách nhiệm vụ ưu tiên cao với ưu tiên thấp. Ranh giới rất rõ: hoạt động thu thập không được gây áp lực lên dịch vụ mục tiêu. Bất kỳ tốc độ nào đạt được bằng cách làm ảnh hưởng đến dịch vụ của bên kia đều không phải một sự đánh đổi hợp lý.
Vì sao môi trường cố định theo tài khoản ổn định hơn việc chuyển đổi ngẫu nhiên
Động cơ của việc chuyển đổi ngẫu nhiên là tạo ra diện mạo khác mỗi lần, nhưng kiểm tra liên kết lại xem xét liệu tín hiệu ở các chiều có ổn định và có mâu thuẫn lẫn nhau hay không. Nếu hôm nay một tài khoản đi ra từ nơi này, ngày mai từ nơi khác, và mỗi lần có một tổ hợp đặc điểm khác nhau, chính sự thiếu nhất quán đó đã là tín hiệu bất thường.
Môi trường cố định đi theo logic ngược lại. Từ lúc đăng ký, tài khoản có một danh tính nhất quán: môi trường cố định, đầu ra cố định, múi giờ và ngôn ngữ đồng bộ, cùng lịch sử phiên được tích lũy dần. Tính nhất quán này càng duy trì lâu, hoạt động càng dễ giống một người dùng bình thường. Giá trị của lớp môi trường nằm ở đây: ổn định lâu dài thay vì thay đổi bắt mắt.
Điều này cũng giải thích vì sao script thu thập không nên tự quản lý các instance trình duyệt. Môi trường cần có thể được lập lịch độc lập để phân bổ môi trường riêng cho từng tài khoản; trạng thái môi trường cần truy vấn được để phát hiện môi trường bất thường và tài khoản đã mất hiệu lực; môi trường cần được thu hồi để vận hành dài hạn không tích lũy các instance zombie; và khi chạy lại một nhiệm vụ thu thập thường cần đổi môi trường, điều chỉ khả thi khi môi trường được lập lịch độc lập. Trong kiến trúc như vậy, PurpleMark là lớp tài nguyên môi trường. Script chỉ xử lý logic thu thập, còn danh tính và tài nguyên được giao cho lớp môi trường.
Ranh giới tuân thủ
Những điểm sau quan trọng hơn mọi tối ưu ở trên.
Tuân thủ điều khoản dịch vụ và quy tắc robots của trang mục tiêu. Nhiều nền tảng thương mại điện tử quy định rõ hạn chế truy cập tự động, vì vậy hãy xác nhận cách sử dụng dự kiến có được phép hay không trước khi bắt đầu. Chỉ thu thập thông tin công khai về sản phẩm, giá và tồn kho, không thu thập thông tin cá nhân. Không vượt qua các biện pháp bảo vệ kỹ thuật. Khi gặp CAPTCHA hoặc giao diện mã hóa, hãy điều chỉnh chiến lược thu thập hoặc xin cấp quyền thay vì tìm cách phá bảo vệ. Kiểm soát tần suất yêu cầu bất kể có bao nhiêu tài khoản và không làm ảnh hưởng đến hoạt động bình thường của dịch vụ mục tiêu.
Tiền đề của thảo luận này là cách giữ nhiều tài khoản hợp lệ độc lập và không gây ảnh hưởng lẫn nhau, chứ không phải cách né quy tắc của nền tảng. Vấn đề thứ nhất là vệ sinh vận hành; vấn đề thứ hai là một chuyện khác.
