在批次動態饋給中,實體版本是由動態饋給信封的 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 為「http://www.provider.com/somerestaurant」) 的 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」的實體將使這個實體的版本為 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 為「http://www.provider.com/somerestaurant」) 的 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」的實體將使這個實體的版本為 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 點,合作夥伴的系統更新了餐廳的電話號碼,因此在 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 點),因此系統會捨棄這個實體並保留目前的版本。但菜單和 Service 實體會更新為新版本。
Sitemap 時間戳記
Sitemap 中的 last-modified
回應標頭「不會」影響實體版本。這會影響 Google 擷取動態饋給的時間。
最佳做法
- 請只在所有檔案最新狀態且已經準備好擷取時,才更新回應標頭。
- 明確使用
update_time
和delete_time
增量。 - 請將
update_time
、delete_time
和dateModified
設為資料自動變更的時間。