スモールビジネスのIT日誌

• (2017-03-28 06:21:38)

Amazonで出品している商品の見直し中。Amazonのデータベースの仕組みがよくわからないので、いちいち操作に手間取る。

「EVERYTHING STORE・全地球カタログ」を目指されているだけあって、出品方法は複雑でわかりにくい(出品のための勉強や試行錯誤が要求される)。

また、データベースの挙動が一定でないことも感じる。常時、入出力や表示方法は変更されているようだ。

変更がそのまま反映されるわけでない

さらに、レコードデータの書き換えは「ビジネスロジック」というプログラムが一枚挟まれており、出品者の変更が直接的に反映されているわけでない(とくに、商品名・SKU・画像)。

ビジネスロジックの挙動によって「在庫ファイル」のアップロードは成功しても、書き換えができない場合が多々ある。

しかも、データのアップロードもデータベースの反映も、数分から数十分と時間を要するため結果がすぐわからない、ビジネスロジックにどのような条件で阻止されるかもよくわかならいため試行錯誤しているうちに時間を消耗する。

また、数回アップロードすると修正される場合もあるし、数時間から24時間経過したら変更が許可されるといったロジックもありそうで、イライラさせられている。

変更されない項目は素直にAmazonサポートに申請した方(メールや電話)が、早いようだ。

キーとなるASIN

Amazonの商品管理の基本の基本は「ASIN」という10桁のAmazon独自商品コード。ISBNをベースに考案された。そのため書籍に関してはASINとISBNは互換性があり相互変換できるそうだ。

書籍以外の商品はJANやEANなどの国際コードとの互換性がある程度考慮されているかもしれないが、国際商品コードを持たない商品も多いので、よくわからない。

Amazon内ではASINはユニークな番号で重複しない(国が違うでそうでもないらしい)。この番号でURLも決定される。ASINで商品ページに到達できる。

商品URL → https://www.amazon.co.jp/dp/(ASIN)

この番号は基本となるだけにデータベースの側から考えるとユニークであるべきだし、一度使用されれば未来永劫再利用されるべきでない。変更ということもない・・・という前提で設計されていると思われる。

ASINの次にキーとなるSKU

各ベンダー・出品者が命名して良い商品番号。SKUとASINは紐付けされている。SKUは様々な人が命名するので当然重複が発生する。

よって、SKUとASINの関係はSKUからASINは一意だが、ASINから各出品者の独自SKUへの紐があるはずなので一意ではない。

だから、たとえば同じ出品者でも、ASINを同じにすれば一つ商品のSKUを変えることで、複数登録することもできある。

SKUも重要な番号で、いったん命名すれば「原則・変更不可」という規則になっている。

(※2017/4/9　一括ファイルアップロード機能で変更できたものがある、できないものもある。また変更反映に数分のときもあれば、48時間くらいかかることも)

しかし、商品ページをいったん削除して、もう一度同じASINを紐付けして商品登録すれば、結果的にSKUは変更可能。

再紐付けの方法はJANコードを入れる「external_product_id」にASINを入れることで可能。

external_product_id・・・ここに以前のAISN番号を入れる
external_product_id_type・・・「ASIN」


この状況から見ると、「出品商品ページ削除」や「出品商品削除」といった行為はSKUを削除または未使用な状態にしているだけであり、ASINは削除されていないし、生きている。

ASINは見えないだけで残っているので、それまでの顧客レビューなどの情報も削除されることなく、ASINのもとに保管されていることがわかる。

JANコード

ASIN・SKUの関係ほどには重視されていないように見える。入力は以前不要だったが現在は必須となっている。JANがない商品の登録は個別申請が必要で、一手間掛けさせられる。

つまり、AmazonとしてJANは必須の方向にしたいようだ。将来はSKUよりJANをベースに商品管理に利用するのではなかろうか。

しかし、商品登録でいったんASINが自動決定・自動採番された後は削除も可能だし、これなしに「在庫ファイル」のアップロードができるので、やはりどうでもよいコードのようだ。

結果的に推測されることは「JANなし商品のカタログ登録を制限」するためだけの役割か。現状は。ただ、いつ状況が変化するかわからない。

なお、当然のことながらこのASIN・SKU・JANの3コードは相互に紐付けされていると思われる。

たとえば、external_product_idセルに、明示的にASINを入れず、JANを入れると、このJANに紐付けされているASINのレコードが変更される。

前に一度、ある商品データ修正の際、間違ってまったく違う商品のJANをexternal_product_idセルに入れたら、完全に間違った商品レコードに入れ替わった。SKUも変化したので、この場合、JANにはASIN並の権限が与えられていると推測される。

以前のJAN(この商品レコードは削除済み)を使って商品登録をすると、それに紐付けされた昔のASINがゾンビのように蘇る場合と、なんと新規にASINが与えられる場合があり、その差は不明。これもビジネスロジック？

特定のASINにJANを紐付けする方法

「在庫ファイル」(Excel)内で、ASINやJANを記入する場所だが、不思議なことに同じセル(external_product_id)で行う。

セルが1つしかないので、ASINを入れたらJANは入れられなくなるし、JANをいれたらASINは入れられない。

ASINはAmazonが自動的に振るナンバーで出品者が自分で入力することを想定していないからこういう仕様なのか？

ASINとJANを入れるセル(external_product_id)の次のセル(external_product_id_type)には「ASIN」や「EAN」(JANの場合)などコード種別を入れる。

意味がよくわからない。あえて明示的にコード種別を入れなくてもexternal_product_idを見れば特定できると思うのだが。

それよりも、このセルを潰してASINとJANを入力できるようにしたらよいのにと思うが、まあ、事情があるのだろう。

現状、ASINとJANの同時入力ができないので、既存のASINにJANを振りたい場合は二段階でアップロードする。

(1) SKU＋既存AISN(SKUとASINの紐付け)
(2) SKU＋JAN(SKUとJANの紐付けで、結果的にASINとJANの紐付け)

顧客レビューを残してSKUを変更する方法

先ほどの(1) SKU＋既存AISN(SKUとASINの紐付け)はいったん与えたSKUを変更したいときにも使える方法。

これを実施するまえに、商品そのものを「削除」しておき、先ほどの(1) SKU＋既存AISN(SKUとASINの紐付け)を実施すれば、結果的にSKUの変更が可能。

ASINを新規に採番させないで、戻すこのやり方は過去のデータを残したいときに使う。

たとえば、顧客のレビューを残してSKUを変更したいときはそれなりに多いと思うが、そんなときはこのやり方しかないようだ。

独自ロジックで表示される商品タイトル

いったん登録された商品名は一定期間経過するなどの条件で、訂正や修正ができなくなる場合がある。

当社のケースでは管理画面上では訂正・修正は可能だが、実際の商品画面(商品詳細ページ)では変更されない。

タイトル変更不可の具体的な条件は公開されていないし、Amazon内部でもコロコロ変わっているのではなかろうか。

これはバグではないかと疑いサポートに問い合わせると、変更されない場合は審査の上、個別対応するという趣旨の返答だった。

「人力による個別対応？」
(サポートさんも大変だ。ハイテクIT企業を目指しながら、流通はやはり人力頼みになることは仕方ないと思う)


商品ページの商品タイトルとして商品データベースの「商品名」フィールドとは違った別のフィールドが存在するようだ。

そして、「商品名」が変更された場合、そのフィールドもリンクして変更されるかどうかはあるアルゴリズムというか条件をチェックするプログラム(*1)に一回通されてパスしなければ、変更されないと言うことらしい。


(*1)Amazon名で「自動ビジネスロジック」という名前のプログラムが噛んでいる模様。次のURLに説明あり →
https://sellercentral-japan.amazon.com/gp/help/200335450?referral=A2FPXC63ESXWBU_A3AO9RYULH0WHG

「複数の出品者が1つのASINに情報を提供する場合、自動ビジネスロジックにより、最終的に単一の商品詳細ページに表示される、商品説明、特徴、商品名、その他の詳細が決定されます」

・・・ということは「商品名」だけでなく詳細は自社が書き換えたどおりには必ずしも反映されないということか。


何のために？・・・まあ、いろいろあるんだろう。最初からあったとは思えない。

どんどん制限が増えるAmazonマケプレ出品

しかし、こんな感じでいろいろな制限が増えてくると出品者もやりにくいと思う。

MS社が、VB6以降、がんじがらめのプログラムを作り始めて、全世界の人々からなんとなく距離を置かれるようになり、IT革命のトップランナーではなくなる状況(とはいってもIBM同様、依然圧倒的なプレゼンスは残るが)と、なにやら似ている気がする。

Amazonも、大企業さんがたどりがちな道の同じ轍に陥り、同じパターンを描きピークアウトしていくだろう。早くもその陰がチラチラしてきたような。