Diese Seite wurde von der Cloud Translation API übersetzt.

Version 1 in Batchfeeds

In Ihren Batchfeeds wird die Version einer Entität über das Feld dateModified im Envelope 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 der Envelope.

Angenommen, Sie haben den folgenden Feed mit zwei Entitäten:

{
  "@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 Speisekarte als auch die Restaurantentität wurden nach Erhalt und Verarbeitung einzeln als "2018-12-28T06:30:00:123-07:00" versioniert.

Versionsverwaltung mit inkrementellen Updates

Wenn Sie eine Entität mithilfe von Inventaraktualisierungen senden, wird die Version über das Feld update_time (bei einem Aufruf zum Hinzufügen/Aktualisieren) oder über 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 zusätzliche Aufruf wird am 2018-12-28T06:30:10:123-07:00 für ein komplett neues Restaurant empfangen. Hier sehen Sie die HTTP-POST-Anfrage für die Entität mit der ID http://www.provider.com/somerestaurant" unter der Annahme, dass das Datenfeed-Schema v1 verwendet wird:

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 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, 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: Implizite Zeit für „update_time“ festlegen

Angenommen, der folgende zusätzliche Aufruf wird am 2018-12-28T06:30:10:123-07:00 für ein komplett neues Restaurant empfangen. Hier sehen Sie die HTTP-POST-Anfrage für diese Entität mit der ID http://www.provider.com/somerestaurant" unter der Annahme, dass im Feed das Inventarschema Version 1 verwendet wird:

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 die JSON-Nutzlast nicht 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: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. Entitäten, die über einen Batch gesendet werden, dauern 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 schrittweise fest, je nachdem, wann die Entität in Ihren Systemen geändert wurde.
Wenn ein Batchfeed (Datei) mehr als eine Top-Level-Entität enthält (z. B. wenn Sie Ihre Restaurants mit Speisekarten und Speisekarten koppeln), aktualisieren Sie den Zeitstempel, wenn die Daten einer Entität aktualisiert werden.
Wir empfehlen Ihnen dringend, das Feld update_time in inkrementellen Aufrufen explizit festzulegen.
Es ist unabdingbar, dass der entsprechende Feed-Zeitstempel (dateModified) bei einem inkrementellen Aufruf ebenfalls aktualisiert wird, bevor Google ihn noch einmal abruft.

Beispiel

Google ruft die folgende Datei am 28.12.2018 um 11:00 Uhr 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 verarbeitet und als „"2018-12-28T06:30:00-07:00"“ formatiert. Da die Verarbeitung von Batch-Feeds einige Zeit in Anspruch nimmt, werden sie in der Regel 2 Tage später bereitgestellt.

Um 13:00 Uhr hat das System des Partners jedoch eine Aktualisierung der Telefonnummer des Restaurants, was zum folgenden inkrementellen Anruf führt, den Google um 13:05 Uhr (5 Sekunden später) erhält:

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 wird explizit bereitgestellt und ist aktueller (neuere) als die vorherige Version (06:30 Uhr des gleichen Tages) und die Restaurantentität wird jetzt als „"2018-12-28T13:00:00-07:00"“ festgelegt. Die Speisekarte und die Dienstentitäten sind aber weiterhin als "2018-12-28T06:30:00-07:00" formatiert.

Da ein inkrementeller Aufruf erfolgt ist, wird der Batchfeed mit dem neuen entsprechenden Zeitstempel aktualisiert. Außerdem werden die entsprechenden Änderungen auf die relevanten Entitäten angewendet (die Telefonnummer des Restaurants 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 (1 PM am 28. Dezember), sodass dieses Element gelöscht und die aktuelle Version beibehalten wird. Die Menü- und Dienstentitäten wurden 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 ausdrücklich update_time und delete_time.
Legen Sie update_time, delete_time und dateModified fest, wenn sich die Daten auf Ihrer Seite ändern.