Phân tích Mercado Libre năm 2026: Tại sao trình thu thập dữ liệu lại thu thập giá không đúng khu vực

Bạn đã tải lên 40.000 thẻ Mercado Libre, tính toán giá trung bình ở Argentina và gửi báo cáo. Vấn đề là đây không phải là giá ở Argentina. Đây là giá cho mã bưu chính 1430 - khu vực mặc định mà nền tảng đưa ra cho tất cả những ai không chỉ định nơi giao hàng.

Mercado Libre hoạt động tại 18 quốc gia ở Mỹ Latinh, doanh thu của nhóm trong năm 2025 đạt 28,9 tỷ đô la, công ty có 123.670 nhân viên. Đối với phân tích thương mại điện tử, đây là nguồn dữ liệu chính trong khu vực và đồng thời là cái bẫy bị đánh giá thấp nhất: nền tảng cung cấp các mức giá khác nhau, giao hàng khác nhau và người chiến thắng trong hộp mua khác nhau tùy thuộc vào nơi yêu cầu đến từ đâu và khu vực giao hàng mà phiên làm việc nhìn thấy. Hãy cùng phân tích những gì đang bị hỏng và cách thu thập dữ liệu một cách chính xác.

Những gì đã thay đổi trong năm 2026: API thực tế đã bị đóng

Chỉ vài năm trước, "parsing Mercado Libre" được giải quyết thông qua API công khai: GET api.mercadolibre.com/sites/MLA/search?q=iphone trả về kết quả mà không cần xác thực. Hôm nay, điều này không còn đúng nữa.

Kiểm tra vào ngày 12 tháng 9 năm 2026 từ một IP máy chủ thông thường, không có token:

• /sites — HTTP 403, nội dung {"code":"PA_UNAUTHORIZED_RESULT_FROM_POLICIES","blocked_by":"PolicyAgent","message":"Ít nhất một chính sách đã trả về UNAUTHORIZED."}
• /sites/MLA/search?q=iphone&limit=1 — HTTP 403, {"message":"forbidden","error":"forbidden"}
• /items/{id} — HTTP 403, cùng một PolicyAgent

Vấn đề không chỉ nằm ở việc thiếu token. Các nhà bán hàng và nhà tích hợp trong các khiếu nại công khai mô tả cùng một bức tranh với token truy cập hợp lệ: /users/me và đơn hàng phản hồi bình thường, trong khi các điểm cuối danh mục và xếp hạng trả về blocked_by: PolicyAgent. Chính sách truy cập API đang trở nên nghiêm ngặt hơn theo từng điểm cuối, và tài liệu không theo kịp.

Song song với đó, nền tảng có hai hạn chót kỹ thuật cho những ai vẫn sống trên API chính thức:

• từ ngày 30 tháng 8 năm 2026 các ứng dụng phải được tách biệt: một ứng dụng riêng cho Mercado Libre, một ứng dụng riêng cho Mercado Pago. Kiểm tra thông qua GET applications/$APP_ID — nếu trong scopes còn lại quyền kiểu urn:mp:..., ứng dụng cần được tái cấp phép, nếu không nó sẽ mất quyền truy cập vào API Mercado Libre;
• việc truyền token truy cập trong các tham số truy vấn đã được công nhận là không an toàn: các yêu cầu như vậy nền tảng sẽ bắt đầu từ chối với phản hồi 301. Token chỉ nên được gửi trong tiêu đề Authorization: Bearer.

Kết luận thực tiễn rất đơn giản: API chính thức trong năm 2026 — là kênh cho nhà bán hàng làm việc với tài khoản của mình, chứ không phải là công cụ phân tích thị trường. Nếu nhiệm vụ là theo dõi đối thủ và giá cả theo khu vực, bạn đang làm việc với cửa hàng công khai. Chúng tôi đã phân tích những gì nên chọn cho nhiệm vụ cụ thể trong tài liệu API chính thức, tập dữ liệu sẵn có hay trình phân tích riêng của bạn.

Bảy cửa hàng thay vì một trang web

Mercado Libre không phải là một danh mục với bộ lọc theo quốc gia, mà là một tập hợp các nền tảng độc lập với các miền, tiền tệ và đề xuất sản phẩm riêng. Trong API, chúng được gọi là site_id:

• MLA — Argentina (mercadolibre.com.ar, ARS)
• MLB — Brazil (mercadolivre.com.br, BRL)
• MLM — Mexico (mercadolibre.com.mx, MXN)
• MLC — Chile, MCO — Colombia, MLU — Uruguay, MPE — Peru, MLV — Venezuela

Cùng một mặt hàng trong MLA và MLB — là hai thẻ khác nhau, hai nhà bán hàng khác nhau, hai sơ đồ logistics khác nhau. So sánh chúng "trực diện" là vô nghĩa: cần phải chuẩn hóa theo tiền tệ và điều kiện giao hàng. Nhân tiện, về tiền tệ — nền tảng tự cung cấp quy tắc định dạng trong HTML: đối với Argentina, đó là "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Các trình phân tích cắt giá bằng biểu thức chính quy theo dấu chấm trên các cửa hàng Mỹ Latinh sẽ mắc lỗi gấp ngàn lần.

Điều chính: giá cả và giao hàng được tính từ khu vực của người nhận

Dưới đây là đoạn mã được nhúng ngay trong HTML của trang kết quả listado.mercadolibre.com.ar khi yêu cầu không có địa chỉ:

"location_info":{"zipcode":"1430","inferred_zipcode":false,"default_zipcode":true,"user_zone":"X19"}

Điều này được hiểu như sau: mã 1430, nó không được lấy từ IP của bạn (inferred_zipcode: false), nó mặc định (default_zipcode: true). Ở đầu trang, có thông báo "Enviar a Capital Federal" — tức là nền tảng đã im lặng quyết định rằng bạn ở khu vực thủ đô Buenos Aires, và sau đó tính toán mọi thứ chính xác cho nó.

Và nó tính toán rất nhiều. Trong cùng một HTML có các nhãn giao hàng gắn liền với khu vực: same_day_free_shipping với văn bản "Llega gratis hoy", biểu tượng vpp_full_icon — "Enviado por FULL" (sản phẩm từ kho của nền tảng). Trên một trang kết quả cho yêu cầu "iphone", có tới 96 đề cập đến giao hàng miễn phí. Khu vực cũng ảnh hưởng đến khối buy_box với "Otra opción de compra": nhà bán hàng nào sẽ thắng thẻ, được xác định một phần bởi ai rẻ hơn và nhanh hơn để giao đến mã bưu chính cụ thể.

Kết quả: trình phân tích, chưa bao giờ đặt khu vực giao hàng, thu thập không phải "thị trường Argentina", mà là một mẫu của một thành phố. Đối với báo cáo theo quốc gia với các thành phố triệu dân cách xa thủ đô hàng ngàn km, đây là một lỗi mà không có cách nào thể hiện — các con số trông có vẻ hợp lý, chỉ là chúng không trả lời đúng câu hỏi.

Rào cản ở đầu vào: /gz/account-verification

Surprise thứ hai chờ đợi ở cấp độ vận chuyển. Yêu cầu đến listado.mercadolibre.com.ar/iphone không trả về kết quả ngay lập tức: nhận được HTTP 302 đến /gz/account-verification?go=...&tid=... — trang kiểm tra thiết bị của riêng nó. Đây không phải là Cloudflare và không phải DataDome: trong mã của rào cản không có reCAPTCHA, Turnstile hay các dấu hiệu của các bot chống lại bên thứ ba, mà là hàng chục yêu cầu đến cơ chế thiết bị. Trang này nặng khoảng 41 KB, được xây dựng trên JavaScript và không hiển thị gì nếu không có nó.

Hành vi khi kiểm tra đã cho thấy điều đáng chú ý. Yêu cầu đầu tiên từ IP máy chủ sạch đã vượt qua rào cản: nhận được kết quả thực sự với 2.425.906 byte — 50 khối ui-search-layout và 120 nút giá andes-money-amount__fraction, tất cả được vẽ trên máy chủ. Các yêu cầu lặp lại từ cùng một địa chỉ đã gặp phải /gz/account-verification và không vượt qua được nữa. Các cửa hàng Brazil và Mexico từ cùng một IP hoàn toàn không cho phép.

Đây là cơ chế "đánh giá danh tiếng" điển hình: địa chỉ nhận được một tín dụng nhỏ về độ tin cậy, tiêu tốn nó sau vài yêu cầu và đóng lại. Không có bài kiểm tra đơn lẻ nào chứng minh được điều gì — điều quan trọng là không có quyền truy cập bền vững từ nhóm trung tâm dữ liệu, và hành vi khác nhau từ quốc gia này sang quốc gia khác.

Thêm một chi tiết từ tiêu đề phản hồi: nền tảng đặt _d2id (định danh thiết bị có thời hạn một năm, cũng được sao chép trong x-request-device-id) và _mldataSessionId với Max-Age=1800. Ba mươi phút — đó là độ dài tự nhiên của phiên, mà bạn nên điều chỉnh để giữ IP.

Những gì robots.txt nói

Trước khi bắt đầu thu thập, hãy đọc quy tắc của nền tảng. Trong robots.txt của cả hai cửa hàng (Argentina và Brazil), khối trên cùng là giống nhau và hoàn toàn rõ ràng:

• cấm hoàn toàn (Disallow: /) cho các crawler AI: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
• cho phép cho các bot xem trước của mạng xã hội: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
• đối với Bingbot — Crawl-delay: 5 và danh sách dài các phần bị đóng: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ và nhiều phần khác.

Từ đây dẫn đến hai điều thực tiễn. Đầu tiên: giỏ hàng, thanh toán và hồ sơ người dùng rõ ràng bị đóng — không cần phải can thiệp vào đó cả về mặt kỹ thuật lẫn pháp lý. Thứ hai: Crawl-delay: 5 cho bot tìm kiếm — đó là chỉ dẫn hợp lý về tốc độ mà nền tảng mong đợi từ tự động hóa. Năm giây cho mỗi yêu cầu từ một địa chỉ — là điểm khởi đầu hợp lý, không phải là con số từ trên trời rơi xuống.

Cách thu thập chính xác: thứ tự hành động

1. Ghi lại ma trận thu thập. Không phải "Mercado Libre", mà là danh sách các cặp "quốc gia × khu vực giao hàng". Đối với Argentina, ví dụ, đó là Capital Federal, Córdoba, Rosario, Mendoza; đối với Brazil — São Paulo, Rio, Belo Horizonte, Recife. Giá mà không chỉ định khu vực là vô nghĩa, và quyết định này được đưa ra trước dòng mã đầu tiên.
2. Lấy IP cư trú của quốc gia cần thiết. Các địa chỉ máy chủ trên các cửa hàng Brazil và Mexico không vượt qua rào cản, trong khi trên cửa hàng Argentina đã hết hạn sau yêu cầu đầu tiên. Địa chỉ cư trú địa phương giải quyết cả vấn đề truy cập và độ tin cậy: nền tảng ban đầu cho bạn thấy những gì nó sẽ cho một người mua địa phương.
3. Giữ IP trong suốt phiên. Cookie phiên sống 30 phút — việc thay đổi mỗi yêu cầu sẽ làm mất cookie và khu vực đã chọn, và bạn lại nhận được mã bưu chính mặc định. Một phiên dính trong 10–30 phút cho một khu vực, sau đó thay đổi. Cách chọn độ dài của cửa sổ, chúng tôi đã phân tích trong hướng dẫn về các phiên dính.
4. Sử dụng động cơ trình duyệt, không phải khách hàng HTTP trần trụi. Trang /gz/account-verification hoàn toàn được xây dựng trên JavaScript: nếu không thực thi các kịch bản, bạn sẽ mãi mãi ở lại rào cản. Playwright hoặc tương tự với việc giữ trạng thái giữa các bước.
5. Rõ ràng chỉ định khu vực giao hàng. Liên kết dẫn đến /addresses/v3/navigation/hub; sau khi thiết lập địa chỉ, trạng thái sống trong cookie của phiên. Chạy quy trình này một lần cho mỗi phiên, không phải cho mỗi thẻ.
6. Thực hiện location_info như một tổng kiểm tra. Trên mỗi trang đã lưu, kiểm tra rằng zipcode khớp với mục tiêu, và default_zipcode trở thành false. Nếu cờ vẫn là true — không ghi dòng vào cửa hàng dữ liệu, nó đã được thu thập không phải cho khu vực đó. Chỉ kiểm tra này đã loại bỏ phần lớn các lỗi âm thầm.
7. Lấy giá từ HTML máy chủ. Giá và nhãn giao hàng đã được vẽ trên máy chủ — không cần phải đuổi theo các điểm cuối JSON nội bộ. Đặt bên cạnh giá chính zipcode, user_zone, currency_id và dấu thời gian: không có chúng, con số không thể kiểm tra được.
8. Giữ tốc độ. Chỉ dẫn từ chính nền tảng — năm giây giữa các yêu cầu từ một địa chỉ. Cần tốc độ — mở rộng nhóm địa chỉ, không phải tần suất từ một IP: chính sự bùng nổ từ một địa chỉ sẽ đóng rào cản.

Các cạm bẫy mà bạn sẽ biết muộn

Lỗi âm thầm của khu vực mặc định. Lỗi đắt giá nhất không rơi vào ngoại lệ. Dữ liệu được thu thập, báo cáo được xây dựng, quyết định về giá cả được đưa ra — và chỉ sau một quý mới phát hiện ra rằng toàn bộ phân tích về Brazil mô tả một khu vực của São Paulo.

Kích thước trang. Một trang kết quả — 2,4 MB. Một nghìn trang mỗi ngày cho bốn quốc gia và bốn khu vực — đó là hàng chục gigabyte lưu lượng mỗi tháng. Với mức giá cư trú tính theo gigabyte, đây là khoản chi phí chính, vì vậy có lý do để ngay lập tức tắt việc tải hình ảnh và phông chữ trong động cơ trình duyệt: giá nằm trong HTML, hình ảnh cho trình phân tích — là sự lãng phí thuần túy.

So sánh các quốc gia mà không có chuẩn hóa. ARS, BRL, MXN và các dấu phân cách khác nhau. Chuyển đổi về một loại tiền tệ theo tỷ giá vào ngày thu thập và lưu giữ giá gốc và loại tiền tệ riêng biệt, nếu không thì không thể tính lại sau này.

Đặt cược vào API chính thức. Nếu việc tích hợp vẫn dựa vào API, hãy nhớ yêu cầu về các ứng dụng tách biệt từ ngày 30 tháng 8 năm 2026 và việc chuyển token từ tham số truy vấn sang tiêu đề. Mất quyền truy cập vào API một cách im lặng trông giống hệt như một lỗi trong mã của bạn.

Các loại proxy cần cho nhiệm vụ này

Proxy cư trú — là lựa chọn hiệu quả để thu thập giá và giao hàng. Cần một địa chỉ chính xác của quốc gia mà bạn đang thu thập dữ liệu từ cửa hàng của họ, và tốt nhất là khu vực mà bạn đang kiểm tra khu vực giao hàng: như vậy dữ liệu được thu thập và vẫn đáng tin cậy. Proxy cư trú với việc giữ phiên đáp ứng cả hai yêu cầu ngay lập tức.

Proxy di động — nơi mà rào cản đặc biệt cứng đầu. Mỹ Latinh là khu vực có tỷ lệ lưu lượng di động cao, và địa chỉ của nhà mạng di động trông rất bình thường đối với nền tảng. Hợp lý cho các mảnh nhỏ nhưng quan trọng, không phải cho việc xuất hàng hàng loạt.

Proxy trung tâm dữ liệu — cho các nhiệm vụ thăm dò và công việc nội bộ: đọc robots.txt, lấy cấu trúc trang, kiểm tra tính khả dụng của miền. Đối với việc thu thập giá thường xuyên, như đã chứng minh qua kiểm tra, tài nguyên không đủ.

Tóm tắt

Mercado Libre trong năm 2026 không cung cấp dữ liệu một cách ẩn danh. API chính thức đã bị đóng bởi các chính sách PolicyAgent, cửa hàng gặp phải kiểm tra thiết bị của riêng mình, và con số chính — giá với giao hàng — được tính từ khu vực của người nhận, mà nền tảng đưa ra theo mặc định nếu không được chỉ định. Trình phân tích đúng ở đây khác với trình phân tích sai không phải ở sự khéo léo trong việc vượt qua, mà ở sự kỷ luật: quốc gia, khu vực, tiền tệ và location_info bên cạnh mỗi dòng. Tất cả những điều khác là câu hỏi về việc yêu cầu của bạn đến từ đâu.