批次動態饋給中的 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 收到下列漸進式呼叫，適用於新的餐廳。這裡的 ID 為「quot;http://www.provider.com/somerestaurant&quot」且該實體的 HTTP POST 要求，假設資料動態饋給使用 v1 庫存結構定義：

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&quot」的實體會產生這個實體的版本為 6:30:00，而不是在收到後版本 (十秒後 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"
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

範例 2：update_time 默示設定

假設在 2018-12-28T06:30:10:123-07:00 收到下列漸進式呼叫，適用於新的餐廳。這裡的 ID 為「quot;http://www.provider.com/somerestaurant&quot」且該實體的 HTTP POST 要求，假設動態饋給使用 v1 庫存結構定義：

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&quot」的實體，因此這個實體的版本編號為 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 點)，因此這個實體會遭到捨棄，目前版本也會保留下來。不過，Menu 和 Service 實體會以新版本更新。

Sitemap 時間戳記

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

最佳做法

  • 請只在所有檔案都處於最新狀態且可供擷取時更新回應標頭。
  • 明確使用 update_time 和 delete_time。
  • 將 update_time、delete_time 和 dateModified 設為資料結尾的變動。