Entity versioning

Each entity that is sent to Google, whether through feeds or real-time updates, has a version attached to it. This version comes in the form of a timestamp. In feeds, the timestamp can be provided for each entity using the dateModified attribute. If the attribute is not included, the timestamp will set to the start time of feed ingestion. In real-time updates batchPush and batchDelete, respectively, the fields generation_timestamp and delete_time are used to set the timestamp. If the field is not included, the timestamp will be set to the time when the request was received. See the expected format of time values in the relational inventory schema.

Google only processes entities (for example: a restaurant, a menu, or a service) with a timestamp equal to or newer than the last accepted timestamp. Otherwise, the entity is not ingested.

If an entity timestamp is not updated for 14 days consecutively, it is garbage collected and removed from serving.

Suppose a feed is generated on June 16th at 01:10 UTC with the following example entity included.

  "@type": "Restaurant",
  "@id": "restaurant12345",
  "dateModified": "2022-06-16T01:10:00.000Z",

The feed is not yet ingested by Google. Later that day, we get the following entity with the same id and with the timestamp set to 2022-06-16T01:20:00.000Z from a real-time update batchPush request.

  "records": [
      "data_record": "{\"@type\": \"Restaurant\",\"@id\": \"restaurant12345\" ...",
      "generation_timestamp": "2022-06-16T01:20:00.000Z"

The timestamp for the restaurant entity is now 2022-06-16T01:20:00.000Z.

Ingestion of the feed starts on June 16th at 02:00 UTC for example. In this situation, the entity received in the feed with timestamp 2022-06-16T01:10:00.000Z is considered stale and not ingested as a result. Google therefore continues to serve the entity with version 2022-06-16T01:20:00.000Z from the real-time update request.