Se usó la API de Cloud Translation para traducir esta página.

Control de versiones v1 en feeds por lotes

En tus feeds por lotes, la versión de una entidad se determina a través del 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, como se indica en el sobre.

Por ejemplo, podría 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"
      ...
    }
  ]
}

Una vez recibidas y procesadas, tanto el menú como las entidades de los restaurantes tendrían versiones individuales 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 cuando Google recibió la llamada.

Ejemplo 1: update_time configurado explícitamente

Supongamos que la siguiente llamada incremental se recibe a las 2018-12-28T06:30:10:123-07:00 de 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 JSON contiene el campo update_time. La entidad con el ID "http://www.provider.com/somerestaurant" da como resultado que esta entidad se controle como 6:30:00 y no cuando se la 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 configurado implícitamente

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 JSON no contiene el campo update_time. Por lo tanto, la entidad con ID "http://www.provider.com/somerestaurant" hace que esta entidad se controle según la versión 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 por lotes y incremental

Una entidad que se envía 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 suelen tardar 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 incrementos 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, 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, la marca de tiempo del feed correspondiente (dateModified) también se actualice antes de que Google la recupere.

Ejemplo

Google recupera el siguiente archivo a las 11 a.m. el 28 de diciembre de 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 se controlan sus versiones como “2018-12-28T06:30:00-07:00". Debido a que los feeds por lotes tardan en procesarse, estos 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, que da como resultado 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"
}

El update_time se proporciona de manera 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, el menú y las entidades de servicio aún tienen versiones como "2018-12-28T06:30:00-07:00".

Se realizó 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 (se actualiza el número de teléfono de la entidad del restaurante).

{
  "@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:00 p.m., el feed se recupera nuevamente. El restaurante aún tiene la misma versión (1 p.m. del 28 de diciembre), por lo que se descarta esta entidad y se conserva la versión actual. Sin embargo, las entidades del menú y del 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 forma incremental.
Configura update_time, delete_time y dateModified para que cambien los datos en tu extremo.