無論是透過動態饋給或即時更新，傳送給 Google 的實體
已附加版本。這個版本的格式為時間戳記。於
動態饋給，則可使用 dateModified 為每個實體提供時間戳記
屬性。如果屬性不包含動態饋給實體，則版本為
設為動態饋給擷取的開始時間。即時更新 batchPush 和
batchDelete，generation_timestamp 和 delete_time 欄位
用於設定版本如果未包含這個欄位，版本會設為
接收請求的時間。查看 time 的預期格式
價值
建立關係
Google 只會處理實體 (例如餐廳、菜單或服務) 版本等於或高於上次接受的版本。否則， 不會擷取實體，並記錄 Stro Entity 錯誤。如果 實體已更新為新版本，上次修改的時間戳記會更新為 維持目前更新的時間
範例
假設動態饋給是在世界標準時間 6 月 16 日 1 點 10 分產生，以下範例為 實體。
{
"@type": "Restaurant",
"@id": "restaurant12345",
"dateModified": "2022-06-16T01:10:00.000Z",
...
}
Google 尚未擷取動態饋給。當天稍晚的
2022-06-16T01:22:00.000Z，Google 收到
即時更新 batchPush 要求，其中包含下列內容
實體。
{
"records": [
{
"data_record": "{\"@type\": \"Restaurant\",\"@id\": \"restaurant12345\" ...",
"generation_timestamp": "2022-06-16T01:20:00.000Z"
}
]
}
餐廳實體 ID「restaurant12345」的版本現已完成
「2022-06-16T01:20:00.000Z」和「實體的上次修改時間戳記」已設定
至 2022-06-16T01:22:00.000Z。總結來說，上次修改時間是
表示該實體已更新於 Google 商品目錄資料中，版本則是
即時更新要求的 generation_timestamp 值，或是
來自動態饋給的 dateModified 值。
這個動態饋給會在 6 月 16 日 02:00 (世界標準時間) 開始擷取。在此情況下
動態饋給收到的實體 2022-06-16T01:10:00.000Z 為
因此不會擷取因此，Google 持續為
版本為 2022-06-16T01:20:00.000Z 的實體，來自
「即時更新」要求。
最佳做法：
- 將時間戳記導入每個實體的動態饋給中。
- 將即時更新變更套用至下一個動態饋給，並 設定 動態饋給實體中的 dateModified 時間戳記，到目前時間 已建立這個動態饋給。