批次擷取

透過資料動態饋給，你可以利用「Google 訂餐」供應餐廳、服務和菜單。

本文說明如何託管您的沙箱和正式版廣告空間，並使用批次擷取功能更新「Google 訂餐」中的商品目錄。

資料動態饋給環境

整合作業有三個資料動態饋給環境：

動態饋給環境 說明 批次擷取
沙箱 動態饋給開發的測試環境。 需要
製片 要啟動商品目錄的實際工作環境。 需要

代管資料動態饋給

為了讓「訂單與 Google 產品」以批次擷取的方式處理您的沙箱和正式版資料動態饋給，您必須使用 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。

選擇代管解決方案

下表列出代管資料動態饋給的選項，以及這些主機如何與「Google 訂餐」搭配使用：

Amazon S3 Google Cloud Storage 透過 Sitemap 使用 HTTPS
憑證與存取權

向 Google 提供下列資訊：

  • 存取金鑰 ID
  • 私密存取金鑰
  • 正式版和沙箱 S3 目錄的路徑與 marker.txt 檔案的路徑。路徑的開頭必須為 s3://。

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

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

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

將實際工作環境和沙箱值區目錄和 marker.txt 檔案的路徑提供給 Google。路徑的開頭必須為 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 檔案內的檔案路徑數量必須小於 100,000。

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

代管動態饋給後，您必須在合作夥伴入口網站上將動態消息連結至專案。初始動態饋給的初始設定是在「新手上路工作」頁面上完成。我們日後隨時可以透過設定 > 動態饋給頁面，針對具備管理員角色的入口網站使用者更新正式版和沙箱動態饋給設定。沙箱環境會用於開發和測試目的，而正式版動態饋給會向使用者顯示。

如果您使用 Amazon S3 代管資料動態饋給

  1. 在合作夥伴入口網站中前往 [設定] > [動態消息]。

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

    • 動態饋給放送方式：設為 Amazon S3。
    • Marker File：提供 marker.txt 檔案的網址。
    • 資料檔案：提供包含資料動態饋給的 S3 值區網址。
    • 存取權 ID：輸入取得 S3 資源讀取權限的身分與存取權管理存取 ID。
    • 存取金鑰：輸入具有 S3 資源讀取權限的身分與存取權管理密鑰存取金鑰。
  3. 按一下「提交」。
  4. 請在一到兩小時後檢查批次擷取是否擷取您的動態饋給檔案。

如果您使用 Google Cloud Storage 託管資料動態饋給

  1. 在合作夥伴入口網站中前往 [設定] > [動態消息]。

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

    • 「Feed Delivery 方法」：設為「Google Cloud Storage」。
    • Marker File：提供 marker.txt 檔案的網址。
    • 資料檔案：提供包含資料動態饋給的 GCS 值區網址。
  3. 按一下「提交」。
  4. 系統會建立服務帳戶來存取 GCS 值區。完成新手上路工作後，您可以在設定 > 動態消息中找到帳戶名稱。這個服務帳戶必須具備「Storage Legacy Object Reader」角色。您可以將這個角色授予 Google Cloud Console 中「身分與存取權管理」頁面的服務帳戶。
  5. 請在一到兩小時後檢查批次擷取是否擷取您的動態饋給檔案。

如果您使用 HTTPS 代管資料動態饋給

  1. 在合作夥伴入口網站中前往 [設定] > [動態消息]。

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

    • 動態饋給放送方式：設為「HTTPS」。
    • Sitemap 檔案：提供 sitemap.xml 檔案的網址。
    • 使用者名稱：輸入用來存取 HTTPS 伺服器的使用者名稱憑證。
    • 密碼：輸入密碼以存取 HTTPS 伺服器。
  3. 按一下「提交」。
  4. 請在一到兩小時後檢查批次擷取是否擷取您的動態饋給檔案。

路徑範例

下表列出所有代管選項的範例路徑：

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 檔案的 last-modified 物件中繼資料欄位 (適用於 GCP 和 S3) 或 sitemap.xml 檔案的 last-modified 回應標頭。Google 會運用這些值來判定資料動態饋給的即時程度。

正在擷取批次動態饋給，

  • 如果現有 OwG 廣告空間中沒有現有實體，而且沒有錯誤，系統會插入這類實體。
  • 實體中已有實體，但未在擷取時發生任何錯誤，且 dateModified 比當前項目更晚，或者在沒有 dateModified 的情況下，動態饋給擷取開始時間晚於更新時目前的項目，否則就會標示為過時。
  • 如果原先的動態饋給不再包含批次處理作業中的動態饋給，只要動態饋給中沒有檔案層級錯誤，系統就會刪除這些實體。

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