Người bán thiết lập giám sát giá cả, thấy những biểu đồ đẹp trong bảng — và quyết định giảm giá sản phẩm, mà thực tế đã rẻ hơn tất cả các đối thủ. Tình huống quen thuộc? Vấn đề không phải ở chính ý tưởng giám sát, mà ở cách thu thập dữ liệu. Phân tích bảy lỗi khiến hệ thống kiểm soát giá trở thành nguồn thông tin sai lệch, và chỉ ra cách khắc phục chúng trên thực tế.
Tại sao độ chính xác của giám sát giá là rất quan trọng cho doanh nghiệp
Giám sát giá cả của đối thủ trên Wildberries, Ozon, Avito và Yandex.Market không phải là một nhiệm vụ đơn lẻ, mà là một quá trình liên tục, mà từ đó lợi nhuận trực tiếp phụ thuộc. Nếu dữ liệu được thu thập với lỗi, người bán sẽ hoặc là giảm giá ở nơi không cần thiết, hoặc bỏ lỡ cơ hội tăng giá ở nơi mà đối thủ có giá cao hơn. Trong quy mô của một danh mục từ 500-1000 SKU, ngay cả 5-10% dữ liệu không chính xác cũng biến thành hàng ngàn rúp lợi nhuận bị bỏ lỡ mỗi tháng.
Vấn đề là các sàn thương mại điện tử đang tích cực bảo vệ mình khỏi việc thu thập dữ liệu tự động: họ hiển thị giá khác nhau tùy thuộc vào khu vực, thiết bị, lịch sử đặt hàng, và cũng chặn hoạt động nghi ngờ bằng captcha và các lệnh cấm IP tạm thời. Nếu hệ thống giám sát không tính đến những cơ chế này, nó sẽ thu thập không phải giá thị trường thực tế mà là một bức tranh bị bóp méo — và doanh nghiệp đưa ra quyết định dựa trên dữ liệu giả mạo.
Dưới đây là phân tích các lỗi cụ thể thường gặp nhất, với giải thích tại sao chúng xảy ra và cách khắc phục mà không cần đến lập trình viên.
Lỗi 1: Thu thập dữ liệu mà không có sự luân chuyển IP — bị chặn và captcha
Lỗi phổ biến nhất là khởi động giám sát từ một địa chỉ IP tĩnh hoặc từ máy chủ của trung tâm dữ liệu mà không có sự luân chuyển. Wildberries và Ozon thấy hàng trăm yêu cầu từ một IP trong khoảng thời gian ngắn và bắt đầu hoặc là hiển thị captcha, hoặc cung cấp dữ liệu bị bóp méo (ví dụ: "sản phẩm không có sẵn" hoặc giá lỗi thời từ bộ nhớ cache), hoặc hoàn toàn chặn quyền truy cập.
Kết quả là hệ thống giám sát hoặc không nhận được dữ liệu nào, hoặc nhận được một phần — và trong báo cáo xuất hiện các khoảng trống mà nhiều người diễn giải là "đối thủ không có sản phẩm này", trong khi thực tế đó chỉ là một sự chặn từ phía sàn.
Giải pháp là sử dụng một nhóm địa chỉ IP với sự luân chuyển tự động cho mỗi yêu cầu hoặc qua một khoảng thời gian nhất định. Đối với các nhiệm vụ giám sát giá trên các sàn thương mại điện tử, proxy dân cư rất phù hợp: chúng sử dụng các địa chỉ IP thực của người dùng internet bình thường, vì vậy chúng trông giống như lưu lượng truy cập hữu cơ đối với sàn, chứ không phải là một mạng bot. Điều này giảm tần suất captcha và chặn xuống hàng chục lần so với các địa chỉ từ trung tâm dữ liệu mà không có sự luân chuyển.
| Loại proxy | Phù hợp cho | Rủi ro bị chặn |
|---|---|---|
| Proxy trung tâm dữ liệu | Thu thập nhanh các danh mục nhỏ mà không có bảo vệ nghiêm ngặt | Cao trên các sàn được bảo vệ |
| Proxy dân cư | Giám sát định kỳ trên Wildberries, Ozon, Avito | Thấp |
| Proxy di động | Kiểm tra giá và khuyến mãi di động trong ứng dụng | Tối thiểu |
Lỗi 2: Bỏ qua định vị địa lý và giá cả khu vực
Wildberries và Ozon hiển thị giá khác nhau tùy thuộc vào kho hàng gửi đi, khu vực giao hàng và thậm chí là thành phố cụ thể. Sản phẩm có thể có giá 1200 rúp cho khách hàng từ Moscow và 1450 rúp cho khách hàng từ Vladivostok — do logistics khác nhau và khả năng có sẵn tại các kho khu vực.
Nếu giám sát được khởi động từ một IP, gắn liền với một khu vực, bạn chỉ nhận được giá cho khu vực đó và sai lầm khi coi đó là "giá của đối thủ" nói chung. Điều này đặc biệt quan trọng đối với những người bán hàng bán ở nhiều khu vực của Liên bang Nga hoặc làm việc với nhiều kho hàng của sàn thương mại điện tử.
Cách tiếp cận đúng là thu thập giá ngay từ nhiều điểm địa lý, mô phỏng người mua từ các thành phố khác nhau. Để làm điều này, cần có proxy với định vị địa lý theo các khu vực cụ thể của Nga. Proxy dân cư với khả năng chọn thành phố hoặc khu vực cho phép xây dựng bản đồ giá hoàn chỉnh trên toàn quốc, thay vì chỉ giới hạn ở một điểm. Điều này đặc biệt quan trọng đối với các sản phẩm có sự khác biệt lớn về chi phí logistics — quần áo, thiết bị gia dụng lớn, nội thất.
Lỗi 3: Tần suất thu thập không đúng — dữ liệu lỗi thời
Nhiều người thiết lập giám sát giá một lần mỗi ngày hoặc thậm chí vài ngày một lần, cho rằng điều đó là đủ. Nhưng các đối thủ trên Wildberries và Ozon có thể thay đổi giá vài lần trong ngày — đặc biệt trong thời gian giảm giá, chương trình "Sản phẩm trong ngày" hoặc các chương trình giảm giá flash chỉ kéo dài vài giờ.
Nếu hệ thống của bạn thu thập dữ liệu một lần mỗi ngày, bạn sẽ hoặc là bỏ lỡ các chương trình khuyến mãi ngắn hạn của đối thủ (và mất doanh số trong thời gian đó), hoặc ngược lại — phản ứng với giá đã thay đổi từ lâu, và giảm giá không cần thiết.
Tần suất tối ưu phụ thuộc vào loại sản phẩm: đối với các lĩnh vực cạnh tranh cao (điện tử, mỹ phẩm, hàng trẻ em), nên thu thập mỗi 2-4 giờ, đối với các loại ít động hơn — 1-2 lần mỗi ngày là đủ. Khi tăng tần suất thu thập, tải trọng lên hạ tầng cũng tăng — chính vì vậy việc luân chuyển IP qua proxy dân cư trở nên bắt buộc, nếu không thì các yêu cầu thường xuyên từ cùng một địa chỉ sẽ nhanh chóng dẫn đến việc bị chặn.
Lỗi 4: Thiếu mô phỏng người dùng thực tế
Các sàn thương mại điện tử phân tích không chỉ địa chỉ IP mà còn cả các mẫu hành vi: tốc độ chuyển trang, sự hiện diện của tiêu đề trình duyệt, cookies, user-agent, chuyển động của con trỏ. Nếu các yêu cầu được gửi "trực tiếp" mà không có mô phỏng trình duyệt thực tế, sàn dễ dàng phân biệt bot với con người và hiển thị các trang bảo vệ hoặc nội dung bị bóp méo.
Đối với những người bán không tham gia vào việc viết mã, giải pháp là sử dụng các trình duyệt chống phát hiện sẵn có: Dolphin Anty, AdsPower, Multilogin, Octo Browser. Những công cụ này cho phép tạo các hồ sơ với dấu vân tay kỹ thuật số độc đáo và gán một địa chỉ proxy riêng cho mỗi hồ sơ. Như vậy, mỗi "người mua ảo" vào Wildberries để kiểm tra giá sẽ trông giống như một người thực duy nhất, chứ không phải là một phần của mạng bot.
Sự kết hợp giữa trình duyệt chống phát hiện + proxy dân cư hoặc di động là một sơ đồ hoạt động mà không chỉ các nhà tiếp thị sử dụng để thu thập tài khoản quảng cáo, mà còn cả người bán để xây dựng hệ thống giám sát giá đáng tin cậy mà không bị chặn liên tục.
Lỗi 5: Bỏ qua cá nhân hóa và giá A/B
Các sàn thương mại điện tử ngày càng sử dụng cá nhân hóa giá: cùng một sản phẩm có thể được hiển thị với giá khác nhau tùy thuộc vào lịch sử tìm kiếm, đăng nhập vào tài khoản cá nhân, tham gia chương trình khách hàng thân thiết (ví dụ: Wildberries Ví) hoặc thậm chí là thử nghiệm A/B ngẫu nhiên về định giá.
Nếu giám sát được khởi động từ một tài khoản đã xác thực hoặc từ hồ sơ "đã ấm" với lịch sử mua sắm, bạn có thể nhận được giá cá nhân hóa với giảm giá, không phản ánh tình hình thị trường thực tế cho khách hàng mới. Ngược lại — nếu đối thủ thiết lập các chương trình khuyến mãi ẩn chỉ cho người đăng ký, việc thu thập dữ liệu ẩn danh sẽ không thấy chúng.
Để có được bức tranh khách quan nhất, nên kết hợp hai chế độ thu thập: ẩn danh (không có xác thực, hồ sơ sạch) cho giá thị trường cơ bản và đã xác thực (với tài khoản thử nghiệm) để theo dõi các đề nghị cá nhân và chương trình khuyến mãi khách hàng thân thiết. Cả hai chế độ nên sử dụng các nhóm IP khác nhau, không giao nhau, để sàn không liên kết chúng trong một phiên.
Lỗi 6: Vấn đề với nội dung động và JS-rendering
Thẻ sản phẩm trên Wildberries và Ozon phụ thuộc nhiều vào JavaScript: giá cả, tồn kho, giảm giá được tải động sau khi tải trang ban đầu. Nếu công cụ giám sát chỉ nhận được HTML gốc mà không thực thi các kịch bản, nó thường thấy các trường trống hoặc giá lỗi thời, được ghi lại trong bộ nhớ cache của trang trước khi áp dụng các giảm giá động.
Điều này đặc biệt rõ ràng trong các chương trình "giá khi thêm vào giỏ hàng" hoặc "giảm giá theo mã khuyến mãi", khi giá cuối cùng chỉ được hình thành sau một số hành động nhất định trên trang. Một yêu cầu đơn giản mà không có việc render đầy đủ trang sẽ không thấy được giá đó và ghi lại giá trị không chính xác.
Đối với các giải pháp sẵn có (không cần viết mã), vấn đề này thường được giải quyết bởi các dịch vụ thu thập dữ liệu chuyên dụng cho các sàn thương mại điện tử, đã tính đến việc tải động nội dung. Khi chọn một dịch vụ như vậy, hãy chắc chắn kiểm tra xem nó có chỉ ra hỗ trợ JS-rendering và giá hiện tại "có tính đến giảm giá theo chương trình" hay không, chứ không chỉ là giá cơ bản từ thẻ sản phẩm.
Lỗi 7: Thiếu xác thực dữ liệu thu thập được
Ngay cả khi thu thập dữ liệu được thiết lập đúng cách, lỗi là không thể tránh khỏi: sự cố mạng, chặn tạm thời, thay đổi cấu trúc trang của sàn thương mại điện tử. Nếu trong hệ thống giám sát không có giai đoạn kiểm tra (xác thực) các giá trị thu thập được, dữ liệu bất thường sẽ trực tiếp vào báo cáo và ảnh hưởng đến quyết định về định giá.
Ví dụ điển hình: sản phẩm có giá 2000 rúp, đột nhiên "giảm" xuống 20 rúp trong báo cáo — đây gần như luôn là lỗi thu thập dữ liệu (ví dụ: giá cho đơn vị đo lường thay vì cho bao bì), chứ không phải là một đợt giảm giá thực sự của đối thủ. Nếu không có kiểm tra tự động về các sai lệch bất thường, những lỗi như vậy dễ dàng bị hiểu nhầm là giảm giá thực sự và dẫn đến một cuộc chiến giá không cần thiết.
Quy tắc xác thực đơn giản: nếu giá mới khác với giá đã ghi nhận trước đó hơn 50% theo bất kỳ hướng nào, hệ thống nên đánh dấu bản ghi là "cần kiểm tra" và không tự động truyền nó vào mô-đun quyết định về giá. Đây là một bộ lọc cơ bản, loại bỏ hầu hết các lỗi thu thập dữ liệu nghiêm trọng.
Danh sách kiểm tra giám sát giá đúng cách
Trước khi khởi động hoặc xem xét lại hệ thống giám sát giá của đối thủ, hãy kiểm tra các điểm sau:
- Sử dụng luân chuyển IP qua proxy dân cư hoặc di động, không phải địa chỉ tĩnh từ trung tâm dữ liệu
- Thu thập dữ liệu từ nhiều khu vực, phù hợp với địa lý bán hàng của bạn
- Tần suất thu thập phù hợp với động lực của loại sản phẩm (từ 2 giờ đến 1 lần mỗi ngày)
- Các yêu cầu mô phỏng trình duyệt thực tế (qua trình duyệt chống phát hiện hoặc dịch vụ hỗ trợ fingerprint)
- Có sự phân chia giữa thu thập dữ liệu ẩn danh và đã xác thực để tính đến cá nhân hóa
- Công cụ hỗ trợ JS-rendering để nhận được giá cuối cùng có tính đến giảm giá
- Đã thiết lập xác thực tự động cho các sai lệch bất thường về giá trước khi truyền vào báo cáo
- Dữ liệu được lưu trữ với lịch sử thay đổi, không chỉ giá trị hiện tại — điều này giúp thấy được các mẫu hành vi của đối thủ
| Lỗi | Hệ quả | Giải pháp |
|---|---|---|
| Không có luân chuyển IP | Captcha, bị chặn, bỏ sót dữ liệu | Proxy dân cư với sự luân chuyển tự động |
| Bỏ qua định vị địa lý | Giá không đúng cho khu vực khác | Proxy với định vị địa lý theo thành phố của Nga |
| Thu thập hiếm | Bỏ lỡ các chương trình khuyến mãi ngắn hạn | Tăng tần suất thu thập lên 2-4 giờ |
| Không có mô phỏng trình duyệt | Các trang bảo vệ thay vì dữ liệu | Trình duyệt chống phát hiện + proxy cho mỗi hồ sơ |
| Không có xác thực | Giá bất thường trong báo cáo | Kiểm tra tự động cho các sai lệch |
Kết luận
Giám sát giá cả của đối thủ trên Wildberries, Ozon, Avito và các sàn thương mại điện tử khác mang lại lợi ích thực sự chỉ khi dữ liệu được thu thập chính xác và thường xuyên. Bảy lỗi được mô tả ở trên — bị chặn do IP tĩnh, bỏ qua định vị địa lý, tần suất thu thập không đúng, thiếu mô phỏng trình duyệt, cá nhân hóa giá, vấn đề với nội dung động và thiếu xác thực — thường gặp ở hầu hết các người bán khi bắt đầu, nhưng tất cả đều có thể khắc phục mà không cần đến lập trình viên.
Nếu bạn chỉ đang thiết lập hệ thống giám sát giá hoặc nhận thấy rằng dữ liệu hiện tại trông đáng ngờ ổn định hoặc ngược lại quá hỗn loạn, hãy bắt đầu bằng việc kiểm tra hạ tầng thu thập. Đối với việc giám sát thường xuyên danh mục trên các sàn thương mại điện tử, chúng tôi khuyên bạn nên thử proxy dân cư — chúng giảm thiểu rủi ro bị chặn và cho phép thu thập dữ liệu từ nhiều khu vực như thể đó là những người mua thực sự. Và để kiểm tra các phiên bản di động của ứng dụng và các chương trình khuyến mãi chỉ có sẵn trong lưu lượng di động, hãy xem xét proxy di động — chúng cung cấp thêm một cấp độ độ tin cậy cho dữ liệu trong các kịch bản mà phiên bản desktop cho thấy một bức tranh khác.