Prezzo e valuta

Cosa richiede Google

Un numero, un punto e una valuta

Google si aspetta un prezzo scritto con il punto come separatore decimale e senza separatore delle migliaia, con il codice valuta ISO 4217, per esempio 119.95 EUR. Il sale_price, quando presente, deve essere nella stessa valuta di price e più basso, e un sale_price_effective_date è composto esattamente da due date ISO 8601, inizio prima della fine. Quando un prodotto è venduto in abbonamento, il costo dell'abbonamento ha una propria forma obbligatoria, e la presenza di un abbonamento rende obbligatorio google_product_category, l'unico punto in cui quell'attributo altrimenti facoltativo è richiesto.

Cosa succede se non lo fai

Riprezzatura silenziosa, o una mancata approvazione

Il decimale con la virgola è il caso pericoloso, perché è ambiguo e non semplicemente sbagliato. 1.234 è milleduecentotrentaquattro nella notazione continentale e poco più di uno in quella inglese, e nulla nel file stabilisce quale delle due. Letto nel modo sbagliato, un catalogo viene riprezzato di un fattore mille senza un solo messaggio di errore. Un codice valuta mancante, un sale_price nella valuta sbagliata o un abbonamento con un costo malformato tendono invece a produrre una mancata approvazione: il prodotto smette di essere mostrato finché il campo non viene corretto. Un prezzo scontato che non è più basso del prezzo è ancora più silenzioso: il prodotto continua a essere pubblicato, ma l'annotazione di sconto con il prezzo barrato va persa.

Come risolverlo a mano

Prima il formato, poi le relazioni

• Sostituisci i decimali con la virgola con il punto e rimuovi ogni separatore delle migliaia, così 1.234,56 diventa 1234.56.
• Aggiungi il codice valuta ISO 4217 a ogni prezzo e prezzo scontato, coerente con il paese in cui vendi.
• Lascia stare un valore davvero ambiguo come 1.234 finché non ne conosci l'ordine di grandezza previsto; non indovinarlo verso l'una o l'altra lettura.
• Verifica che ogni sale_price condivida la valuta del suo price e sia più basso, e che ogni finestra di sconto contenga un prezzo scontato.
• Dove è presente un costo di abbonamento, aggiungi un google_product_category valido e verifica che periodo, durata e importo siano ben formati.

Quali dei nostri controlli si applicano

I campi di prezzo che FeedMender legge

Questi vengono letti direttamente dal registro dello scanner stesso. Ognuno indica l'attributo che ispeziona e la gravità che gli assegniamo.

• price_formatprice, blocca
• price_missingprice, blocca
• price_unparseableprice, blocca
• price_zeroprice, blocca
• loyalty_price_in_price_fieldprice, a rischio
• sale_price_formatsale_price, blocca
• sale_price_currency_mismatchsale_price, blocca
• sale_price_not_lowersale_price, a rischio
• sale_window_without_sale_pricesale_price_effective_date, a rischio
• sale_price_effective_date_formatsale_price_effective_date, blocca
• sale_price_effective_date_partssale_price_effective_date, blocca
• sale_price_effective_date_reversedsale_price_effective_date, blocca
• unit_pricing_measure_formatunit_pricing_measure, blocca
• unit_pricing_unit_mismatchunit_pricing_base_measure, blocca

I controlli su prezzo, prezzo scontato e abbonamento formano insieme la famiglia Prices and currency nell'elenco completo dei controlli; i controlli sul prezzo unitario sono archiviati lì sotto EU compliance, perché è lì che vive la direttiva sull'indicazione dei prezzi.

La via più rapida

Lascia che l'analisi li trovi

Passare i prezzi in rassegna a mano è esattamente il tipo di controllo ripetitivo che un'analisi fa in un solo passaggio, senza riprezzare nulla a indovinare. L'analisi gratuita elenca ogni difetto di prezzo che trova, accanto al prodotto a cui appartiene, prima che tu decida qualsiasi cosa.