Obsługa wersji v1 w plikach danych wsadowych

W plikach danych wsadowych wersja elementu jest określana w polu dateModified w kopercie pliku danych:

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

Wszystkie elementy wymienione w polu dataFeedElement będą miały tę samą sygnaturę czasową co podane w danych koperty.

Załóżmy, że masz taki plik danych z 2 elementami:

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

Zarówno pozycje menu, jak i restauracje, po otrzymaniu i przetworzeniu, byłyby indywidualnie traktowane jako „"2018-12-28T06:30:00:123-07:00"”.

Obsługa wersji z aktualizacjami przyrostowymi

Gdy wysyłasz element za pomocą aktualizacji zasobów reklamowych, wersję ustawia się w polu update_time (w przypadku wywołania dodawania lub aktualizacji) lub delete_time (w przypadku wywołania usunięcia). Pola te są opcjonalne, dlatego domyślną sygnaturą czasową jest moment, w którym odebrano połączenie.

Przykład 1. Ustawianie parametru update_time

Załóżmy, że poniższe przyrostowe połączenie zostało odebrane w 2018-12-28T06:30:10:123-07:00 dla zupełnie nowej restauracji. Oto żądanie HTTP POST dla tego elementu o identyfikatorze "http://www.provider.com/somefood" przy założeniu, że plik danych używa schematu zasobów reklamowych w wersji 1:

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

W treści treści ładunku JSON znajduje się pole update_time. Element z identyfikatorem &httpt;http://www.provider.com/jakaś restauracja" otrzymuje wersję 6:30:00, a nie dzień jej odbioru (10 sekund później, o 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"
}

Przykład 2. Domyślna wartość atrybutu update_time

Załóżmy, że poniższe przyrostowe połączenie zostało odebrane w 2018-12-28T06:30:10:123-07:00 dla zupełnie nowej restauracji. Oto żądanie HTTP POST dla tego elementu o identyfikatorze "http://www.provider.com/someRestauracja" przy założeniu, że plik danych korzysta ze schematu zasobów reklamowych v1:

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

Treść ładunku JSON nie zawiera pola update_time. Elementem o identyfikatorze &http://www.provider.com/jakaś restauracja" jest więc wersja o 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"
  }
}

Obsługa wersji wsadowej i przyrostowej

Element wysyłany do Google jest przetwarzany i wyświetlany tylko wtedy, gdy ma najnowszą wersję. Przetwarzanie jednostek przesłanych za pomocą operacji zbiorczych zajmuje zwykle kilka dni, podczas gdy encje wysyłane za pomocą przyrostowego interfejsu API są przetwarzane natychmiast.

Sprawdzonych metod

  • Skonfiguruj pola update_time i dateModified przyrostowo i wsadowo odpowiednio do zmian encji w swoich systemach.
  • Jeśli wsadowy plik (plik) zawiera więcej niż 1 element najwyższego poziomu (np. sparujesz restauracje z usługami i menu), zaktualizuj sygnaturę czasową aktualizacji danych elementu.
  • Zdecydowanie zalecamy umieszczenie w poszczególnych wywołaniach pola update_time.
  • Po wykonaniu przyrostowego wywołania odpowiednia sygnatura czasowa pliku (dateModified) jest też aktualizowana przed ponownym pobraniem pliku przez Google.

Przykład

21.12.2018 o godzinie 18:00 Google pobierze taki plik:

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

Te elementy są przetwarzane i mają wersję "2018-12-28T06:30:00-07:00". Przetwarzanie plików danych zajmuje dużo czasu, dlatego zwykle są udostępniane 2 dni później.

Jednak o 13:00 system aktualizuje numer telefonu restauracji, co powoduje, że telefon otrzymuje przyrostowe połączenie, które Google otrzymuje o 13:05 (5 sekund później):

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

Wartość w polu update_time jest wyraźnie określona i większa niż w poprzedniej wersji (6:30 tego samego dnia), więc wersja restauracji ma teraz postać „"2018-12-28T13:00:00-07:00"”. Jednak elementy menu i usługi są nadal przechowywane w formacie „"2018-12-28T06:30:00-07:00"”.

Wystąpiło przyrostowe wywołanie, więc plik danych wsadowy jest aktualizowany o odpowiednią odpowiednią sygnaturę czasową. Odpowiednie zmiany są też stosowane do odpowiednich podmiotów (numer restauracji ma zaktualizowany numer telefonu).

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

Następnego dnia (29.12.2018) o 23:00 plik zostanie ponownie pobrany. Restauracja nadal ma taką samą wersję (18:00 z 28 grudnia), więc ten element jest usuwany i jego bieżąca wersja zostaje zachowana. Elementy menu i usługi zostały jednak zaktualizowane o nową wersję.

sygnatury czasowe mapy witryny;

Nagłówek odpowiedzi last-modified w mapie witryny nie wpływa na wersję elementu. Ma to wpływ na termin pobrania pliku danych przez Google.

Sprawdzonych metod

  • Aktualizuj nagłówek odpowiedzi tylko wtedy, gdy wszystkie pliki są aktualne i gotowe do pobrania.
  • Wyraźnie używaj update_time i delete_time.
  • Ustaw update_time, delete_time i dateModified na to, kiedy dane zmienią się po Twojej stronie.