Diese Seite wurde von der Cloud Translation API übersetzt.

v1-Versionsverwaltung in Batchfeeds

In Ihren Batchfeeds wird die Version einer Entität durch das Feld dateModified im Umschlag des Feeds bestimmt:

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

Alle im Feld dataFeedElement aufgeführten Entitäten haben denselben Zeitstempel, wie auf dem Umschlag angegeben.

Sie könnten beispielsweise den folgenden Feed mit zwei Entitäten erstellen:

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

Sowohl die Menü- als auch die Restaurantentitäten werden nach Erhalt und Verarbeitung einzeln als „2018-12-28T06:30:00:123-07:00“ versioniert.

Versionsverwaltung mit inkrementellen Updates

Beim Senden einer Entität mithilfe von Inventaraktualisierungen wird die Version über das Feld update_time (bei einem Hinzufügen/Aktualisieren-Aufruf) oder das Feld delete_time (bei einem Löschaufruf) festgelegt. Da diese Felder optional sind, wird der Standardzeitstempel auf den Zeitpunkt festgelegt, zu dem Google den Aufruf erhalten hat.

Beispiel 1: Update_time explizit festgelegt

Angenommen, der folgende inkrementelle Anruf wird am 2018-12-28T06:30:10:123-07:00 für ein völlig neues Restaurant empfangen. Hier sehen Sie die HTTP-POST-Anfrage für die Entität mit der ID "http://www.provider.com/somerestaurant", vorausgesetzt, der Datenfeed verwendet das Inventarschema v1:

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

Unten enthält der JSON-Nutzlasttext das Feld update_time. Die Entität mit der ID "http://www.provider.com/somerestaurant" führt dazu, dass diese Entität als 6:30:00 versioniert wird und nicht als sie empfangen wurde (zehn Sekunden später um 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"
}

Beispiel 2: update_time implizit festlegen

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

Im folgenden Beispiel enthält der JSON-Nutzlasttext nicht das Feld update_time. Die Entität mit der ID „http://www.provider.com/somerestaurant“ führt daher dazu, dass diese Entität als 6:30:10 versioniert wird:

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

Versionsverwaltung zwischen Batch- und inkrementeller Version

Eine an Google gesendete Entität wird nur verarbeitet und bereitgestellt, wenn sie die neueste Version hat. Die Verarbeitung von Entitäten, die über einen Batch gesendet werden, dauert in der Regel einige Tage, während Entitäten, die über die inkrementelle API gesendet werden, sofort verarbeitet werden.

Best Practices

Legen Sie die Felder update_time und dateModified inkrementell bzw. im Batch fest, je nachdem, wann die Entität in Ihren Systemen geändert wurde.
Wenn ein Batchfeed (Datei) mehr als eine übergeordnete Entität aufführt (z. B. wenn Sie Restaurants mit Dienstleistungen und Speisekarten verknüpfen), aktualisieren Sie den Zeitstempel, wenn die Daten einer Entität aktualisiert werden.
Bei inkrementellen Aufrufen wird dringend empfohlen, das Feld update_time explizit festzulegen.
Nach einem inkrementellen Aufruf muss der entsprechende Feedzeitstempel (dateModified) ebenfalls aktualisiert werden, bevor Google ihn noch einmal abruft.

Beispiel

Google ruft am 28.12.2018 um 11:00 Uhr die folgende Datei für ein völlig neues Restaurant ab:

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

Diese Entitäten werden erfolgreich verarbeitet und haben die Version „2018-12-28T06:30:00-07:00“. Da die Verarbeitung von Batchfeeds einige Zeit in Anspruch nimmt, werden sie in der Regel zwei Tage später bereitgestellt.

Um 13:00 Uhr wird im System des Partners jedoch die Telefonnummer des Restaurants aktualisiert. Dies führt zum folgenden inkrementellen Anruf, der Google um 13:05 Uhr (5 Sekunden später) empfängt:

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

Die update_time wird explizit angegeben und ist größer (neueste) als die vorherige Version (6:30 Uhr am selben Tag), sodass die Restaurantentität jetzt als „2018-12-28T13:00:00-07:00“ versioniert wird. Die Menü- und Dienstentitäten werden jedoch weiterhin als „2018-12-28T06:30:00-07:00“ versioniert.

Da es einen inkrementellen Aufruf gab, wird der Batchfeed mit dem neuen entsprechenden Zeitstempel aktualisiert. Außerdem werden die entsprechenden Änderungen auf die relevanten Entitäten angewendet (die Telefonnummer der Restaurantentität wird aktualisiert).

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

Am nächsten Tag (29.12.2018) um 23:00 Uhr wird der Feed noch einmal abgerufen. Das Restaurant hat noch dieselbe Version (13:00 Uhr am 28. Dezember), sodass diese Entität verworfen und die aktuelle Version beibehalten wird. Die Entitäten „Menü“ und „Service“ werden jedoch mit einer neuen Version aktualisiert.

Sitemap-Zeitstempel

Der Antwortheader last-modified in der Sitemap wirkt sich nicht auf die Version einer Entität aus. Sie wirkt sich darauf aus, wann der Feed von Google abgerufen wird.

Best Practices

Aktualisieren Sie den Antwortheader nur dann, wenn alle Dateien aktuell sind und abgerufen werden können.
Verwenden Sie update_time und delete_time explizit inkrementell.
Legen Sie für update_time, delete_time und dateModified den Wert fest, wenn sich die Daten Ihrerseits ändern.