Control de versiones v1 en feeds por lotes

En tus feeds por lotes, la versión de una entidad se determina mediante el campo dateModified en el sobre del feed:

{
  "@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 */
  ]
}

Todas las entidades enumeradas en el campo dataFeedElement tendrán la misma marca de tiempo, tal como se indica en el sobre.

Por ejemplo, puedes tener el siguiente feed con dos entidades:

{
  "@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"
      ...
    }
  ]
}

Tanto las entidades de menú como las del restaurante, una vez recibidas y procesadas, recibirán la versión de forma individual como “2018-12-28T06:30:00:123-07:00”.

Control de versiones con actualizaciones incrementales

Cuando envías una entidad mediante actualizaciones de inventario, la versión se establece a través del campo update_time (en el caso de una llamada de adición o actualización) o el campo delete_time (en el caso de una llamada de eliminación). Dado que estos campos son opcionales, la marca de tiempo predeterminada se establece en el momento en que Google recibió la llamada.

Ejemplo 1: update_time establece explícitamente

Supongamos que se recibe la siguiente llamada incremental el 2018-12-28T06:30:10:123-07:00 para un restaurante completamente nuevo. A continuación, se muestra la solicitud HTTP POST para esa entidad con el ID "http://www.provider.com/somerestaurant", suponiendo que el feed de datos usa el esquema de inventario v1:

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

A continuación, el cuerpo de la carga útil de JSON contiene el campo update_time. La entidad con el ID "http://www.provider.com/somerestaurant" da como resultado la versión de esta entidad como 6:30:00 y no cuando se recibió (diez segundos después, a las 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"
}

Ejemplo 2: update_time establece de forma implícita

Supongamos que se recibe la siguiente llamada incremental el 2018-12-28T06:30:10:123-07:00 para un restaurante completamente nuevo. A continuación, se muestra la solicitud HTTP POST para esa entidad con el ID "http://www.provider.com/somerestaurant", suponiendo que el feed usa el esquema de inventario v1:

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

A continuación, el cuerpo de la carga útil de JSON no contiene el campo update_time. Por lo tanto, la entidad con el ID "http://www.provider.com/somerestaurant" da como resultado la versión de esta entidad como 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"
  }
}

Control de versiones entre incremental y por lotes

Una entidad enviada a Google se procesa y entrega solo si tiene la versión más reciente. Ten en cuenta que las entidades enviadas a través de lotes, por lo general, tardan unos días en procesarse, mientras que las entidades enviadas a través de la API incremental se procesan de inmediato.

Prácticas recomendadas

  • Configura los campos update_time y dateModified en forma incremental y por lotes, respectivamente, según cuándo se modificó la entidad en tus sistemas.
  • Si un feed por lotes (archivo) enumera más de una entidad de nivel superior (por ejemplo, si vinculas tus restaurantes con servicios y menús), actualiza la marca de tiempo a medida que se actualizan los datos de una entidad.
  • En las llamadas incrementales, te recomendamos que configures de forma explícita el campo update_time.
  • Es fundamental que, una vez que se realice una llamada incremental, también se actualice la marca de tiempo del feed correspondiente (dateModified) antes de que Google la recupere de nuevo.

Ejemplo

Google recupera el siguiente archivo a las 11 a.m. el 28/12/2018 para un restaurante completamente nuevo:

{
  "@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"
      ...
    }
  ]
}

Estas entidades se procesan de forma correcta y tienen la versión “2018-12-28T06:30:00-07:00”. Debido a que los feeds por lotes tardan en procesarse, se suelen publicar 2 días después.

Sin embargo, a la 1 p.m., el sistema del socio tiene una actualización del número de teléfono del restaurante, lo que genera la siguiente llamada incremental, que Google recibe a las 13:05 (5 segundos después):

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"
}

La update_time se proporciona de forma explícita y es mayor (más reciente) que la versión anterior (6:30 a.m. del mismo día), por lo que la entidad del restaurante ahora tiene la versión "2018-12-28T13:00:00-07:00". Sin embargo, las entidades de menú y servicio todavía tienen la versión "2018-12-28T06:30:00-07:00".

Hubo una llamada incremental, por lo que el feed por lotes se actualiza con la nueva marca de tiempo correspondiente. Además, los cambios correspondientes se aplican a las entidades relevantes (la entidad del restaurante tiene su número de teléfono actualizado).

{
  "@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"
      ...
    }
  ]
}

Al día siguiente (29 de diciembre de 2018) a las 11 p.m., se vuelve a recuperar el feed. El restaurante todavía tiene la misma versión (1 p.m. del 28 de diciembre), por lo que esta entidad se descarta y se conserva la versión actual. Sin embargo, las entidades de menú y servicio se actualizan con una versión nueva.

Marcas de tiempo del mapa del sitio

El encabezado de respuesta last-modified en el mapa del sitio no afecta la versión de una entidad. Afecta cuándo Google recupera el feed.

Prácticas recomendadas

  • Actualiza el encabezado de respuesta solo cuando todos los archivos estén actualizados y listos para recuperarse.
  • Usa update_time y delete_time de forma explícita en el incremento.
  • Configura update_time, delete_time y dateModified en el momento en el que cambien los datos.