Price and currency

What Google requires

A number, a point, and a currency

Google expects a price written with a point as the decimal separator and no thousands separator, with the ISO 4217 currency code, for example 119.95 EUR. The sale_price, when present, has to be in the same currency as price and lower than it, and a sale_price_effective_date is exactly two ISO 8601 dates, start before end. Where a product is sold on subscription, the subscription cost carries its own required shape, and the presence of a subscription makes google_product_category mandatory, the one place that otherwise optional attribute is required.

What happens if you do not

Silent repricing, or a disapproval

A comma decimal is the dangerous one, because it is ambiguous rather than merely wrong. 1.234 is one thousand two hundred and thirty-four in continental notation and one and a bit in English, and nothing in the file settles which. Read the wrong way, a catalogue is repriced by a factor of a thousand without a single error message. A missing currency code, a sale_price in the wrong currency, or a subscription with a malformed cost tends to produce a disapproval instead: the product stops being shown until the field is corrected. A sale price that is not lower than the price is quieter again, the product still serves, but the strikethrough sale annotation is lost.

How to fix it by hand

Format first, then the relationships

• Replace comma decimals with points, and remove any thousands separators, so 1.234,56 becomes 1234.56.
• Append the ISO 4217 currency code to every price and sale price, matched to the country you sell in.
• Leave a genuinely ambiguous value such as 1.234 alone until you know its intended magnitude; do not guess it into either reading.
• Confirm each sale_price shares the currency of its price and is lower, and that any sale window contains a sale price.
• Where a subscription cost is present, add a valid google_product_category and check the period, length and amount are well formed.

Which of our checks apply

The price fields FeedMender reads

These are read straight from the scanner's own registry. Each names the attribute it inspects and the severity we assign it.

• price_formatprice, blocks
• price_missingprice, blocks
• price_unparseableprice, blocks
• price_zeroprice, blocks
• loyalty_price_in_price_fieldprice, at risk
• sale_price_formatsale_price, blocks
• sale_price_currency_mismatchsale_price, blocks
• sale_price_not_lowersale_price, at risk
• sale_window_without_sale_pricesale_price_effective_date, at risk
• sale_price_effective_date_formatsale_price_effective_date, blocks
• sale_price_effective_date_partssale_price_effective_date, blocks
• sale_price_effective_date_reversedsale_price_effective_date, blocks
• unit_pricing_measure_formatunit_pricing_measure, blocks
• unit_pricing_unit_mismatchunit_pricing_base_measure, blocks

The price, sale-price and subscription checks together form the Prices and currency family on the full checks list; the unit-pricing checks are filed there under EU compliance, since that is where the pricing directive lives.

The quicker way

Let the scan find them

Working through prices by hand is exactly the kind of repetitive checking a scan does in one pass, without repricing anything by guesswork. The free scan lists every price fault it finds against the product it belongs to before you decide anything.