Precio y moneda

Qué exige Google

Un número, un punto y una moneda

Google espera un precio escrito con punto como separador decimal y sin separador de miles, con el código de moneda ISO 4217, por ejemplo 119.95 EUR. El sale_price, cuando está presente, tiene que ir en la misma moneda que price y ser más bajo, y un sale_price_effective_date son exactamente dos fechas ISO 8601, con el inicio antes del fin. Cuando un producto se vende por suscripción, el coste de la suscripción tiene su propia forma obligatoria, y la presencia de una suscripción hace obligatorio google_product_category, el único caso en que ese atributo, opcional en el resto, es obligatorio.

Qué pasa si no lo haces

Un cambio de precio silencioso, o un rechazo

El decimal con coma es el peligroso, porque es ambiguo y no simplemente incorrecto. 1.234 es mil doscientos treinta y cuatro en notación continental y poco más de uno en la inglesa, y nada en el archivo decide cuál de las dos es. Leído del modo equivocado, un catálogo cambia de precio por un factor de mil sin un solo mensaje de error. Un código de moneda que falta, un sale_price en la moneda equivocada o una suscripción con un coste mal formado tienden a producir en cambio un rechazo: el producto deja de mostrarse hasta que el campo se corrige. Un precio de oferta que no es más bajo que el precio es de nuevo más silencioso: el producto se sigue mostrando, pero se pierde la anotación de oferta con el precio tachado.

Cómo arreglarlo a mano

Primero el formato, después las relaciones

• Sustituye los decimales con coma por puntos y elimina cualquier separador de miles, de modo que 1.234,56 se convierta en 1234.56.
• Añade el código de moneda ISO 4217 a cada precio y precio de oferta, acorde con el país en el que vendes.
• Deja en paz un valor genuinamente ambiguo como 1.234 hasta que conozcas su magnitud prevista; no lo fuerces a ninguna de las dos lecturas por conjetura.
• Confirma que cada sale_price comparte la moneda de su price y es más bajo, y que cualquier ventana de oferta contiene un precio de oferta.
• Cuando haya un coste de suscripción, añade un google_product_category válido y comprueba que el periodo, la duración y el importe están bien formados.

Cuáles de nuestras comprobaciones se aplican

Los campos de precio que FeedMender lee

Estas comprobaciones se leen directamente del propio registro del escáner. Cada una nombra el atributo que inspecciona y la severidad que le asignamos.

• price_formatprice, bloquea
• price_missingprice, bloquea
• price_unparseableprice, bloquea
• price_zeroprice, bloquea
• loyalty_price_in_price_fieldprice, en riesgo
• sale_price_formatsale_price, bloquea
• sale_price_currency_mismatchsale_price, bloquea
• sale_price_not_lowersale_price, en riesgo
• sale_window_without_sale_pricesale_price_effective_date, en riesgo
• sale_price_effective_date_formatsale_price_effective_date, bloquea
• sale_price_effective_date_partssale_price_effective_date, bloquea
• sale_price_effective_date_reversedsale_price_effective_date, bloquea
• unit_pricing_measure_formatunit_pricing_measure, bloquea
• unit_pricing_unit_mismatchunit_pricing_base_measure, bloquea

Las comprobaciones de precio, precio de oferta y suscripción forman juntas la familia Prices and currency en la lista completa de comprobaciones; las de precio por unidad figuran allí bajo EU compliance, porque ahí es donde vive la directiva de precios.

El camino más rápido

Deja que el análisis los encuentre

Repasar los precios a mano es exactamente el tipo de comprobación repetitiva que un análisis hace en una sola pasada, sin cambiar ningún precio por conjetura. El análisis gratuito enumera cada fallo de precio que encuentra junto al producto al que pertenece, antes de que tú decidas nada.