Questa pagina è stata tradotta dall'API Cloud Translation.

Controllo delle versioni v1 nei feed batch

Nei tuoi feed collettivi, la versione di un'entità viene determinata tramite Campo dateModified nella busta 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 */
  ]
}

Tutte le entità elencate nel campo dataFeedElement avranno lo stesso timestamp, come indicato nella busta.

Ad esempio, potresti avere il seguente feed con due entità:

{
  "@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 volta ricevute ed elaborate, entrambe le entità menu versioni singole come "2018-12-28T06:30:00:123-07:00".

Controllo delle versioni con aggiornamenti incrementali

Quando invii un'entità utilizzando gli aggiornamenti dell'inventario, la versione viene impostata tramite il campo update_time (in caso di chiamata di aggiunta/aggiornamento) oppure il campo delete_time (nel caso di una chiamata di eliminazione). Poiché questi campi sono facoltativi, il timestamp predefinito è impostato sulla data in cui Google ha ricevuto la chiamata.

Esempio 1: update_time impostato esplicitamente

Supponiamo che la seguente chiamata incrementale venga ricevuta il 28-12-2018T06:30:10:123-07:00 per un ristorante completamente nuovo. Ecco la richiesta POST HTTP per l'entità con ID "http://www.provider.com/someRestaurant", supponendo che il feed di dati utilizzi schema dell'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

Di seguito, il corpo del payload JSON contiene il campo update_time. L'entità con ID "http://www.provider.com/qualsiasiristorante" fa sì che questa entità versione 6:30:00 e non quando è stato ricevuto (dieci secondi dopo, 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&quot;
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

Esempio 2: update_time impostato in modo implicito

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

Di seguito, il corpo del payload JSON non contiene il campo update_time. La entità con ID "http://www.provider.com/someRestaurant" risulta perciò in il controllo delle versioni di questa entità è 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"
  }
}

Controllo delle versioni tra batch e incrementali

Un'entità inviata a Google viene elaborata e pubblicata solo se ha la versione più recente completamente gestita. Tieni presente che le entità inviate tramite batch di solito richiedono alcuni giorni mentre le entità inviate tramite l'API incrementale vengono elaborate immediatamente.

Best practice

Imposta i campi update_time e dateModified in modo incrementale e in batch rispettivamente, in base a quando l'entità è stata modificata nei tuoi sistemi.
Se un feed batch (file) elenca più di un'entità di primo livello (ad esempio, associare i tuoi ristoranti a servizi e menu), quindi aggiorna il timestamp come vengono aggiornati i dati di un'entità.
Nelle chiamate incrementali, consigliamo vivamente di impostare in modo esplicito campo update_time.
È fondamentale che, una volta effettuata una chiamata incrementale, il feed corrispondente anche il timestamp (dateModified) viene aggiornato prima che Google lo recuperi di nuovo.

Esempio

Google recupera il seguente file alle 11:00 del 28/12/2018 per un'anteprima ristorante:

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

Queste entità vengono elaborate correttamente e vengono sottoposte al controllo delle versioni "2018-12-28T06:30:00-07:00". Poiché l'elaborazione dei feed batch richiede tempo, in genere vengono pubblicati 2 giorni dopo.

Alle 13, invece, il sistema del partner aggiorna il telefono del ristorante numero di telefono, il che genera la seguente chiamata incrementale, che Google riceve alle 13:05 (5 secondi dopo):

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

Il valore update_time è fornito esplicitamente ed è superiore (più recente) al valore precedente (06:30 dello stesso giorno), quindi l'entità ristorante ora versioned come "2018-12-28T13:00:00-07:00". Tuttavia, il menu e le entità di servizio sono ancora versioni come "2018-12-28T06:30:00-07:00".

È stata eseguita una chiamata incrementale, quindi il feed batch viene aggiornato con i nuovi il timestamp corrispondente. Inoltre, le modifiche corrispondenti vengono applicate entità pertinenti (il numero di telefono del ristorante è aggiornato).

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

Il giorno successivo (29/12/2018) alle 23:00, il feed viene recuperato di nuovo. Ristorante ha ancora la stessa versione (13:00 del 28 dicembre), pertanto questa entità viene eliminata e viene mantenuta la versione corrente. Tuttavia, le entità Menu e Service sono aggiornato con una nuova versione.

Timestamp della Sitemap

L'intestazione della risposta last-modified nella Sitemap non incide sulla di un'entità. Incide quando il feed viene recuperato da Google.

Best practice

Aggiorna l'intestazione della risposta solo quando tutti i file sono aggiornati e pronti per il recupero dell'account.
Usa in modo esplicito update_time e delete_time in modo incrementale.
Imposta update_time, delete_time e dateModified quando i dati cambiano da parte tua.