批次擷取

您可以利用資料動態饋給功能，讓餐廳、服務和菜單提供完整的訂單服務。

本文說明如何代管沙箱和正式版商品目錄，以及如何使用批次擷取功能更新訂單端對端的商品目錄。

資料動態饋給環境

以下是可用於整合開發的資料動態饋給環境：

動態饋給環境 說明 批次擷取
沙箱 動態饋給開發的測試環境。 必要
實際工作環境 您要推出的廣告空間實際執行環境。 必要

代管資料動態饋給

為了進行批次擷取以批次擷取「沙箱」和「實際工作環境」資料動態饋給，您必須透過 Sitemap 託管資料動態饋給檔案，並存放在 Google Cloud Storage、Amazon S3 或 HTTPS 中。

建議您分別代管沙箱和實際執行環境的資料動態饋給。透過這種做法，您可以先在沙箱動態饋給環境中進行開發和測試，再將變更部署至實際工作環境。

舉例來說，如果您使用 Google Cloud Storage 做為代管選項，會看到下列路徑：

  • 沙箱動態饋給： gs://foorestaurant-google-feed-sandbox/
  • 正式版動態饋給： gs://foorestaurant-google-feed-prod/

如要代管廣告空間，請按照下列步驟操作：

  1. 產生資料動態饋給檔案。
  2. 選擇託管解決方案。
  3. 代管資料動態饋給。
  4. 務必定期更新資料動態饋給檔案。請務必每天更新 實際工作環境資料動態饋給。

如要進一步瞭解如何建立商品目錄動態饋給，請參閱 Restaurant、Service 和 Menu 實體的說明文件，以及「建立資料動態饋給」部分。

資料動態饋給檔案規範

每個檔案可以包含多個實體，大小不得超過 200 MB。頂層實體 Restaurant、Service 和 Menu 及其子實體，全都不得超過 4 MB。

選擇託管解決方案

下表列出代管資料動態饋給的選項，以及這些主機如何與端對端排序功能搭配運作：

Amazon S3 Google Cloud Storage 含有 Sitemap 的 HTTPS
憑證和存取權

將以下資訊提供給 Google：

  • 存取金鑰 ID
  • 私密存取金鑰
  • 實際執行環境與沙箱 S3 目錄和 marker.txt 檔案的路徑。路徑的開頭必須是 s3://。

S3 值區必須包含下列資訊：

  • 商品目錄的動態饋給檔案。
  • marker.txt：包含用於擷取的時間戳記。

marker.txt 檔案範例：2018-12-03T08:30:42.694Z

向 Google 提供實際工作環境、沙箱值區目錄和 marker.txt 檔案的路徑。路徑的開頭必須是 gs://。

將 Google 顧問提供的服務帳戶新增為 Google Cloud Storage 值區的讀取者。

如要進一步瞭解如何控管 Google Cloud Storage (GCS) 的存取權，請參閱 Google Cloud Platform Console：設定值區權限。

GCS 值區必須包含下列資訊：

  • 商品目錄的動態饋給檔案。
  • marker.txt：包含用於擷取的時間戳記。

marker.txt 檔案範例：2018-12-03T08:30:42.694Z

將以下資訊提供給 Google：

  • 基本驗證的憑證。
  • 實際執行環境與沙箱 Sitemap 路徑的路徑。路徑的開頭必須是 https://。
  • 通訊協定：您必須透過 HTTPS (而非 HTTP) 提供動態饋給檔案。
  • 安全性：Google 強烈建議您透過基本驗證功能保護代管的動態饋給檔案。
Google 如何得知需要擷取哪些檔案 值區中所有檔案的目錄清單。 值區中所有檔案的目錄清單。 Sitemap 中所列檔案的個別網址。
Google 如何確認檔案已可擷取 資料動態饋給產生完成後，請使用最新的時間戳記更新 marker.txt 檔案。 資料動態饋給產生完成後，請使用最新的時間戳記更新 marker.txt 檔案。 資料動態饋給產生完成後，請更新 sitemap.xml 的回應標頭 last-modified 中的最新時間戳記。
檔案限制

檔案數量上限：100,000。

Amazon S3 值區中的檔案總數必須少於 100,000 個。

檔案數量上限：100,000。

Google Cloud Storage 值區中的檔案總數必須少於 100,000 個。

檔案數量上限：100,000。

Sitemap XML 檔案中的檔案路徑數量不得超過 100,000 個。

連結資料動態饋給以進行批次擷取

代管動態饋給後，開發人員必須到 Actions Center 中將動態饋給連結至您的專案。正式版動態饋給的初始設定可以在「新手上路工作」頁面中完成。之後，您隨時可以透過「設定」>「動態饋給」頁面，更新正式版和沙箱動態饋給的設定，並由具備管理員角色的任何入口網站使用者更新。沙箱環境會用於開發及測試，使用者則會看到正式版動態饋給。

如果是透過 Amazon S3 代管資料動態饋給

  1. 在 Actions Center 中，依序前往「設定」>「動態饋給」。

  2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

    • Feed Delivery method：設定為「Amazon S3」。
    • 標記檔案：提供 marker.txt 檔案的網址。
    • 資料檔案：提供包含資料動態饋給的 S3 值區網址。
    • Access ID：輸入具備從 S3 資源讀取權限的 IAM 存取金鑰 ID。
    • 存取金鑰：輸入具備讀取 S3 資源讀取權限的 IAM 密鑰。
  3. 點選「提交」。
  4. 1 到 2 小時後，請確認批次擷取作業是否擷取了您的動態饋給檔案。

如果您是透過 Google Cloud Storage 代管資料動態饋給

  1. 在 Actions Center 中，依序前往「設定」>「動態饋給」。

  2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

    • 動態饋給傳遞方式：設為「Google Cloud Storage」。
    • 標記檔案：提供 marker.txt 檔案的網址。
    • 資料檔案：提供包含資料動態饋給的 GCS 值區網址。
  3. 點選「提交」。
  4. 系統會建立服務帳戶來存取您的 GCS 值區。完成新手上路工作後，您可以前往「設定」>「動態饋給」找到帳戶名稱。這個服務帳戶需要「Storage 舊版物件讀取者」角色。您可以在 Google Cloud 控制台的「身分與存取權管理」頁面中，將這個角色授予服務帳戶。
  5. 1 到 2 小時後，請確認批次擷取作業是否擷取了您的動態饋給檔案。

如果您透過 HTTPS 代管資料動態饋給

  1. 在 Actions Center 中，依序前往「設定」>「動態饋給」。

  2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

    • 動態饋給放送方式：設為「HTTPS」。
    • Sitemap 檔案：提供 sitemap.xml 檔案的網址。
    • 使用者名稱：輸入使用者名稱憑證來存取 HTTPS 伺服器。
    • 密碼：輸入密碼來存取 HTTPS 伺服器。
  3. 點選「提交」。
  4. 1 到 2 小時後，請確認批次擷取作業是否擷取了您的動態饋給檔案。

路徑範例

下表列出各個代管選項的路徑範例：

Amazon S3 Google Cloud Storage 含有 Sitemap 的 HTTPS
路徑 s3://foorestaurant-google-feed-sandbox/ gs://foorestaurant-google-feed-sandbox/ https://sandbox-foorestaurant.com/sitemap.xml
標記檔案 s3://foorestaurant-google-feed-sandbox/marker.txt gs://foorestaurant-google-feed-sandbox/marker.txt 不適用

HTTPS 託管的 Sitemap

定義 Sitemap 時，請遵守下列規範：

  • Sitemap 中的連結必須指向檔案本身。
  • 如果您的 Sitemap 參照的是雲端服務供應商而非您自己的網域名稱，請確認網址開頭 (例如 https://www.yourcloudprovider.com/your_id) 是固定且專屬於批次工作的網址。
  • 請小心不要上傳部分 Sitemap (例如上傳部分資料時)。如果這麼做，Google 只會擷取 Sitemap 中的檔案，導致庫存量下降，並可能導致動態饋給擷取功能遭到封鎖。
  • 請確認 Sitemap 中參照的檔案路徑並未變更。舉例來說，現在不要讓 Sitemap 參照 https://www.yourcloudprovider.com/your_id/10000.json，但明天卻參照 https://www.yourcloudprovider.com/your_id/20000.json。
範例 Sitemap

以下是提供資料動態饋給檔案的範例 sitemap.xml 檔案：

範例 1：按商家分組的實體 (建議)。

XML

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_1.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_2.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_3.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

範例 2：按類型分組的實體。

XML

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/menu.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/service.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

更新資料動態饋給

連結資料動態饋給後，Google 每小時會檢查一次更新，但只有在修改 marker.txt 或 sitemap.xml 檔案時，系統才會擷取所有資料動態饋給。我們希望您每天更新資料動態饋給一次，以免商品目錄過時。

如要指定資料動態饋給已修改並準備好進行批次擷取，請更新 marker.txt 檔案 (適用於 GCP 和 S3) 的 last-modified 物件中繼資料欄位，或是 sitemap.xml 檔案的 last-modified 回應標頭。Google 會使用這些值來判斷資料動態饋給的即時程度。

當系統擷取批次動態饋給時

  • 如果新實體不存在於目前的「訂單至結束」商品目錄，且沒有任何錯誤，系統就會插入該實體。
  • 如果商品目錄中已有實體在擷取時沒有任何錯誤，且 dateModified 晚於其目前項目，或是沒有 dateModified，動態饋給擷取開始時間早於要更新的現有項目，否則會標示為過時。
  • 如果動態饋給沒有檔案層級的錯誤，那麼如果實體在舊有的動態饋給中不再包含在處理中的批次動態饋給中，該實體就會遭到刪除。

只有在所有資料動態饋給檔案都已產生並更新之後，才能更新時間戳記或 last-modified 回應標頭。限制更新資料動態饋給的批次工作每天僅執行一次。或者，每次批次工作之間間隔至少 3 小時。如未採取這些步驟，Google 可能會擷取過時的檔案。

上一頁
測試資料動態饋給