Diese Seite wurde von der Cloud Translation API übersetzt.

v1-Versionsverwaltung in Batchfeeds

In Ihren Batchfeeds wird die Version einer Entität durch die dateModified im Feedumschlag:

{
  "@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 im Umschlag angegeben.

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

{
  "@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 Speisekarten- als auch die Restaurantentitäten werden nach Erhalt und Verarbeitung Version einzeln als „2018-12-28T06:30:00:123-07:00“.

Versionsverwaltung mit inkrementellen Updates

Wird eine Entität mithilfe von Inventaraktualisierungen gesendet, wird die Version über das Feld update_time (bei einem Aufruf zum Hinzufügen/Aktualisieren) oder delete_time (bei einem Delete-Aufruf). Da diese Felder optional sind, Der Standardzeitstempel ist auf den Zeitpunkt festgelegt, an dem Google den Anruf empfangen hat.

Beispiel 1: update_time explizit festgelegt

Angenommen, der folgende inkrementelle Aufruf wird um 2018-12-28T06:30:10:123-07:00 empfangen. für ein völlig neues Restaurant. Hier ist die HTTP-POST-Anfrage für diese Entität: mit der ID "http://www.anbieter.de/beispielrestaurant", unter der Annahme, dass im Datenfeed das Inventarschema von 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 ID: „http://www.provider.com/irgendeinrestaurant“ führt dazu, dass diese Entität 6:30:00 und nicht beim Empfang (zehn Sekunden später 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"
}

Beispiel 2: update_time implizit festgelegt

Angenommen, der folgende inkrementelle Aufruf wird um 2018-12-28T06:30:10:123-07:00 empfangen. für ein völlig neues Restaurant. Hier ist die HTTP-POST-Anfrage für diese Entität: mit der ID "http://www.provider.com/somerestaurant", vorausgesetzt, der Feed verwendet Version 1 Inventarschema:

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 nicht das Feld update_time. Die Entität mit der ID „http://www.provider.com/beispielrestaurant“ führt daher zu diese Entität wird als 6:30:10 versioniert:

{
// 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 Inkrementierung

An Google gesendete Entität wird nur verarbeitet und bereitgestellt, Version. Es dauert in der Regel einige Tage, bis Entitäten, die per Batch gesendet werden, und Entitäten, die über die inkrementelle API gesendet werden, sofort.

Best Practices

Legen Sie die Felder update_time und dateModified inkrementell und im Batch fest. je nachdem, wann das Element in Ihren Systemen geändert wurde.
Wenn in einem Batch-Feed (Datei) mehrere übergeordnete Elemente aufgeführt sind, z. B. Ihre Restaurants mit Dienstleistungen und Speisekarten verknüpfen, und aktualisieren Sie dann den Zeitstempel werden die Daten einer Entität aktualisiert.
Bei inkrementellen Aufrufen empfehlen wir dringend, den Parameter update_time.
Sobald ein inkrementeller Aufruf erfolgt ist, muss der entsprechende Feed Der Zeitstempel (dateModified) wird ebenfalls aktualisiert, bevor Google ihn noch einmal abruft.

Beispiel

Google ruft die folgende Datei am 28.12.2018 um 11:00 Uhr für einen komplett neuen Restaurant:

{
  "@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 versioniert als "2018-12-28T06:30:00-07:00". Da die Verarbeitung von Batch-Feeds einige Zeit in Anspruch nimmt, werden in der Regel zwei Tage später bereitgestellt.

Um 13:00 Uhr hat das System des Partners jedoch ein Update zur Telefonnummer des Restaurants. Dies führt zum folgenden inkrementellen Anruf, der bei Google um 13:05 Uhr (5 Sekunden später):

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 höher (neuer) als die in der vorherigen Version (6:30 Uhr am selben Tag) veröffentlicht als „2018-12-28T13:00:00-07:00“. Die Menü- und Serviceentitäten werden weiterhin als „2018-12-28T06:30:00-07:00“ versioniert.

Da es einen inkrementellen Aufruf gab, wird der Batch-Feed mit der neuen entsprechenden Zeitstempel. Außerdem werden die entsprechenden Änderungen relevanten Rechtssubjekten (die Telefonnummer des Restaurants wurde 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 immer noch dieselbe Version (13:00 Uhr am 28. Dezember), sodass dieses Element entfernt wird. und die aktuelle Version wird beibehalten. Die Entitäten für Speisekarte und Leistung sind jedoch mit einer neuen Version aktualisiert.

Zeitstempel der Sitemap

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

Best Practices

Aktualisieren Sie den Antwortheader nur, wenn alle Dateien aktuell und bereit für abgerufen werden.
Verwenden Sie update_time und delete_time explizit inkrementell.
update_time, delete_time und dateModified auf den Zeitpunkt festlegen, zu dem sich die Daten ändern auf Ihre Seite zu leiten.