Loading Light/Dark Toggle
Trích xuất Dữ liệu từ Trang Sản Phẩm Động trên Các Cửa Hàng Headless Commerce

Cách Trích Xuất Dữ Liệu từ Trang Sản Phẩm Động trên Các Cửa Hàng Headless Commerce

Scrapeless Agent Browser render các storefront JavaScript trong các phiên trình duyệt được quản lý, và Scrapeless Residential Proxies hỗ trợ truy cập theo vị trí cho các phiên thu thập được ủy quyền theo vùng.

TL;DR

  • Một trang sản phẩm headless có thể có nhiều dạng thể hiện khác nhau. So sánh HTML ban đầu, dữ liệu storefront được tài liệu hóa và offer cuối cùng hiển thị cho người mua.
  • Việc chọn biến thể cần một điều kiện sẵn sàng có ý nghĩa. Tương quan biến thể đã chọn, thị trường và response trước khi chấp nhận mức giá đã render.
  • Bằng chứng từ mạng và trạng thái hiển thị bổ sung cho nhau. Một response có thể thuộc về một biến thể được prefetched hoặc mặc định mà người mua không bao giờ chọn.
  • Một quan sát theo vùng cần có bằng chứng về thị trường. Xác nhận loại tiền tệ và thị trường đã render ngay cả khi kết nối sử dụng proxy nhắm mục tiêu theo vị trí.

Xác Định Bề Mặt Nào Sở Hữu Offer

Các storefront headless commerce tách giao diện mua sắm khỏi các dịch vụ thương mại backend, vì vậy thông tin sản phẩm có thể xuất hiện trong HTML ban đầu, state của ứng dụng, các response và trang đã render. Hãy chọn nguồn trả lời cho câu hỏi thu thập cụ thể. Nếu cửa hàng cung cấp một API hoặc feed được tài liệu hóa cho bạn sử dụng, nó có thể là đủ cho danh tính danh mục. Nếu bạn cần mức giá mà người mua nhìn thấy sau khi chọn thị trường và biến thể, hãy xác minh cả trạng thái đã render.

Dùng công cụ so sánh HTML ban đầu và một phiên trình duyệt thực song song. Một trang có thể gửi tiêu đề sản phẩm và số tiền mặc định từ server, sau đó hydrate các control và hiển thị offer của biến thể đã chọn. Một trang khác có thể render offer đã chọn trên server và chỉ dùng trình duyệt để thay đổi biến thể. Chọn biến thể sản phẩm trên Hydrogen mô tả cách một framework sử dụng các route storefront nhận biết biến thể và dữ liệu. Hãy kiểm tra cửa hàng cụ thể trước khi giả định một cách triển khai nào đó.

Tách riêng nhóm sản phẩm, biến thể và thị trường trong thỏa thuận thu thập của bạn. Từ vựng ProductGroup phân biệt một nhóm với các biến thể thuộc về nó. Một URL sản phẩm chuẩn có thể nhận diện một họ sản phẩm ngay cả khi biến thể được chọn nằm trong tham số query hoặc thay đổi state. Lưu cả URL nhóm chuẩn khi biết và URL thực tế được quan sát trong quá trình thu thập.

Yêu Cầu Tiên Quyết và Cài Đặt

Sử dụng một dự án Node.js với gói Playwright và Chromium. Cài đặt runtime Chromium của Playwright hoặc cấu hình một trình duyệt tương thích sẵn có. Chọn một storefront đã được phê duyệt hoặc một fixture kiểm thử tách biệt. Bao gồm một biến thể thay đổi số tiền, một tùy chọn không khả dụng và một thị trường sử dụng loại tiền tệ khác. Một lần chạy từ xa yêu cầu tài khoản Scrapeless và các thiết lập kết nối Agent Browser đã được tài liệu hóa.

Sử dụng công cụ dành cho nhà phát triển trên storefront đã được phê duyệt để kiểm tra quá trình tải, các control và các request. Xác nhận xem việc thu thập là cho dữ liệu sản phẩm hay bằng chứng offer hiển thị cho người mua. Nếu một trang web cung cấp giao diện đã được tài liệu hóa cho bạn sử dụng, hãy lấy quyền truy cập phù hợp và tôn trọng phạm vi của nó. Một request xuất hiện trong công cụ nhà phát triển không tự động thiết lập một giao diện ổn định hoặc trao cho bạn quyền thu thập độc lập từ nó.

Bước 1. Khám Phá Sản Phẩm và Thị Trường Được Chọn

Bắt đầu từ một nguồn danh mục được cho phép hoặc các URL sản phẩm đã biết và ghi lại ngữ cảnh thị trường bạn dự định quan sát. Thực hiện điều hướng bình thường và ghi nhận route cuối cùng. Tìm một chỉ báo thị trường hoặc loại tiền tệ đã render, đặc biệt khi route ban đầu bị chuyển hướng. Trên các cửa hàng phơi bày locale và thị trường độc lập, hãy ghi cả hai. Ngôn ngữ của tiêu đề sản phẩm là không đủ để xác định loại tiền tệ hoặc vùng giao hàng.

Tiêu chuẩn URL Standard giải thích các thành phần mà trình duyệt sử dụng khi resolve và tuần tự hóa URL. Xử lý các thành phần đó theo hành vi của cửa hàng. Tham số theo dõi có thể không liên quan đến danh tính, trong khi tham số query cho việc chọn biến thể thực sự thì quan trọng với bằng chứng. Hãy kiểm tra trang với và không với tham số đó trước khi chuẩn hóa route.

Bước 2. Tương Quan Một Response Biến Thể và Xác Minh Giao Diện Người Dùng

Một response offer chỉ hữu ích khi nó tương ứng với tương tác và trạng thái dự định. Đăng ký listener trước hành động, khớp origin mong đợi và hình dạng request, và xác minh biến thể cùng thị trường đã chọn. Sau đó chờ đến khi các giá trị mong đợi được commit vào offer đã render. Tránh dùng một khoảng trễ tải chung chung như tín hiệu rằng mọi cập nhật bất đồng bộ đã hoàn tất.

Ví dụ sau chạy trên một fixture storefront được kiểm soát, fixture này cung cấp một response offer và cập nhật panel sản phẩm sau khi nhấn nút. Đường dẫn, selector và các trường payload là đặc thù của fixture. Chỉ điều chỉnh chúng sang các giao diện và control trang mà bạn có thể xác minh trên cửa hàng mục tiêu. Đối với tích hợp dựa trên GraphQL, một tên operation được phê duyệt và các biến input liên quan có thể nhận diện một response khi một endpoint dùng chung xử lý nhiều request.

async function readMarketVariant(page, targetUrl, variant, market) {
  await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
  await page.getByTestId('product-ready').waitFor({ state: 'visible' });

  // Register the response listener before selecting the variant.
  const data = page.waitForResponse(response => {
    const url = new URL(response.url());
    return url.origin === new URL(targetUrl).origin &&
      url.pathname === '/fixture/offer' &&
      url.searchParams.get('variant') === variant &&
      url.searchParams.get('market') === market &&
      response.request().method() === 'GET' && response.ok();
  }, { timeout: 5000 });
  await Promise.all([
    data,
    page.getByRole('button', { name: variant, exact: true }).click()
  ]);

  const offer = await (await data).json();
  const panel = page.getByTestId('rendered-offer');
  await panel.getByText(offer.display, { exact: true }).waitFor();
  const visible = await panel.evaluate(node => ({
    variant: node.dataset.variant,
    market: node.dataset.market,
    currency: node.dataset.currency,
    display: node.querySelector('[data-testid="amount"]').textContent.trim()
  }));
  if (offer.variant !== variant || offer.market !== market ||
      visible.variant !== variant || visible.market !== market ||
      visible.currency !== offer.currency || visible.display !== offer.display) {
    throw new Error('Offer response and rendered state disagree');
  }
  return { url: page.url(), ...visible, observedAt: new Date().toISOString() };
}

Fixture chọn Olive, nhận một offer GBP cho thị trường GB và xác minh hiển thị £74.00. Nó sẽ thất bại khi thị trường hoặc biến thể đã render khác với response. Các storefront thực có thể hydrate mà không gửi một request mới, ví dụ khi dữ liệu cần thiết đã được cung cấp hoặc prefetched. Trong trường hợp đó, hãy chọn một kiểm tra trạng thái đã render đã được xác minh, có thể nhận diện offer đã chọn mà không trông đợi một sự kiện sẽ không bao giờ xảy ra.

Bước 3. Diễn Giải Giá Sản Phẩm, Tồn Kho và Các Offer Có Điều Kiện

Từ vựng Offer vocabulary cung cấp các trường cho giá, đơn vị tiền tệ và tình trạng sẵn có. Hãy để số tiền gốc và số tiền đã chuẩn hóa ở các trường riêng, và giữ giá khuyến mãi, giá niêm yết và giá thành viên tách biệt khi chúng xuất hiện. Một cửa hàng headless có thể chỉ hiển thị thông báo về phí vận chuyển hoặc thuế sau khi biết vị trí. Xác định những thành phần mà hợp đồng dữ liệu của bạn yêu cầu và giữ các khoản tiền có điều kiện ra khỏi chế độ xem giá tiền mặt có thể so sánh cho đến khi chúng được xác minh.

Hãy kiểm tra biến thể đã chọn khi chuyển từ một tùy chọn sang tùy chọn khác, ngay cả khi số tiền hiển thị giữ nguyên. Hai biến thể có thể có giá bằng nhau, điều này khiến việc chỉ chờ văn bản trở nên không đáng tin cậy. Hãy kiểm tra các dấu hiệu trạng thái hoặc bằng chứng nhận dạng khác. Ví dụ sẽ kiểm tra cả phản hồi và nhận dạng bảng điều khiển sau khi số tiền hiển thị được ổn định. Trên một cửa hàng do bạn vận hành, hãy cung cấp một dấu hiệu sẵn sàng có phiên bản nếu bạn cần một điều kiện tập hợp ổn định duy nhất.

Hãy giữ tình trạng sẵn có tách biệt với việc điều hướng thành công. Một phản hồi trình duyệt hợp lệ có thể hiển thị một mặt hàng hết hàng, một biến thể không khả dụng, một chuyển hướng hoặc một thông báo gián đoạn hoạt động của cửa hàng. Lưu kết quả theo từng loại để một giá trị trống không trở thành cảnh báo sai về giá thấp. Sử dụng các trường hợp mẫu được thiết kế để cố ý không hiển thị đầy đủ một ưu đãi và xác nhận rằng đường ống phía sau giữ chúng ngoài các phép so sánh đã được chấp thuận.

Bước 4. Gán trách nhiệm cho Trình duyệt và Proxy

Sử dụng Scrapeless Agent Browser khi Playwright cần thực thi storefront và tương tác với các điều khiển của nó. Giải pháp Agent Browser solution for dynamic websites bao phủ các quy trình làm việc dựa trên trình duyệt. Sử dụng Residential Proxies khi một hoạt động quan sát được ủy quyền yêu cầu một vị trí mạng đã chọn. Giải pháp proxy price monitoring solution liên quan trong trường hợp cùng một danh mục cần được so sánh lặp lại giữa các thị trường. Trình duyệt thực thi trang và proxy cung cấp tuyến mạng. Việc chấp nhận của thị trường thuộc về logic thu thập.

Tài liệu Playwright guide for Shopify variant data đưa ra một ví dụ khác về việc chọn đúng nguồn trước khi trích xuất. Ước lượng khối lượng công việc trực tiếp bằng Scrapeless pricing sau khi bạn đo thời gian các phiên trình duyệt được mở và lượng truyền tải mạng mà mỗi khu vực tiêu thụ. Gom nhóm các trang có hành vi tương tự để một mẫu tương tác phức tạp không làm sai lệch ước tính cho các trang sản phẩm đơn giản hơn.

Những gì bạn nhận lại

Một sự kiện có thể xem xét lại chứa URL nguồn, khóa sản phẩm hoặc biến thể, thị trường, tiền tệ, số tiền hiển thị, thời gian quan sát và nguồn thu thập. Thêm tình trạng sẵn có và người bán khi nguồn hiển thị chúng và hợp đồng cần chúng. Giữ một biểu diễn đã chuẩn hóa cho phân tích phía sau và một bản ghi gọn về lý do việc thu thập được chấp nhận. Bằng chứng có thể bao gồm tùy chọn đã chọn, các trường phản hồi liên quan và một ảnh chụp màn hình trong phạm vi khi trường hợp sử dụng yêu cầu.

Xác minh trạng thái Storefront trước khi mở rộng quy mô

Chọn một sản phẩm đã biết và so sánh HTML ban đầu, dữ liệu có cấu trúc đã được chấp thuận và ưu đãi đã render. Tự động hóa việc lựa chọn chính xác và ghi lại những gì thay đổi sau hành động. Mở rộng phạm vi khi bộ thu thập của bạn có thể phân biệt ưu đãi được yêu cầu với trạng thái mặc định, tải trước hoặc sai lệch khu vực.

Sẵn sàng thu thập ưu đãi từ Storefront headless?

Render một storefront đã được chấp thuận trong Agent Browser và so sánh ưu đãi đã chọn với phản hồi của nó.

Đăng ký hôm nay và nhận $5 in free credit — không cần thẻ tín dụng.

Nhận $5 tín dụng của bạn →

Câu hỏi thường gặp

Tất cả các cửa hàng headless commerce có đều cần Playwright không?

Một API hoặc feed danh mục được ghi chép đầy đủ có thể là đủ khi nó cung cấp các trường bắt buộc. Sử dụng Playwright để xác minh hành vi phụ thuộc vào storefront đã render hoặc lựa chọn của người dùng.

HTML ban đầu có thể chứa các mức giá sử dụng được không?

Một số storefront bao gồm giá trong phản hồi được render bởi máy chủ. Xác nhận rằng các giá trị áp dụng cho biến thể và thị trường đã chọn trước khi sử dụng chúng.

Khi nào proxy hữu ích cho việc scraping headless commerce?

Sử dụng một tuyến đường theo vị trí khi việc thu thập theo thị trường được ủy quyền phụ thuộc vào điểm thoát mạng. Kiểm tra khu vực và đơn vị tiền tệ hiển thị vì bộ chọn thị trường và thiết lập phiên có thể thay đổi kết quả.

Trình thu thập nên xử lý từ chối truy cập và giới hạn lưu lượng như thế nào?

Ghi lại các trang bị từ chối là không khả dụng và sử dụng một phạm vi hoặc feed được chủ sở hữu chấp thuận. Xem lại các điều khoản và quyền áp dụng với cố vấn pháp lý khi cần và giữ lưu lượng trong giới hạn đã thỏa thuận.

Điều gì xảy ra khi cửa hàng thay đổi đánh dấu (markup) sản phẩm?

Kiểm tra bộ chuyển đổi với một mẫu mới và xác nhận cả sự tương quan phản hồi và nhận dạng ưu đãi đã render. Một dấu hiệu biến thể đã chọn hoặc ưu đãi đã cam kết bền vững giúp khoanh vùng thay đổi.

Quy trình làm việc này có thể chạy mà không cần tác nhân AI không?

Playwright có thể điều hướng, chọn tùy chọn và so sánh phản hồi với trang đã render trực tiếp. Giữ mức độ song song của trình duyệt bị giới hạn bởi hạn mức nguồn đã được chấp thuận và năng lực sẵn có.

Tài liệu tham khảo