Dans vos flux par lot, la version d'une entité est déterminée par le champ dateModified
de l'enveloppe du flux:
{
"@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 */
]
}
Toutes les entités répertoriées dans le champ dataFeedElement
auront le même horodatage, comme indiqué dans l'enveloppe.
Par exemple, vous pouvez créer le flux suivant avec deux entités:
{
"@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"
...
}
]
}
Une fois reçus et traités, les entités de menu et de restaurant ont toutes deux la version "2018-12-28T06:30:00:123-07:00".
Gestion des versions avec mises à jour incrémentielles
Lorsque vous envoyez une entité à l'aide de mises à jour d'inventaire, la version est définie via le champ update_time
(dans le cas d'un appel d'ajout/de mise à jour) ou le champ delete_time
(dans le cas d'un appel de suppression). Ces champs étant facultatifs, l'horodatage par défaut est défini sur la date de réception de l'appel par Google.
Exemple 1: heure de mise à jour explicitement définie
Supposons que l'appel incrémentiel suivant soit reçu à 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST pour cette entité portant l'ID "http://www.provider.com/somerestaurant", en supposant que le flux de données utilise le schéma d'inventaire v1:
POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
En dessous, le corps de la charge utile JSON contient le champ update_time
. Avec l'ID "http://www.provider.com/somerestaurant", la version de cette entité est 6:30:00 et non lorsqu'elle a été reçue (dix secondes plus tard à 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"
}
Exemple 2: update_time définie implicitement
Supposons que l'appel incrémentiel suivant soit reçu à 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST pour cette entité avec l'ID "http://www.provider.com/somerestaurant", en supposant que le flux utilise le schéma d'inventaire v1:
POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
Ci-dessous, le corps de la charge utile JSON ne contient pas le champ update_time
. L'entité portant l'ID "http://www.provider.com/somerestaurant" entraîne donc la gestion des versions 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"
}
}
Gestion des versions entre les traitements par lot et les versions incrémentielles
Une entité envoyée à Google est traitée et diffusée uniquement si elle dispose de la dernière version. Notez que le traitement des entités envoyées par lot prend généralement quelques jours, tandis que les entités envoyées via l'API incrémentielle sont traitées immédiatement.
Bonnes pratiques
- Définissez les champs
update_time
etdateModified
de manière incrémentielle et par lot, respectivement, en fonction de la date de modification de l'entité dans vos systèmes. - Si un flux par lot (fichier) répertorie plusieurs entités de niveau supérieur (par exemple, si vous associez vos restaurants avec des services et des menus), mettez à jour l'horodatage à mesure que les données d'une entité sont actualisées.
- Pour les appels incrémentiels, nous vous recommandons vivement de définir explicitement le champ
update_time
. - Une fois un appel incrémentiel effectué, il est impératif de mettre à jour l'horodatage de flux correspondant (
dateModified
) avant que Google ne le récupère à nouveau.
Exemple
Google récupère le fichier suivant à 11h le 28/12/2018 pour un tout nouveau 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"
...
}
]
}
Ces entités sont traitées correctement et gérées par la version "2018-12-28T06:30:00-07:00". Le traitement des flux par lot prend du temps, c'est pourquoi ils sont généralement diffusés deux jours plus tard.
Toutefois, à 13h00, le système du partenaire a mis à jour le numéro de téléphone du restaurant, ce qui entraîne l'appel incrémentiel suivant, que Google reçoit à 13h05 (cinq secondes plus tard) :
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"
}
L'élément update_time
est fourni explicitement et est supérieur (plus récent) que la version précédente (6:30 du même jour). L'entité de restaurant a donc la version "2018-12-28T13:00:00-07:00". Toutefois, la version des entités de menu et de service est toujours "2018-12-28T06:30:00-07:00".
Un appel incrémentiel a été effectué. Le flux par lot est donc mis à jour avec le nouvel horodatage correspondant. En outre, les modifications correspondantes sont appliquées aux entités concernées (le numéro de téléphone de l'entité restaurant est mis à jour).
{
"@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"
...
}
]
}
Le jour suivant (29/12/2018) à 23h, le flux est à nouveau récupéré. Le restaurant possède toujours la même version (13h le 28 décembre). Cette entité est donc supprimée et la version actuelle est conservée. Toutefois, les entités Menu et Service sont mises à jour avec une nouvelle version.
Codes temporels du sitemap
L'en-tête de réponse last-modified
dans le sitemap n'affecte pas la version d'une entité. Elle a une incidence sur le moment de la récupération du flux par Google.
Bonnes pratiques
- Mettez à jour l'en-tête de réponse uniquement lorsque tous les fichiers sont à jour et prêts à être récupérés.
- Utilisez explicitement
update_time
etdelete_time
de manière incrémentielle. - Définissez
update_time
,delete_time
etdateModified
sur le moment où les données changent de votre côté.