Prix et devise

Ce que Google exige

Un nombre, un point et une devise

Google attend un prix écrit avec un point comme séparateur décimal et sans séparateur de milliers, accompagné du code de devise ISO 4217, par exemple 119.95 EUR. Le sale_price, lorsqu'il est présent, doit être dans la même devise que price et plus bas que lui, et une sale_price_effective_date est exactement deux dates ISO 8601, le début avant la fin. Lorsqu'un produit est vendu sur abonnement, le coût de l'abonnement a sa propre forme obligatoire, et la présence d'un abonnement rend google_product_category obligatoire, le seul endroit où cet attribut par ailleurs facultatif est exigé.

Ce qui se passe sinon

Des prix modifiés en silence, ou un refus

La virgule décimale est le cas dangereux, parce qu'elle est ambiguë plutôt que simplement fausse. 1.234 vaut mille deux cent trente-quatre en notation continentale et un peu plus de un en notation anglaise, et rien dans le fichier ne tranche. Lu dans le mauvais sens, un catalogue voit ses prix changer d'un facteur mille sans le moindre message d'erreur. Un code de devise manquant, un sale_price dans la mauvaise devise ou un abonnement au coût mal formé produisent plutôt un refus : le produit cesse d'être diffusé jusqu'à ce que le champ soit corrigé. Un prix soldé qui n'est pas plus bas que le prix est encore plus discret, le produit est toujours diffusé, mais l'annotation de solde avec prix barré est perdue.

Comment corriger à la main

Le format d'abord, puis les relations

• Remplacez les virgules décimales par des points et supprimez tout séparateur de milliers, pour que 1.234,56 devienne 1234.56.
• Ajoutez le code de devise ISO 4217 à chaque prix et prix soldé, en accord avec le pays où vous vendez.
• Laissez une valeur réellement ambiguë comme 1.234 telle quelle tant que vous ne connaissez pas l'ordre de grandeur voulu ; ne la devinez pas dans un sens ou dans l'autre.
• Confirmez que chaque sale_price partage la devise de son price et est plus bas, et que toute période de soldes contient un prix soldé.
• Lorsqu'un coût d'abonnement est présent, ajoutez un google_product_category valide et vérifiez que la période, la durée et le montant sont bien formés.

Lesquels de nos contrôles s'appliquent

Les champs de prix que FeedMender lit

Ils sont lus directement dans le registre de l'outil d'analyse. Chacun nomme l'attribut qu'il inspecte et la sévérité que nous lui attribuons.

• price_formatprice, bloque
• price_missingprice, bloque
• price_unparseableprice, bloque
• price_zeroprice, bloque
• loyalty_price_in_price_fieldprice, à risque
• sale_price_formatsale_price, bloque
• sale_price_currency_mismatchsale_price, bloque
• sale_price_not_lowersale_price, à risque
• sale_window_without_sale_pricesale_price_effective_date, à risque
• sale_price_effective_date_formatsale_price_effective_date, bloque
• sale_price_effective_date_partssale_price_effective_date, bloque
• sale_price_effective_date_reversedsale_price_effective_date, bloque
• unit_pricing_measure_formatunit_pricing_measure, bloque
• unit_pricing_unit_mismatchunit_pricing_base_measure, bloque

Les contrôles de prix, de prix soldé et d'abonnement forment ensemble la famille Prices and currency sur la liste complète des contrôles ; les contrôles de prix unitaire y sont classés sous EU compliance, puisque c'est là que vit la directive sur les prix.

Le chemin le plus rapide

Laissez l'analyse les trouver

Passer les prix en revue à la main est exactement le genre de vérification répétitive qu'une analyse fait en un seul passage, sans modifier aucun prix au jugé. L'analyse gratuite liste chaque défaut de prix trouvé, rattaché au produit concerné, avant que vous ne décidiez quoi que ce soit.