本頁面由 Cloud Translation API 翻譯而成。

批次動態饋給中的 v1 版本管理功能

在批次動態饋給中，實體的版本取決於動態饋給信封中的 dateModified 欄位：

{
  "@context": "http://schema.googleapis.com",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "@type": "DataFeed",
  "dataFeedElement": [
    /* All the items that are part of this feed go here */
  ]
}

「dataFeedElement」欄位中列出的所有實體都會有相同的時間戳記。與信封中所列的問題相同

例如，您可以使用包含兩個實體的下列動態饋給：

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/somerestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/somerestaurant/menu/1"
      ...
    }
  ]
}

我們收到並處理完菜單和餐廳資料後，分別定義為「2018-12-28T06:30:00:123-07:00」

包含漸進式更新的版本管理

使用商品目錄更新傳送實體時，版本會經過以下設定： update_time 欄位 (如果是新增/更新呼叫) 或 delete_time 欄位 (如果是刪除呼叫的話)。由於這些是選填欄位，因此預設時間戳記設為 Google 接到來電的時間。

範例 1：已明確設定 update_time

假設在 2018-12-28T06:30:10:123-07:00 接到下列漸進式呼叫是一間全新的餐廳以下是該實體的 HTTP POST 要求且 ID 為「http://www.provider.com/somerestaurant」 (假設資料動態饋給使用第 1 版商品目錄架構：

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

下方的 JSON 酬載主體包含 update_time 欄位。含有 ID：「http://www.provider.com/somerestaurant」會導致這個實體版本為 6:30:00，而不是實際接收的時間 (10 秒後在 6:30:10):

{
// This envelope is to be used for incremental.
  "entity": {
    // Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING&quot;
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

範例 2：以隱含方式設定 update_time

假設在 2018-12-28T06:30:10:123-07:00 接到下列漸進式呼叫是一間全新的餐廳以下是該實體的 HTTP POST 要求且 ID 為「http://www.provider.com/somerestaurant」廣告空間架構：

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

下方的 JSON 酬載主體不含 update_time 欄位。編號為「http://www.provider.com/somerestaurant」的實體因此會產生該實體的版本為 6:30:10：

{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]";,
    "vertical": "FOODORDERING"
  }
}

批次與漸進式版本管理

傳送給 Google 的實體只有在其最新版本的情況下才會處理及放送版本。請注意，以批次傳送的實體通常需要幾天的時間才會收到而透過漸進式 API 傳送的實體則會處理立即生效

最佳做法

以增量和批次的方式設定 update_time 和 dateModified 欄位產生這些更新。
如果批次動態饋給 (檔案) 列出多個頂層實體 (例如然後將餐廳與服務和菜單配對，然後將時間戳記更新為實體的資料都會更新。
在增量呼叫中，我們強烈建議您明確設定「update_time」欄位。
務必等到發出漸進式呼叫後，相應的動態饋給時間戳記 (dateModified) 也在 Google 再次擷取前更新。

範例

Google 將於 2018 年 12 月 28 日早上 11 點擷取下列檔案，以取得全新餐廳：

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

系統已成功處理這些實體，並使用以下版本編號： "2018-12-28T06:30:00-07:00".由於批次動態饋給的處理需要一些時間通常在 2 天後就會獲得放送

不過在下午 1 點，合作夥伴的系統更新了餐廳的手機號碼，因此會產生下列漸進式呼叫，而 Google 會 13:05 (5 秒後)：

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  },
  "update_time":"2018-12-28T13:00:00-07:00"
}

update_time 已明確提供，且會大於 (較新) 舊版 (當天早上 6:30)，因此餐廳實體現在已經版本為「2018-12-28T13:00:00-07:00」。不過，菜單和服務實體仍是「2018-12-28T06:30:00-07:00」的版本。

出現漸進式呼叫，因此批次動態饋給會以新的對應的時間戳記相應的變更也會套用至相關實體 (餐廳實體已更新)。

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T13:00:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

隔天 (2018 年 12 月 29 日) 中午 11 點再次擷取動態饋給。餐廳仍會有相同的版本 (12 月 28 日下午 1 點)，因此這個實體會遭到捨棄會保留目前版本不過，「菜單」和「服務」實體會透過新版本完成更新

Sitemap 時間戳記

Sitemap 中的 last-modified 回應標頭「不會」影響專屬版本這會影響 Google 擷取動態饋給的「時間」。

最佳做法

「僅」在所有檔案都已完成更新且準備就緒時，才更新回應標頭以便擷取。
以漸進方式明確使用 update_time 和 delete_time。
將 update_time、delete_time 和 dateModified 設為資料變更的時間。