Một trang kết quả Google Shopping tưởng chừng rất đơn giản, nhưng thực ra có thể chen quảng cáo vào giữa các sản phẩm tự nhiên, ẩn giá khi mặt hàng hết hàng, và lặp lại cùng một sản phẩm ở tới năm nhà bán khác nhau. Trong vài tuần qua, tôi đã mổ xẻ chín công cụ tự nhận có thể “vét” đống dữ liệu lộn xộn đó thành dữ liệu sạch, dùng được — và câu trả lời thẳng thắn là: “tốt nhất” hoàn toàn phụ thuộc vào việc bạn là lập trình viên đang xây pipeline hay là marketer chỉ muốn có con số trong file spreadsheet trước thứ Sáu.
Sự phân hóa này xuất hiện ở khắp nơi trong quá trình nghiên cứu. Trên r/learnpython và r/node, mọi người bàn về Puppeteer, Playwright và xoay vòng proxy. Còn trên r/PPC, người ta lại hỏi theo kiểu gần như “chỉ đưa dữ liệu cho tôi, tôi không muốn đụng vào code”. Vì vậy, thay vì xếp chín công cụ này theo thứ tự alphabet hoặc gắn nhãn “tốt nhất tổng thể” cho nhà cung cấp có homepage bắt mắt nhất, tôi chấm điểm từng công cụ theo sáu tiêu chí cụ thể và sắp theo luồng công việc — nhóm SERP API được quản lý trước, rồi đến hạ tầng proxy và scraper, tiếp theo là nền tảng actor dành cho developer, và cuối cùng là công cụ trình duyệt no-code.
Điều gì khiến một Google Shopping Scraper trở thành “tốt nhất”? Tiêu chí chấm điểm của chúng tôi
“Tốt nhất” là một từ bị lạm dụng trong rất nhiều bài listicle, nên ở đây nó có nghĩa khá cụ thể. Tôi chấm cả chín công cụ theo cùng sáu yếu tố, thay vì lặp lại những gì trang marketing của từng nhà cung cấp nói:
- Độ bao phủ dữ liệu — schema được tài liệu hóa có trả về ổn định giá, người bán, đánh giá, số lượng review, phí ship, và phân biệt rõ giữa listing được tài trợ với listing tự nhiên hay không?
- Hỗ trợ locale/geo — bạn có thật sự nhắm được quốc gia, ngôn ngữ hoặc thiết bị cụ thể, hay chỉ phụ thuộc vào IP mà proxy tình cờ resolve ra?
- Độ phức tạp khi thiết lập — chỉ cần API key và một GET request, hay phải tạo task chờ callback, hay workflow hai bước nối token, hay chỉ cần bấm trên một trang?
- Gánh nặng bảo trì — khi Google đổi cấu trúc HTML hoặc bật CAPTCHA, ai sẽ xử lý: bạn hay nhà cung cấp?
- Đường xuất dữ liệu/tích hợp — chỉ là JSON dump, hay có thể đẩy thẳng vào Sheets, Airtable hoặc data warehouse?
- Tính minh bạch về giá — nhà cung cấp có công bố chi phí thực theo đơn vị để bạn tự tính, hay bạn phải “liên hệ sales” mới biết mọi thứ tốn bao nhiêu?
Có một điều tôi sẽ không làm ở đây là bịa ra tỷ lệ thành công, benchmark tốc độ, hay phần trăm độ chính xác. Không công cụ nào trong danh sách này tự benchmark độc lập với công cụ khác, và các tuyên bố kiểu “99.9% success” hay “blazing fast” chỉ là quảng cáo chứ không phải số đo. Thay vào đó, bạn sẽ thấy những gì tài liệu của từng nhà cung cấp thực sự chứng minh — và hóa ra như vậy đã đủ hữu ích.
Developer muốn code, marketer muốn không cần code
Nếu bạn từng lăn lộn trong các diễn đàn liên quan đến scraping, bạn sẽ biết sự chia tách này tồn tại. Nhưng vẫn nên nói rõ vì nó quyết định thứ tự của danh sách này. Developer xây dựng data pipeline muốn có API key, JSON có cấu trúc ổn định, tham số locale rõ ràng và schema có thể validate rồi normalize ở các bước sau. Họ là những người hỏi về xoay vòng proxy và render bằng headless browser.
Người làm marketing và PPC thì muốn kiểu “trỏ vào trang, lấy ra spreadsheet”. Họ không muốn phải duy trì một script Puppeteer mỗi khi Google chỉnh layout Shopping lần thứ ba trong quý này (và chuyện đó chắc chắn sẽ xảy ra — Google đổi markup Shopping đủ thường xuyên để ngay cả các nhà cung cấp API cũng phải đăng changelog về nó).
Vì vậy, danh sách này đi từ các nhà cung cấp SERP API được quản lý (SerpApi, Serper, SearchAPI, DataForSEO) — JSON có cấu trúc, không phải tự lo proxy, nhưng vẫn cần code — sang hạ tầng proxy và scraper (Bright Data, Oxylabs) vốn cho nhiều quyền kiểm soát hơn nhưng cấu hình cũng nặng hơn, rồi đến nền tảng actor tùy biến cao cho developer (Apify), và kết thúc bằng Thunderbit, một công cụ trình duyệt agentic no-code dành cho những ai thật sự không muốn viết hay bảo trì code scraping.
9 Google Shopping Scraper tốt nhất, nhìn nhanh
| Công cụ | Mô hình thu thập | Độ phức tạp thiết lập | Hỗ trợ locale | Phù hợp nhất với | Gánh nặng bảo trì |
|---|---|---|---|---|---|
| SerpApi | API Shopping được quản lý | Thấp (API key) | Mạnh (location, gl, hl, device) | Data engineer, công cụ SEO | Nhà cung cấp xử lý |
| Serper | SERP API tổng quát, Shopping là một loại kết quả | Thấp | Trung bình (có tài liệu về country/language) | Developer nhạy chi phí | Nhà cung cấp xử lý |
| SearchAPI | API Shopping + Product Offers được quản lý | Thấp–Trung bình (hai bước cho offers) | Trung bình | Nhóm so sánh offer/merchant | Nhà cung cấp xử lý |
| DataForSEO | Merchant API theo task | Trung bình (queue/callback) | Mạnh | Pipeline hàng loạt/định kỳ | Nhà cung cấp xử lý |
| Bright Data | Dataset + Scraper API + SERP API | Trung bình (tùy bề mặt) | Rất mạnh | Nhóm dữ liệu enterprise | Chia sẻ |
| Oxylabs | Hai bước search + product-detail API | Trung bình (nối token) | Rất mạnh | Nhóm dữ liệu enterprise | Chia sẻ |
| Scrapingdog | Endpoint Shopping chuyên dụng | Thấp–Trung bình | Trung bình | Developer tối ưu chi phí | Nhà cung cấp xử lý |
| Apify | Nền tảng actor/developer | Trung bình–Cao | Tùy actor | Người xây pipeline tùy biến | Người dùng tự quản |
| Thunderbit | Trích xuất trình duyệt agentic no-code | Rất thấp (One Click Extract) | Tùy trang đích | Marketer/PPC, người không biết code | Thấp, phụ thuộc trang |
(Hãy kiểm tra giá hiện tại, giới hạn credit và phạm vi locale trên tài liệu live của từng nhà cung cấp trước khi quyết định — các thông tin này thay đổi rất nhanh, và vài nhà cung cấp ở đây đã tung ra thay đổi gây ảnh hưởng vào năm 2026.)
1. SerpApi — Được quản lý, giàu tính năng, và công khai về cache
SerpApi chạy một engine Google Shopping riêng (engine=google_shopping) nhận truy vấn của bạn rồi trả về shopping_results có cấu trúc — vị trí, tiêu đề, product ID, giá cùng giá số đã trích xuất, giá cũ/trả góp, giao hàng, tình trạng, rating, review, và ảnh. Đây là một schema rất mạnh. SerpApi cũng tài liệu hóa riêng kết quả Shopping được tài trợ thông qua schema Google Ads Shopping, nên bạn có thể tìm placement được tài trợ — chỉ là không có một cờ sponsored: true/false duy nhất, đáng tin cậy, được nhúng sẵn trong response Shopping chuyên dụng.
Điểm khiến SerpApi nổi bật là cách họ nói rất rõ những thứ thường làm bạn vỡ kế hoạch ở giai đoạn sau. Tùy chọn location hỗ trợ location cấp thành phố theo chuẩn hoặc uule chính xác, cộng thêm gl (quốc gia), hl (ngôn ngữ), và device (desktop, tablet, mobile). Họ cũng nói thẳng rằng cùng một truy vấn có thể được phục vụ từ cache tối đa một giờ theo mặc định — lượt cache không tốn tiền, còn no_cache=true sẽ ép lấy dữ liệu mới. Đây là kiểu công khai thông tin mà hầu hết nhà cung cấp khác thường giấu kỹ hoặc bỏ qua.
Giá (kiểm tra ngày 2026-08-13) được công bố theo tháng: gói Free 250 lượt search, Starter $25 cho 1,000 lượt, lên tới Big Data $275 cho 30,000 lượt. Chỉ các lượt thành công mới bị tính vào quota — request bị cache hoặc thất bại không bị trừ. Một điểm cần biết: đầu năm 2026 Google đã kiện SerpApi liên quan đến phương thức truy cập dữ liệu; SerpApi bác bỏ cách mô tả đó và nói họ truy cập kết quả công khai, không cần xác thực. Đây là tình huống pháp lý đang diễn ra, không phải phán quyết cuối cùng, nên hãy xem đó là rủi ro cần theo dõi chứ không phải lý do tự động loại bỏ công cụ.
Phù hợp nhất cho: developer muốn schema Shopping giàu nhất trong tài liệu và kiểm soát rõ ràng nhất về cache và locale.
2. Serper — Nhanh, tiết kiệm, và có tuyên bố rõ nhất về độ tươi của dữ liệu
Serper định vị mình là một Google SERP API tổng quát, trong đó Shopping chỉ là một loại kết quả bên cạnh Search, Images, News, Maps và nhiều loại khác. Nếu bạn đã kéo dữ liệu tìm kiếm thường xuyên và chỉ cần thêm Shopping vào, đây là lựa chọn ít ma sát hơn nhiều so với việc dựng thêm một nhà cung cấp chuyên dụng khác.
Ví dụ Shopping công khai trả về title, nguồn, link merchant trực tiếp, giá đã định dạng, phí giao hàng, rating, số lượng rating, số lượng offer, product ID và vị trí — đủ tốt cho việc theo dõi card sản phẩm cơ bản, dù tài liệu công khai không đi sâu vào chi tiết merchant-offer hay các trường giá khuyến mại như SearchAPI hoặc Oxylabs. Điểm bán hàng rõ nhất của Serper là cam kết về độ tươi: mỗi lần gọi đều truy vấn Google trực tiếp và không dùng cache, nhờ đó bạn không phải quyết định có dùng cache hay không như với SerpApi (đổi lại là phải trả tiền cho mọi truy vấn lặp lại, dù có cache hay không).
Giá dùng mô hình credit trả trước thay vì subscription — khởi đầu với 2,500 query miễn phí, sau đó $50 cho 50,000 credit, và giảm dần tới $0.30/1,000 ở tier cao nhất; credit có hiệu lực trong sáu tháng. Trang giá cũng công khai một điều khá thẳng thắn: từng request có thể mất 2–4 giây “khi phải thử lại request tới Google”, đây là phần đuôi độ trễ thực tế mà bạn nên tính đến chứ không phải benchmark để lo lắng.
Phù hợp nhất cho: đội đã tích hợp SERP API rộng hơn và muốn Shopping như một tiện ích thêm vào, không phải sản phẩm chính.
3. SearchAPI — Chi tiết offer rất mạnh, nhưng tài liệu có một điểm vướng
SearchAPI vận hành một workflow hai bước rất hữu ích nếu bạn cần so sánh giá ở cấp người bán. Endpoint Shopping trả về các trường card quen thuộc cùng một product_token — và token này mở khóa Product Offers API riêng, trả về mảng offers với link merchant, giá, phí giao hàng, tổng giá, tình trạng hàng và phương thức thanh toán theo từng người bán. Nếu use case của bạn là “cho tôi xem mọi mức giá của đúng sản phẩm này ở các seller khác nhau”, đây là con đường trực tiếp nhất trong danh sách.
Có một điểm cần cảnh báo rõ: tính đến ngày 15/05/2026, thay đổi từ Google buộc SearchAPI phải dùng product_token mới cho mỗi request — các tham số product_id/prds cũ giờ sẽ trả về lỗi 400 thẳng. Nếu bạn tích hợp dựa trên sample code hay tutorial cũ, nó có thể hỏng mà bạn không nhận ra ngay.
SearchAPI cũng cảnh báo rõ rằng các bộ lọc bằng ngôn ngữ tự nhiên trong truy vấn (như “under $30” hoặc “used”) chỉ là gợi ý, không phải bộ lọc cứng — Google vẫn có thể trả kết quả nằm ngoài phạm vi đó khi số kết quả phù hợp quá ít. Bộ lọc mã hóa shoprs mới là cách áp dụng chặt. Và còn một mâu thuẫn tài liệu đáng chú ý: SearchAPI quảng cáo endpoint này là “real-time”, nhưng thỏa thuận xử lý dữ liệu của chính họ lại nói họ có cache kết quả để tăng hiệu năng. Không có TTL công khai cho dù theo hướng nào, nên nếu bạn quan tâm đến giá thay đổi liên tục, hãy test bằng truy vấn lặp trước khi xây pipeline dựa trên giả định dữ liệu luôn tươi.
Giá (kiểm tra ngày 2026-08-13) bắt đầu từ $40/tháng cho gói Developer ở mức $4/1,000 search, và giảm dần ở khối lượng cao hơn, với mức trần theo giờ được tài liệu hóa là 20% credit hàng tháng của bạn.
Phù hợp nhất cho: nhóm cần so sánh theo seller/offer, chấp nhận workflow hai request và tự kiểm tra độ tươi của dữ liệu.
4. DataForSEO — Dữ liệu Merchant và Shopping ở quy mô lớn, chạy theo queue
DataForSEO thực sự là trường hợp khác biệt trong nhóm này vì nó không phải API request/response trực tiếp theo thời gian thực — mà là queue theo task. Bạn POST một task với keyword, location và language, nhận về task ID, rồi hoặc poll kết quả hoặc thiết lập callback URL. Chỉ truy xuất chuẩn; core Shopping endpoints không có chế độ live, bất kể ngôn ngữ marketing tổng quát gợi ý điều gì.
Điều này quan trọng vì nó thay đổi cách nhìn về độ phức tạp thiết lập. Không hẳn là khó, nhưng nó khác hẳn mô hình “gọi API là có JSON trả về” — bạn phải quản lý trạng thái task, và tài liệu của DataForSEO nói rõ rằng nếu server callback không phản hồi trong vòng 10 giây thì task sẽ bị đẩy vào hàng đợi “Tasks Ready”, sau đó bạn phải poll thủ công.
Điểm khiến nó có chỗ trong danh sách là khả năng research hàng loạt: endpoint Products trả về rank, domain, title, price, giá cũ, rating và số vote, với mã loại kết quả phân biệt rõ google_shopping_sponsored_carousel với google_shopping_paid và kết quả organic — đây là một trong những cách phân biệt sponsored/organic rõ ràng nhất trong toàn bộ danh sách. Nó cũng cảnh báo rất minh bạch rằng product_id là động và đôi khi có thể là null, đồng thời các yếu tố xếp hạng cá nhân hóa (lịch sử người dùng, sở thích vị trí) được loại trừ có chủ đích khỏi kết quả — một bài kiểm tra trung thực mà nhiều nhà cung cấp khác bỏ qua.
Giá tính theo từng block kết quả (40 cho Products, 10 cho Sellers/Reviews) với tốc độ queue thường tối đa 45 phút, hoặc queue ưu tiên tối đa một phút nhưng giá gấp đôi. Tài khoản mới nhận $1 credit dùng thử không hết hạn.
Phù hợp nhất cho: nhóm thoải mái với workflow theo queue, theo task, và cần dữ liệu merchant/product hàng loạt theo lịch.
5. Bright Data — Ba sản phẩm nhưng chung một nhãn
Đến đây tôi cần nói chậm lại, vì Bright Data thực ra cung cấp ba cách khác nhau để lấy dữ liệu Google Shopping, và chúng hoạt động hoàn toàn không giống nhau. Có một dataset được thu thập sẵn (được quảng bá là hơn 7.4 tỷ bản ghi, giao dưới dạng JSON/CSV/Parquet vào cloud warehouse của bạn theo lịch), một Google Scraper API với các scraper ID chuyên dụng cho Shopping chạy job đồng bộ hoặc bất đồng bộ, và một SERP API lấy live Shopping URL rồi parse kết quả theo thời gian thực. Xem ba thứ này như một sản phẩm duy nhất là cách nhiều bài so sánh làm ẩu — ở đây tôi không làm vậy.
Dữ liệu mẫu của dataset chính họ cho thấy một số record có giá trị null cho product ID, description, rating và review count — bằng chứng từ chính nguồn rằng “structured dataset” không có nghĩa mọi trường đều luôn có dữ liệu. SERP API lại tài liệu hóa Product Listing Ads như các loại kết quả riêng (top_pla, bottom_pla, jackpot_pla) với title, price, shop và rank — rất hữu ích nếu bạn làm việc với riêng SERP API chứ không phải dataset.
Các async job qua Scraper API có thể trả overall “success” dù từng input trong batch bị lỗi — tài liệu yêu cầu kiểm tra trường errors và retry riêng từng mục đó, đây là chi tiết bảo trì đáng chú ý nếu bạn chạy batch lớn.
Giá (kiểm tra ngày 2026-08-13) thay đổi rất nhiều theo bề mặt: dataset hiển thị $250 cho 100,000 bản ghi một lần, SERP API liệt kê 5,000 request miễn phí mỗi tháng với pay-as-you-go $1.50/1,000, và dedicated Shopping Scraper API lại có tier miễn phí và mức giá riêng. Đừng coi các con số này là có thể thay thế cho nhau — hãy kiểm tra đúng trang sản phẩm bạn thực sự dùng.
Phù hợp nhất cho: nhóm enterprise muốn một nền tảng bao phủ cả dataset có sẵn lẫn API live, và sẵn sàng định giá riêng từng bề mặt.
6. Oxylabs — Chuỗi hai bước rõ ràng nhất cho search + chi tiết sản phẩm
Oxylabs tách Shopping thành hai target chuyên dụng: google_shopping_search cho kết quả ở cấp listing, và google_shopping_product cho dữ liệu chi tiết theo từng sản phẩm, được nối với nhau bằng product token. Response tìm kiếm phân biệt rất gọn pla (paid listing ads) với sản phẩm organic — có lẽ là cách phân tách sponsored/organic được tài liệu hóa rõ nhất trong toàn bộ danh sách — còn endpoint sản phẩm bổ sung offer theo từng seller với giá số, tình trạng, thuế, tổng giá và phí ship.
Điểm khó, và là khó thật: workflow token này chỉ hoạt động nếu request tìm kiếm của bạn dùng cả render: "html" lẫn parse: true. Thiếu một trong hai, bạn sẽ không nhận được product token, và bước chi tiết sản phẩm sẽ hỏng. Oxylabs cũng cảnh báo rõ rằng request search và product phải dùng giống hệt nhau về giá trị localization — nếu lệch geo_location giữa hai lần gọi, kết quả sản phẩm có thể thiếu hoặc sai. Và nếu bạn muốn mở rộng panel “More stores” để thấy thêm offer từ các seller khác, bạn cũng phải bật rendering, đồng nghĩa chi phí tăng thêm.
Một chi tiết dễ bỏ lỡ: FAQ giá của Oxylabs định nghĩa các request “successful” — và vì vậy bị tính tiền — là bao gồm cả response 2xx và 4xx. Nếu request của bạn bị sai định dạng, bạn vẫn có thể bị tính phí.
Product reviews được tài liệu hóa là chỉ dành cho locale US, và locale/language với locale/results-language là hai điều khiển thật sự tách biệt — đặt một cái không tự động đặt cái còn lại.
Phù hợp nhất cho: nhóm kỹ thuật cần cả dữ liệu cấp ranking lẫn offer theo từng seller, và có thể xử lý nối token cùng tính nhất quán locale như một phần của setup.
7. Scrapingdog — Endpoint đơn giản, tài liệu công khai khá mỏng
Scrapingdog cung cấp một endpoint Google Shopping chuyên dụng, nhận API key và query rồi trả JSON với title, giá và giá số đã trích xuất, giá cũ, rating, review, nguồn/người bán, giao hàng và vị trí. Trang này cũng nói đến lọc theo giá, thương hiệu, quốc gia và ngôn ngữ, cùng một danh mục phản hồi “ads” riêng để theo dõi listing được tài trợ — nhưng schema ads cụ thể và tên tham số chính xác cho lọc locale không được tài liệu hóa đầy đủ trên trang công khai, nên bạn nên dành thời gian test với use case của mình trước khi xây tự động hóa.
Đây là mục duy nhất trong danh sách mà phép tính chi phí credit đơn giản là không khớp chỉ từ tài liệu công khai: trang giá của Scrapingdog cho thấy hạn mức credit theo tháng (LITE $40/tháng cho 200,000 credit, STANDARD $90/tháng cho 1,000,000 credit) nhưng không nêu rõ một request Google Shopping tiêu tốn bao nhiêu credit. Đừng mặc định là 1:1 với ví dụ chung của API tìm kiếm — hãy xác minh trực tiếp với nhà cung cấp trước khi tính chi phí thật trên mỗi query.
Giống hầu hết các vendor ở đây, Scrapingdog quảng bá proxy residential xoay vòng tích hợp sẵn và tự động xử lý CAPTCHA do nhà cung cấp quản lý. Hãy xem đó là một tuyên bố về ranh giới bảo trì, chứ không phải bằng chứng cho quyền truy cập được bảo đảm.
Phù hợp nhất cho: developer nhạy chi phí, muốn một endpoint chuyên dụng hẹp và sẵn sàng xác minh chi phí credit trực tiếp trước khi ký.
8. Apify — Hãy đánh giá actor, không phải marketplace
Tôi cần nói rõ một điều: Apify không phải một Google Shopping scraper duy nhất — mà là một marketplace gồm nhiều “Actor” do các bên độc lập duy trì, và actor tôi xem kỹ ở đây (Google Shopping Insights, do developer epctex xuất bản và được gắn nhãn “Maintained by Community”) hoạt động rất khác các công cụ do nhà cung cấp vận hành ở trên. Apify cung cấp runtime, hạ tầng proxy và công cụ dataset/export. Logic trích xuất Shopping thực tế — và việc bảo trì nó — thuộc về epctex, không phải Apify.
Sự khác biệt này quan trọng vì output ví dụ chính thức của actor này có trường price bị null. Không phải “thỉnh thoảng”, không phải “với hàng hết stock” — record mẫu trong tài liệu chính nó đã hiển thị price: null và withoutDiscountPrice: null ngay cạnh các trường tên sản phẩm, merchant và rating đã có dữ liệu. Đây thực sự là bằng chứng trực tiếp mạnh nhất trong toàn bộ bài tổng hợp này rằng bạn không thể mặc định dữ liệu giá luôn đầy đủ, và nó đến thẳng từ tài liệu của công cụ.
Bạn có các input có thể cấu hình — includeSponsoredResults, includeComparisonPrices cho giá giữa các merchant, nhắm country code, maxItemsPerQuery — và cần cấu hình proxy bắt buộc (của bạn hoặc của Apify). Kết quả có thể xuất ra JSON, XML, CSV hoặc Excel thông qua hệ thống Dataset của Apify. Trang Store tôi kiểm tra cho thấy tổng cộng khoảng 2,300 người dùng nhưng chỉ 2 người dùng hoạt động hàng tháng tại thời điểm đó — một chỉ số đáng lưu ý vì “community maintained” là con dao hai lưỡi: linh hoạt, nhưng độ tin cậy chỉ ngang với những người đang tích cực dùng và báo lỗi cho nó.
Phù hợp nhất cho: developer thoải mái khi phải tự đánh giá mức độ bảo trì của một actor cụ thể và xem schema output thực tế trước khi dùng — không phù hợp với ai nghĩ rằng thương hiệu Apify tự nó sẽ bảo đảm hành vi ổn định.
9. Thunderbit — Thu thập no-code cho marketer
Thunderbit đại diện cho đầu kia của danh sách này: một workflow no-code chạy trên trình duyệt dành cho những ai muốn nhìn thấy trang họ đang xem rồi biến nó thành một bảng có cấu trúc, thay vì tích hợp Google Shopping API. Điều đó khiến nó trở thành lựa chọn tự nhiên cho marketer, người chạy PPC và các team ecommerce nhỏ làm các lần kiểm tra ad-hoc thay vì một pipeline backend khối lượng lớn.
Cách bạn dùng là trích xuất ngay trong trình duyệt: mở trang Shopping mà bạn thật sự quan tâm, để Thunderbit đọc trang đã render chỉ với một cú click, rồi xuất các trường thẳng sang Excel, Google Sheets, Airtable hoặc Notion. Có một lưu ý thực tế, nhưng nó thuộc về Shopping hơn là riêng công cụ nào: vì việc trích xuất chạy trên chính trang đang mở trước mắt bạn, kết quả sẽ mang theo location, ngôn ngữ và session của trình duyệt đó. Hãy cố định các thiết lập này trước khi coi dữ liệu tuần này là tương đương với tuần trước. Đây cũng chính là vấn đề độ tin cậy trường dữ liệu mà phần tiếp theo sẽ bàn tới, và nó áp dụng cho mọi lựa chọn trong danh sách này.
Phù hợp nhất cho: đội không kỹ thuật, ưu tiên trích xuất trên trình duyệt có thể nhìn thấy và kiểm tra được thay vì pipeline JSON do developer quản lý — và chỉ cần lấy các trang Shopping cụ thể theo nhu cầu chứ không chạy crawl đa địa lý, khối lượng lớn.
Bạn thực sự có thể tin cậy dữ liệu nào? Vấn đề độ tin cậy của trường dữ liệu
Đây là phần mà hầu hết bài so sánh Google Shopping bỏ qua hoàn toàn, và cũng là điều quan trọng nhất bạn cần hiểu trước khi tự động hóa bất cứ thứ gì: không phải trường nào cũng xuất hiện trên mọi listing, và coi “thiếu” là “0” sẽ âm thầm làm hỏng dữ liệu của bạn.
| Trường | Độ tin cậy | Điểm cần lưu ý |
|---|---|---|
| Title | Cao | Chuẩn hóa các biến thể/bundle trước khi đối sánh sản phẩm giữa các nguồn |
| Product ID | Có điều kiện | DataForSEO tài liệu hóa rõ đây là giá trị động và đôi khi là null |
| Price | Có điều kiện | Ví dụ chính thức của Apify hiển thị null price trên một record hoàn chỉnh |
| Seller/merchant | Thường có | Listing nhiều seller nghĩa là một sản phẩm có thể có nhiều offer riêng |
| Rating/số review | Có điều kiện | Sản phẩm mới hoặc chưa được đánh giá có thể không có — đừng ép thành zero |
| Shipping/delivery | Không ổn định | Có thể phụ thuộc vào điểm đến, tồn kho của seller và session |
| Sponsored flag | Phụ thuộc công cụ | Oxylabs tách rõ pla khỏi organic; một số công cụ khác cho phép include/exclude sponsored results nhưng không cho bạn một nhãn per-row thật đáng tin |
Quy tắc thực tế: trước khi tự động hóa bất kỳ workflow nào, hãy kéo một mẫu thật bằng đúng keyword của bạn và xem chính xác những gì đang null, bị lặp hoặc bị thiếu — chứ không phải những gì tài liệu ngụ ý là phải có.
Google Merchant Center chính thức vs. Google Shopping Scraper: Bạn cần cái nào?
Đây là câu hỏi các team ecommerce thường đặt ra trước cả khi bắt đầu so sánh vendor, và đáng để trả lời thẳng: nếu bạn đang quản lý listing, giá hoặc Shopping ads của chính mình, đó là công việc dành cho công cụ Merchant Center chính thức của Google — không phải scraper của bên thứ ba. Các công cụ scraping trong danh sách này dành cho việc quan sát listing của người khác: giá đối thủ, độ hiện diện trên thị trường, nghiên cứu danh mục, theo dõi placement được tài trợ. Đừng nhầm lẫn hai việc này. Hãy kiểm tra trực tiếp tài liệu chính thức hiện tại của Google để biết tên và phạm vi của API first-party, vì những thứ này thường xuyên được đổi tên và tái cấu trúc.
Các công cụ này xử lý phòng thủ chống bot của Google như thế nào
Tôi sẽ nói về điều này như một câu hỏi quản trị, chứ không phải tutorial “làm sao vượt Google”, vì đó mới là cách nhìn trung thực. Nhiều vendor ở đây — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — công khai rằng họ tự quản lý xoay vòng proxy, render bằng trình duyệt và xử lý CAPTCHA ở phía họ. Đó là một ranh giới bảo trì rất đáng giá: nghĩa là bạn không phải là người ngồi debug IP bị chặn lúc 2 giờ sáng. Nhưng điều đó không, và không bao giờ nên được hiểu là, một lời đảm bảo truy cập vĩnh viễn hoặc toàn cầu.
Điều không biến mất ngay cả khi dùng vendor được quản lý hoàn toàn: kiểm soát tốc độ và chi phí, phân loại lỗi, retry, và monitoring khi Google thay đổi điều gì đó (mà dựa trên changelog tôi tìm thấy của cả SearchAPI và Oxylabs, chuyện này xảy ra khá thường xuyên). Bright Data tài liệu hóa rõ các lỗi một phần trong batch; DataForSEO tài liệu hóa hành vi timeout của callback; Oxylabs tài liệu hóa lỗi token không hợp lệ. Tất cả điều này không phải hướng dẫn vượt qua gì cả — chỉ là cách ghi nhận trung thực ai đang chịu trách nhiệm cho từng chế độ lỗi.
Cách chọn Google Shopping Scraper tốt nhất cho đội của bạn
Đi theo thứ tự này:
- Xác định persona của bạn. Bạn là developer đang xây pipeline, hay là marketer/ops muốn có kết quả mà không đụng code?
- Xác định thật rõ các trường bạn cần. Dữ liệu cấp ranking khác với chi tiết giá cấp merchant/offer — SearchAPI và Oxylabs nổi bật chính ở phần sau.
- Thành thật về năng lực bảo trì của đội. Mapping API và xử lý lỗi, cấu hình Actor và proxy, hay trích xuất trên trang đã review — hãy chọn thứ đội của bạn có thể thực sự tự vận hành lâu dài.
- Test hành vi locale/device bằng truy vấn thật trước khi cam kết với một vendor, vì tài liệu công khai không phải lúc nào cũng khớp hoàn toàn với hành vi thực tế.
- Kiểm tra đường xuất dữ liệu có phù hợp với stack hiện có của bạn không — một JSON dump vào data warehouse hoàn toàn khác với một spreadsheet mà marketer có thể mở ngay.
Kết luận: Bạn nên dùng Google Shopping Scraper nào?
Không có một lựa chọn “tốt nhất” duy nhất ở đây, và nếu một bài listicle nói khác đi thì bạn nên dè chừng. Nếu bạn là developer xây data pipeline và muốn schema tài liệu phong phú nhất cùng khả năng kiểm soát cache và locale rõ ràng, hãy bắt đầu với SerpApi. Nếu mục tiêu thực sự của bạn là so sánh giá theo từng seller ở cấp offer, workflow nối token của SearchAPI hoặc Oxylabs sẽ đưa bạn đến đích trực tiếp hơn. Nếu bạn chạy nghiên cứu hàng loạt theo lịch và chấp nhận queue task, DataForSEO mở rộng rất tốt. Nếu bạn muốn một nền tảng enterprise bao phủ cả dataset có sẵn lẫn truy vấn live, Bright Data là lựa chọn rộng nhất — chỉ cần định giá riêng từng bề mặt.
Và nếu bạn là người làm PPC hoặc marketing, không muốn đụng tới API key, thì nhóm công cụ chạy trên trình duyệt mà Thunderbit đại diện chính là câu trả lời trực diện cho câu “tôi chỉ cần dữ liệu, không cần một dự án code”. Chỉ cần nói rõ bạn đang chọn bề mặt nào: workflow trình duyệt được thiết kế cho các trang bạn tự mở và tự xem, còn API documentation và CLI của Thunderbit là các đường đi riêng dành cho developer. Hãy chọn thứ khớp với cách đội của bạn thực sự làm việc.
Dù bạn chọn gì, hãy lấy một mẫu thật trước. Mỗi vendor ở đây đều tài liệu hóa ít nhất một trường không phải lúc nào cũng có — hãy kiểm tra dữ liệu của bạn trước khi xây bất cứ thứ gì lên trên nó.
Câu hỏi thường gặp
Scrape dữ liệu Google Shopping có hợp pháp không? Đây không phải câu hỏi tôi có thể trả lời theo kiểu tuyệt đối, và cũng không bài listicle nào nên làm vậy. Dữ liệu công khai nhìn thấy được và các tuyên bố tuân thủ của vendor không tự động làm cho mọi trường hợp sử dụng trở thành hợp pháp. Trước khi xây bất cứ thứ gì, hãy kiểm tra điều khoản dịch vụ hiện tại của Google, xem xét luật áp dụng tại khu vực pháp lý của bạn, và đảm bảo phương thức thu thập của bạn được cho phép. Hãy coi đây là tình huống “cần tự kiểm tra với luật sư của bạn”, chứ không phải điều một bài blog có thể quyết định thay.
Khác nhau giữa SERP API và Google Shopping scraper là gì? SERP hoặc Shopping API nhận các tham số request có cấu trúc rồi trả về JSON đã parse — vendor chịu phần lớn hạ tầng thu thập. Một scraper chạy trên trình duyệt (như Thunderbit) sẽ trích xuất từ một trang mà bạn hoặc người dùng thực sự đang mở. Các sản phẩm dạng dataset (như một phần trong offerings của Bright Data) thì giao bản ghi đã thu thập sẵn theo lịch thay vì request live. Chúng có cùng mục đích ở mức tổng quát nhưng khác rất nhiều về độ tươi dữ liệu, kiểm soát locale và lượng việc bạn thật sự phải tự vận hành.
Tôi có cần biết code để scrape Google Shopping không? Không phải lúc nào cũng cần. Toàn bộ thông điệp của Thunderbit là workflow no-code, bấm là chạy, đúng vì lý do này. Apify về mặt kỹ thuật có thể chạy qua web UI mà không cần viết code, dù để tùy biến thật sự thì vẫn cần chút nền tảng kỹ thuật. Mọi công cụ dựa trên API trong danh sách này — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — đều cần tối thiểu kỹ năng developer cơ bản: xác thực, xử lý tham số và kiểm tra lỗi.
Dữ liệu Google Shopping thay đổi bao lâu một lần? Thường xuyên hơn nhiều người nghĩ, nhưng không có quy tắc chung kiểu “mỗi X giờ cập nhật một lần” để bạn có thể tin hoàn toàn. Giá, tồn kho, vị trí được tài trợ và thứ hạng có thể thay đổi theo session, locale và thời điểm trong ngày. Một số vendor ở đây cung cấp chế độ live/real-time chính xác vì dữ liệu cache sẽ nhanh chóng lỗi thời trong danh mục này. Nếu quyết định của bạn phụ thuộc vào giá hiện tại, hãy chạy lại truy vấn thay vì tin vào kết quả từ hôm qua.
Tìm hiểu thêm
