Google a publié une proposition dans l’instance GitHub du projet Schema.org qui propose de proposer une mise à jour sur Schema.org pour étendre les données structurées d’achat afin que les commerçants puissent fournir plus d’informations d’expédition qui apparaîtront probablement dans la recherche Google et d’autres systèmes.
Données structurées d’expédition Schema.org
Le nouveau type de données structurées proposé peut être utilisé par les commerçants pour fournir plus de détails sur l’expédition. Il suggère également d’ajouter la flexibilité d’utiliser des données structurées d’expédition à l’échelle du site qui peuvent ensuite être imbriquées avec les données structurées de l’organisation, évitant ainsi d’avoir à répéter les mêmes informations des milliers de fois sur un site Web.
La proposition initiale précise :
« Il s’agit d’une proposition de Google visant à prendre en charge une représentation plus riche des détails d’expédition (tels que les frais et la rapidité de livraison) et à rendre explicite ce type de données. S’il est adopté par schema.org et les éditeurs, nous considérons qu’il est probable que les expériences de recherche et autres systèmes de consommation pourraient être améliorés grâce à l’utilisation d’un tel balisage.
Ce changement introduit un nouveau type, ShippingService, qui regroupe les contraintes d’expédition (lieux de livraison, délais, limites de poids et de taille et tarif d’expédition). Les champs redondants de ShippingRateSettings sont donc obsolètes dans cette proposition.
En conséquence, les modifications suivantes sont également proposées :
certains champs de OfferShippingDetails ont été déplacés vers ShippingService ;
ShippingRateSettings propose davantage de moyens de spécifier le tarif d’expédition, proportionnel au prix de la commande ou au poids d’expédition ;
la liaison à partir de l’offre doit désormais être effectuée avec une liaison URI du Web sémantique standard.
La proposition est ouverte à la discussion et de nombreuses parties prenantes donnent leur avis sur la manière dont fonctionneraient les données structurées mises à jour et nouvelles.
Par exemple, une personne impliquée dans la discussion a demandé comment un type de données structurées à l’échelle du site placé au niveau de l’organisation pouvait être remplacé par des produits individuels contenant des informations différentes et quelqu’un d’autre a fourni une réponse.
Un participant à la discussion GitHub nommé Tiggerito posté:
« J’ai relu le document et ce que vous dites est logique. L’organisation est un endroit où les conditions d’expédition partagées peuvent être stockées. Mais ShippingDetails est toujours au niveau ProductGroup ou Product.
Voici comment je traite actuellement les détails d’expédition :
Dans le back-end, le propriétaire peut définir un ensemble global de détails d’expédition. Chacun contient les champs actuellement pris en charge par Google, comme le lieu et les heures, mais pas de détails sur les dimensions. Chaque candidature comporte également des conditions concernant le produit auquel la candidature peut s’appliquer. Cela peut inclure une fourchette de prix et une fourchette de poids.
Lorsque je génère les données structurées pour une page, j’inclus les entrées dans lesquelles le produit correspond aux conditions.
Ce changement semble me permettre de passer du filtrage des conditions sur le serveur à leur inclusion dans les données structurées sur la page du produit.
Ensuite, les consommateurs de données peuvent calculer quelles conditions d’expédition correspondent et donc quels tarifs sont disponibles lors de la commande d’un numéro spécifique du produit. Actuellement, vous ne pouvez fournir que les prix d’expédition d’un seul exemplaire.
Cette division signifie également qu’il est plus facile de fournir des informations spécifiques au produit ainsi que des informations d’expédition partagées sans avoir besoin de répétition.
Votre exemple dans le document à la fin pour utiliser Organization. Il semble que vous fassiez référence aux Conditions d’expédition d’un produit qui se trouve sur une page d’expédition. Ce croisement entre les pages pourrait réduire considérablement l’encombrement de la page produit, s’il est pris en charge par Google.
Le Googleur a répondu à Tiggerito :
« @Tiggerito
L’organisation est un endroit où les conditions d’expédition partagées peuvent être stockées. Mais ShippingDetails est toujours au niveau ProductGroup ou Product.
En effet, et c’est déjà le cas. Ce changement sépare également les deux significations de par exemple. largeur, hauteur, poids comme description du produit (dans ShippingDetails) et comme contraintes dans ShippingConditions où ils peuvent être exprimés sous forme de plage (QuantitativeValue a min et max).
Dans le back-end, le propriétaire peut définir un ensemble global de détails d’expédition. Chacun contient les champs actuellement pris en charge par Google, comme le lieu et les heures, mais pas de détails sur les dimensions. Chaque candidature comporte également des conditions concernant le produit auquel la candidature peut s’appliquer. Cela peut inclure une fourchette de prix et une fourchette de poids.
Lorsque je génère les données structurées pour une page, j’inclus les entrées dans lesquelles le produit correspond aux conditions.
Ce changement semble me permettre de passer du filtrage des conditions sur le serveur à leur inclusion dans les données structurées sur la page du produit.
Ensuite, les consommateurs de données peuvent calculer quelles conditions d’expédition correspondent et donc quels tarifs sont disponibles lors de la commande d’un numéro spécifique du produit. Actuellement, vous ne pouvez fournir que les prix d’expédition d’un seul exemplaire.
Certaines contraintes d’expédition ne sont pas disponibles au moment où le produit est répertorié ou même affiché sur une page (par exemple, destination d’expédition, nombre d’articles, vitesse de livraison souhaitée ou niveau client si l’utilisateur n’est pas connecté). Les ShippingDetails attachés à un produit doivent contenir des informations sur le produit lui-même uniquement, le reste est déplacé vers les nouvelles ShippingConditions dans cette proposition.
Notez que schema.org ne spécifie pas de cardinalité, nous pouvons donc spécifier plusieurs liens ShippingConditions afin que celui approprié soit sélectionné du côté du consommateur.
Cette division signifie également qu’il est plus facile de fournir des informations spécifiques au produit ainsi que des informations d’expédition partagées sans avoir besoin de répétition.
Votre exemple dans le document à la fin pour utiliser Organization. Il semble que vous fassiez référence aux Conditions d’expédition d’un produit qui se trouve sur une page d’expédition. Ce croisement entre les pages pourrait réduire considérablement l’encombrement de la page produit, s’il est pris en charge par Google.
En effet. C’est là que nous essayons d’arriver.
Discussion sur LinkedIn
Irina Tuduce, membre de LinkedIn (Profil LinkedIn), ingénieur logiciel chez Google Shopping, a lancé une discussion qui a reçu plusieurs réponses démontrant son intérêt pour la proposition.
Andrea Volpini (Profil LinkedIn), PDG et co-fondateur de WordLift, a exprimé son enthousiasme pour la proposition dans sa réponse :
« Comme Irina Tuduce, cela rationaliserait la modélisation de la vitesse de livraison, des emplacements et des coûts pour les grandes organisations.
En effet. C’est là que nous essayons d’arriver.
Une autre membre, Ilana Davis (Profil LinkedIn), développeur du JSON-LD pour l’application SEO Shopifyposté :
« J’ai déjà fait part de mes commentaires sur les conventions de dénomination mises en œuvre par schema.org. Ce qui me préoccupe pour Google, c’est de savoir comment exactement les commerçants intégreront ces données dans le balisage. Il est presque impossible d’obtenir des tarifs d’expédition exacts dans le SD s’ils fluctuent. Les commerçants peuvent saisir un tarif forfaitaire approximatif, mais ils se demandent souvent si cela est acceptable. Y a-t-il des conséquences pour eux si les tarifs d’expédition sont approximatifs (par exemple, une inadéquation des prix dans GMC désapprouve un produit) ?
Regard intérieur sur le développement de nouvelles données structurées
Le discussion LinkedIn en cours offre un aperçu de ce que pensent les parties prenantes des nouvelles données structurées à propos de la proposition. Le fonctionnaire Discussion sur Schema.org sur GitHub non seulement il donne une idée de l’évolution de la proposition, mais il offre aux parties prenantes la possibilité de fournir des commentaires pour façonner ce à quoi elle ressemblera finalement.
Il existe également un document Google public intitulé : Proposition de modification du schéma des détails d’expéditionqui contient une description complète de la proposition.
Image en vedette par Shutterstock/Stokkete
