Một tá trứng Lucerne tại một cửa hàng Safeway ở Washington, D.C. được chào bán trên Instacart với các mức giá $3.99, $4.28, $4.59, $4.69 và $4.79. Cùng một cửa hàng, cùng một thời điểm, nhưng dành cho những người mua khác nhau. Con số nào trong năm mức giá này thuộc về bảng theo dõi giá của bạn?
Thách thức
Ngành hàng tạp hóa là nơi price intelligence không còn đơn thuần là "tải trang sản phẩm, bóc tách giá". Một mức giá tạp hóa gắn liền với một cửa hàng, thường là với một khu vực giao hàng, và ngày càng phụ thuộc vào việc ai đang xem nó.
Hãy bắt đầu từ cửa hàng. hướng dẫn so sánh giá hàng tạp hóa của Scrapfly ghi nhận một gallon sữa có giá $3.98 tại một cửa hàng Walmart và $4.29 tại một cửa hàng khác cách đó 20 dặm, đồng thời cảnh báo rằng một phiên không có vị trí cửa hàng sẽ nhận dữ liệu mặc định có thể không khớp với bất kỳ cửa hàng thực tế nào. hướng dẫn giao hàng tạp hóa năm 2026 của ScrapeInsight cũng chỉ ra điều tương tự ở cấp độ sâu hơn: $3.99 tại một khu vực giao hàng, $4.49 ở vị trí cách đó vài dặm. nghiên cứu tình huống ShopGrok của Bright Data mô tả việc định giá bán lẻ tại Úc đã trở nên phụ thuộc vào mã bưu chính trong suốt gần bốn năm hoạt động của công ty đó.
Tiếp theo là người mua hàng. Vào tháng 12 năm 2025, Groundwork Collaborative, Consumer Reports và More Perfect Union đã tiến hành thử nghiệm trực tiếp với 437 người mua tại bốn thành phố, cùng lúc thêm các giỏ hàng Instacart giống hệt nhau từ cùng một cửa hàng. 74% số mặt hàng xuất hiện với nhiều hơn một mức giá. Tại những nơi có chênh lệch giá, khoảng cách giữa giá thấp nhất và cao nhất trung bình là 13%, và toàn bộ giỏ hàng chênh lệch khoảng 7%.
Kết hợp các yếu tố đó lại, bạn sẽ thấy lỗi sai khiến dữ liệu ngành tạp hóa trở nên đắt đỏ. Khi mất ngữ cảnh cửa hàng, hệ thống không hề báo lỗi. Trang web không trả về mã lỗi. Nó trả về một mức giá hoàn toàn hợp lệ cho một cửa hàng mà bạn không hề yêu cầu, kèm theo SKU, con số và timestamp vượt qua mọi bước kiểm tra null của bạn.
Chúng tôi đã từng viết về trường hợp một lượt chặn trông giống như một điểm dữ liệu. Trường hợp này còn khó phát hiện hơn, vì trang hiển thị thực sự là một trang giá. Chỉ có điều nó không dành cho bạn.
Xác thực cửa hàng ngay trong response
Phần lớn các bộ thu thập gửi thông tin chọn cửa hàng (cookie, query parameter, header) và mặc định tin tưởng nó. Cách làm bền vững hơn là buộc response phải chứng minh điều đó. Nếu trang hiển thị rõ tên cửa hàng mà nó được kết xuất, chẳng hạn như store ID trong dữ liệu nhúng hoặc tên cửa hàng trên banner nhận hàng, điểm đánh dấu đó sẽ trở thành định nghĩa thành công của bạn. Trên FourA, thao tác đó chỉ cần một lệnh gọi Proxy Finder:
import requests
r = requests.post(
"https://api.foura.ai/api/proxy",
headers={"X-API-Key": "pk_live_..."},
json={
"maxTries": 6,
"request": {
"method": "GET",
"url": "https://grocer.example/product/0001234",
"headers": [["Cookie", "store=1234"]],
"validate": {
"status": {"accept": [200]},
"data": {
"accept": ["\"storeId\":\"1234\""],
"fail": ["Just a moment", "Access Denied"]
}
}
}
}
).json()
if "error" in r:
report = r.get("attemptReport", {})
print(report.get("summary", r["error"]))
if report.get("contentRejected", 0) > report.get("defense", 0) + report.get("noResponse", 0):
print("the site answered for another store: check the store selection")
else:
page, exit_id = r["data"], r["proxy"]
Ba chi tiết trong request đó rất dễ bị nhầm lẫn.
accept được tính là đạt khi bất kỳ chuỗi nào trong đó xuất hiện trên trang. Nếu đặt dấu hiệu giá tiền cạnh dấu hiệu cửa hàng, trang của cửa hàng khác vẫn sẽ lọt qua vì nó cũng chứa giá tiền. Chỉ giữ lại dấu hiệu cửa hàng trong accept, và đặt các chuỗi thử thách (challenge) vào fail.
Header Cookie của chính bạn sẽ làm thay đổi cơ chế retry. Khi một trang web từ chối trình duyệt mà chúng tôi cung cấp, Proxy Finder thông thường sẽ chuyển sang họ trình duyệt khác ở lần thử tiếp theo. Nhưng khi có cookie của bạn đính kèm thì không. Một session sẽ được gắn chặt với signature đã tạo ra nó, do đó request mang cookie riêng sẽ giữ nguyên trình duyệt ban đầu. Nếu trang web của một chuỗi cửa hàng khắt khe với trình duyệt, hãy chọn cụ thể một trình duyệt bằng browser profiles thay vì trông chờ vào việc rotation.
Và một tác vụ thất bại sẽ cho bạn biết chính xác dạng lỗi gặp phải. Mỗi response Proxy Finder thất bại đều mang một attemptReport. defense đếm các phản hồi phát hiện bot check, noResponse đếm các exit node không thể truy cập trang web, và contentRejected đếm các trang trả về HTTP 200 không có bot check nhưng bị loại bỏ bởi content rule của bạn. Đối với hệ thống thu thập dữ liệu hàng bách hóa, chỉ số cuối cùng mang ý nghĩa cụ thể: trang web đã phản hồi, chỉ là không dành cho cửa hàng của bạn. Thêm exit node sẽ không giải quyết được điều đó. attempt report guide sẽ đề cập đến các chỉ số đếm còn lại.
Giữ nguyên người mua, hoặc đo lường mức độ phân tán
Các phát hiện trên Instacart bổ sung thêm biến số thứ hai, và có hai cách xử lý chuẩn xác.
Đối với bảng theo dõi giá, hãy giữ việc thu thập của mỗi cửa hàng trên một danh tính duy nhất. Tái sử dụng exit node đã phân phối thành công (r["proxy"], một ID không định dạng) thông qua Single với cùng cookie đó, và lưu ID đó kèm theo response header X-FourA-Request-Id trên mỗi hàng dữ liệu. Khi giá thay đổi đột ngột, bạn có thể phân biệt được đâu là biến động từ cửa hàng và đâu là do thay đổi session.
Đối với nghiên cứu giá cả, hãy chủ động làm điều ngược lại. Lấy mẫu cùng một SKU trong cùng một cửa hàng qua nhiều session độc lập và giữ lại phân phối dữ liệu, thay vì chỉ lấy kết quả đầu tiên. Một bảng dữ liệu chỉ báo cáo một con số trong khi người mua nhìn thấy năm mức giá khác nhau thì không phải là chính xác. Đó chỉ là may mắn.
Kết quả
Xét trường hợp một chuỗi bán lẻ khu vực đánh giá 120 cửa hàng đối thủ trên 2.500 SKU, được làm mới hàng ngày (kịch bản minh họa dựa trên benchmark ngành). Con số này tương đương 300.000 lượt đọc trang mỗi ngày, và vào bất kỳ đêm nào cũng sẽ có một số kết quả trả về sai cửa hàng: định dạng cookie bị thay đổi, cửa hàng đóng cửa, hoặc trang web bắt đầu ưu tiên vị trí IP hơn cookie.
- Trang sai cửa hàng sẽ bị loại bỏ ngay khi thu thập. Chúng không bao giờ trở thành các hàng dữ liệu, vì vậy biến động giá trong bảng dữ liệu thực sự là biến động tại đúng cửa hàng đó.
- Lỗi được phân loại sẵn khi trả về. Tỷ lệ
contentRejectedcao sẽ được chuyển cho người phụ trách phần chọn cửa hàng,defensecao là vấn đề quyền truy cập,noResponsecao là do proxy exit. Ba người phụ trách, ba hướng xử lý, và không ai phải mất cả buổi sáng để đoán xem lỗi bắt nguồn từ đâu. - Mọi hàng dữ liệu đều có thể truy vết. Một exit ID và một request ID cho mỗi lần ghi nhận biến câu hỏi "mức giá tăng đột biến này có thật không?" thành một thao tác tra cứu đơn giản.
- Mức chênh lệch trở thành một con số thực tế bạn sở hữu. Đối với các SKU bạn lấy mẫu qua nhiều phiên, bạn có thể báo cáo khoảng giá thực tế mà người mua hàng gặp phải thay vì chỉ dựa vào một lần đọc duy nhất.
Giới hạn của phương pháp này: giá dành cho thành viên và khách hàng thân thiết nằm sau tài khoản đăng nhập, và các thử nghiệm gắn với người mua đã đăng nhập hoàn toàn không xuất hiện trong các phiên ẩn danh. Việc thu thập những dữ liệu đó là vấn đề về điều khoản dịch vụ trước khi là bài toán kỹ thuật. Thêm vào đó, dấu hiệu nhận diện cửa hàng chỉ hữu ích nếu bạn chọn đúng. Hãy lấy nó từ mã nguồn trang, không dựa vào phỏng đoán, và kiểm tra lại mỗi khi chuỗi cửa hàng thay đổi giao diện.
Kết luận chính
Giá hàng tạp hóa từng là một thông tin cố định gắn liền với sản phẩm. Giờ đây, đó là thông tin gắn liền với sản phẩm, cửa hàng và người mua. Một hệ thống thu thập chỉ ghi nhận yếu tố đầu tiên sẽ tạo ra dữ liệu nhiễu trong một schema rất gọn gàng.
Nếu định giá theo từng người mua tiếp tục phổ biến, câu hỏi mà người mua dữ liệu tạp hóa đặt ra sẽ chuyển từ "sản phẩm này có giá bao nhiêu?" sang "sản phẩm này có giá bao nhiêu tại đây, và biên độ chênh lệch là bao nhiêu?" Do đó, những hệ thống thu thập đáng tin cậy sẽ không phải là những hệ thống có nhiều proxy exit nhất. Đó sẽ là những hệ thống mà mỗi request đều có thể chỉ rõ cửa hàng mục tiêu, kèm theo bằng chứng xác thực.