Эта страница переведена с помощью Cloud Translation API.

Управление версиями v1 в пакетных фидах

В пакетных фидах версия объекта определяется с помощью поля 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 получен следующий добавочный вызов для совершенно нового ресторана. Вот запрос HTTP POST для этого объекта с идентификатором «http://www.provider.com/somerestaurant», предполагая, что канал данных использует схему инвентаризации 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 . Сущность с идентификатором «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 получен следующий добавочный вызов для совершенно нового ресторана. Вот запрос HTTP POST для этого объекта с идентификатором «http://www.provider.com/somerestaurant», предполагая, что канал использует схему инвентаризации 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 . Таким образом, объект с идентификатором «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 извлекает следующий файл в 11 утра 28 декабря 2018 г. для совершенно нового ресторана:

{
  "@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 дня.

Однако в 13:00 в системе партнера появляется обновление телефонного номера ресторана, что приводит к следующему дополнительному звонку, который Google получает в 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"
      ...
    }
  ]
}

На следующий день (29 декабря 2018 г.) в 23:00 канал снова загрузится. В ресторане все еще используется та же версия (28 декабря в 13:00), поэтому этот объект удаляется и сохраняется текущая версия. Однако объекты «Меню» и «Сервис» обновлены до новой версии.

Временные метки карты сайта

last-modified заголовок ответа в карте сайта не влияет на версию объекта. Это влияет на то, когда Google получает канал.

Лучшие практики

Обновляйте заголовок ответа только тогда, когда все файлы обновлены и готовы к загрузке.
Явно используйте update_time и delete_time в инкрементальном режиме.
Установите update_time , delete_time и dateModified на момент изменения данных на вашей стороне.