【Amazon輸出】意外と知らない価格改定の仕組み

価格改定

この記事を読むのに必要な時間は約 16 分です。

■ 意外と知らない価格改定の仕組み

皆さんは、ご自身が出品している商品の価格をどれくらいの頻度で変えていますか?

先日、Amazonがセラーセントラル上で価格改定を行える「Automate Pricing」という機能をリリースしました。
このホットな機能のおかげで、初心者の方も今より価格改定というワードを認知する事でしょう。

Automate Pricingの機能分析に関する記事は、現在解析中なので、また後ほど投下する予定です。
という事で今回は、価格改定の重要性についてお伝えしたいと思います。

 価格改定とは

そもそも価格改定とは、単に価格を変えるという作業の事を指します。
ただし、価格改定というと一般的に「システム」や「ツール」と言ったワードを同時に連想するのでは無いでしょうか?

手動で行う分には、「価格を変えている」。
システムで自動的に行う分には、「価格改定を行っている」。

なんと言うか、私の周りでもこんな風に意識付けされています。
という事で、価格改定とは価格を戦略的に変える行為であるが、一般的にはそれを自動的かつ高速に行えるシステムと勝手に定義します。

それでは、そんな価格改定システムについて次から詳しく書いていきます。

 価格改定の怖さ

皆さん、価格の操作を他人に任せるのは怖いですよね?
例えシステムに任せるのだとしても、それは同じ事だと思います。

「自分が1500円で仕入れた商品を2500円で売りたいのに、勝手に1円で出品されている!」

こんな大惨事が引き起こされる事もあるかもしれません。

事実、イギリスのRepricer Express社が提供する価格改定システムでは、2年くらい前に暴発した経緯があります。
当時は、「Amazonで1ペニー祭り」とかなり騒がれていました。

このケース自体は、Amazonの協力によって対応されましたので、逆に安心感のあるセラーも居るかも知れません。
しかし、これは大型の暴発であるからAmazonが協力的してくれたのであって、他国の企業が開発している「せどりツール」で同様の事が起こったとしたらどうなるか?
これは、暴発してみないと分かりゃしません。

どうでしょう?価格改定システムの怖さが垣間見えたのでは無いでしょうか?

それでも、怖いのはシステムだけじゃありません。
私が見てきた限り、エクセルベースで価格改定をしているような場合、大抵墓穴を掘る事態を引き起こされる方が多いです。

例えば、

「コピペミスで1行ずれてしまい、出品価格が全てずれてしまった!
寝てる間に300件ほどの赤字注文が。。。」

こんな事も、ざらにあります。
つまり、手動でやっても何らかの異常事態が発生する事があるという事です。

私は良く「夜、寝る前に大きな事(改定など)はしないでください。」と助言させてもらうんですが、それでも、寝る前に手動で価格を変える為にアップロードしてしまう人が結構いらっしゃる。
価格改定というより、こういうのは人間の怖さでもありますよね。

あなたは、どちらの怖さで妥協しますか?

次からは、あなたの恐怖心を少しでも取り除く為に、価格改定システムの内部構造について解き明かしたいと思います。

価格改定システムの脳味噌

突拍子もなく切り込みますが、皆さん、他人をいきなり信用する事なんて出来ませんよね。
信用する前に、相手が何を考えているのか、どんな人なのかを知る事から関係が始まっていくのではないかと思います。
特に、お金が絡むのであれば尚更です。

それは、システムにおいても同じ事と言えるでしょう。
あなたが使う価格改定システムの脳味噌が一体どんな事を考えて、値下げ、あるいは値上げをするのか?
最低でも、利用する前に少しは脳内の仕組みを把握しておくべきです。

システムというのは必ずしも、あなたの命令に忠実であるとは限りません。
利益に直接関係する行為を代行させる訳なので、暴発しないシステムかどうかを客観的に判断していきましょう。

では、まず最初に価格改定システムの基礎的な仕組みについて解説します。

価格改定システムの脳味噌は単純です。
あなたが欲求する「もしも、〇〇ならば▲▲円にする」というような文章で構成されています。

その○○の部分にあたるのが条件です。
ちなみに、条件が一つだけでは価格改定システムは同じことをするばかりなので、実際には「もしも、〇〇ならば▲▲円にするが、もしも、□□なら◆◆円にする」と複数の条件が加わります。
このように○○と□□のように、複数の条件によって分けられるような事をプログラムでは、広く「条件分岐」と呼びます。

次は、その条件分岐について洗い出してみたいと思います。

 価格改定システムにおける条件分岐

Amazonにおける価格改定システムでは、一般的に次のような条件分岐で構成されます。

  • ライバルよりも価格が自分よりも(高い・低い)場合
  • ライバルの評価が(高い・低い)場合
  • ライバルがいない場合
  • カートの価格が自分よりも(高い・低い)場合
  • カートが取れていない場合

もしも、あなたの価格改定システムがこれくらいの条件分岐しか行えないようであれば、Amazonの無料で使える価格改定機能を利用した方がマシでしょう。

それでは、一般的でない複雑な価格改定が出来るシステムでは、例えばどのような条件分岐が行えるのか
以下に、ほんの一部をまとめました。

  • Amazonが競合している場合
  • 競合者数が(多い・少ない)場合
  • ライバルの在庫数が(多い・少ない)場合
  • 売れ行きが(良い・悪い)場合
  • 在庫の滞留期間が(長い・短い)場合
  • コンディションに応じた条件
  • 一定期間のカート平均価格より自分の価格が(高い・低い)場合
  • 一定期間の最低価格より自分の価格が(高い・低い)場合
  • 特定のセラーより自分の価格が(高い・低い)場合
  • 仕入先の在庫数が(多い・少ない)場合
  • 他プロダクトの価格より自プロダクトの価格が(高い・低い)場合
  • etc…

複雑な価格改定が出来るシステムでは、このような感じで条件がまだまだ存在します。
Amazonでは、カートの保有率を上げる事が最も大事な戦略ですが、値下げ行為はカートの保有率を上げる要素の一つにしか過ぎず、カートが取れる保証は何処にもありません。
初心者であれ、上級者であれ、価格改定の条件に幅広い選択肢を用意してくれるシステムを常に利用するべきです。

 価格改定システムにおけるアクション

これまで、価格改定システムにおける条件について、色々と説明してきました。
次は、その条件に基づいてプログラムが最終的にどのように動作し、実行されていくのかを解説します。
この記事では、そういった最終的な動作、実行を「アクション」と呼んで行きます。

先ほど、価格改定システムの概要を

価格改定システムの脳味噌は単純です。
あなたが欲求する「もしも、〇〇ならば▲▲円にする」というような文章で構成されています。

このように説明しました。

これから解説する「アクション」とは、上記の「▲▲円にする」という部分にあたります。
つまり、値下げするのか値上げするのか、どのような行為を行うかの直接的な部分にあたるので、とても重要な部分です。

一般的な価格改定システムにありうるアクションを以下に並べました。

  • 値下げ
  • 値上げ
  • 待機

大抵の価格改定のシステムでは、これらの三つが頻繁に行われています。
値下げと値上げはお分かりだと思いますが、待機も処理の内の一つです。
最も多く実行されているのが待機でしょう。
後は、価格改定システムの癖(アルゴリズム)によって、値下げか値上げのどちらかがより多く実行されます。

ちなみに、複雑な価格改定システムでは、以下のようなアクションも行えたりします。

  • 在庫数操作
  • 出品停止
  • 在庫注入アラート
  • etc…

条件程多くはありませんが、アクションにも色々なバリエーションが複雑になればなるほど存在します。
カートの保有率を上げるのが大事だと先ほど言いましたが、在庫数を上げたりするのも保有率を上げる為の1つの要素です。
それが出来るか出来ないかでは、えらい違います。

ここまで、アクションについて紐解いてきましたが、注意して欲しいのはあなたのシステムがどのようにしてアクションをAmazon側に反映させているかという事です。
今までに、Amazon側に反映させる部分のプログラムをAPIからAPIでないパターンまで組んで来た経験上、最も良いパターンと言えるのは、APIによってXMLなどで送信する形です。
CSV(カンマ区切り)やTSV(タブ区切り)のデータでの反映は、データの形式が簡易的なのでトラブル時にあまりお勧めしません。

さらに、「CSVやTSVを出力するから後は自分でAmazonに反映させてね」という頭の価格改定システムを利用されている場合は、人の操作が絡むので余計怖いですからお勧めしません。
経験上、物事の99パーセントは「ヒューマンエラー」、つまり人間が引き起こすミスなどによって生じるエラーが大半だからです。
先述したように、エクセルやスプレッドシートなどで管理するなどはもっての他です。
ただし、マクロやJSが使えるのであれば話は別です。

 価格改定システムの速度を確かめろ

「僕の価格改定システムは速度が速いんだ。」

自慢げに話される方がたまにいらっしゃいますが、果たしてどれくらいの速度なら早いのでしょうか。

価格改定システムで気にすべき速度は、大きく2つあります。
まずは、「ライバルの情報をどれくらいの速度で取得してくるか?」です。

現時点は、ライバルの情報を取得してくるのに毎時30分も掛かっているようでは、非常に遅いと言えます。
Amazon側からも多数のAPIが提供されており、基本的にライバルの価格情報は変わったタイミングで取得する事が出来ます。
しかし、その瞬時のタイミングで取得しないAPIを利用しているシステムだった場合、既にロスタイムが発生します。

あなたの価格改定システムがどのタイミングでライバルの情報を取得して来ているのかを調べるには、開発者に聞くか、実際に反映される速度をテストするか、どちらかしか方法はありません。
もちろん、所詮はAPIですから、Amazonの調子が悪い時は遅くなる事もあります。
テストをされる場合は、複数回行い、検証と呼べるレベルで行いましょう。

次に、気にすべき速度は、「価格を反映させる速度」です。

ライバルの価格情報を取得して来たら、その次は計算処理ですが、プログラムでは単純な四則演算の負荷は微々たるものです。
そんな所の速度を気にする必要が無いので、そこを飛ばして、価格を反映させる速度を気にするべきです。

これもAmazon側が提供するファイル形式やAPIによって、若干変わってきます。
若干と言いましたが件数が多ければ多いほど、その差が開いてきます。

また、ファイルをAmazonへ送信した後、その次にどれだけの間隔をあけて送信するのかによっても変わってきます。
どのアップ形式が一番早く、効率が良いのか。
そこもちゃんと突き詰めている価格改定システムは信頼出来ると言えるでしょう。

 価格改定システムのエラー対策

価格改定システムの速度や条件、アクションなど、重要な点を解説しましたが、次はもっとも大事なポイントを説明します。

システム・ツールというのは、エラーを未然に防ぐ対策非常に重要です。
高度なコードを書く人は、大抵このエラー処理が細かいもんです。
コードを書く段階で、失敗を繰り返し、成功率を上げていくのがプログラミングだと思ってます。

一度もエラーを吐かずに、組みあがるプログラムなんていうものは「ハローワールド」ぐらいでしょう。

では、ハローワールドなんて意味分からない言葉が出てきたところで、本題に。
価格改定システムのエラーを防ぐためには、具体的に「もしも○○の箇所でエラーが発生した場合、○○をする。」という、文章の元にプログラムが展開していく必要があります。

例えば、価格改定を行った後ファイルに異常があったりなんらかの影響でAmazon側から拒否され、反映に至らない場合があります。
その様な場合に、どういったエラー処理が行われるのか?
出来ればここまで把握しておきたいものです。
こういうエラーに対する処理の事を「例外処理」と広く呼びます。

システム販売側にこのような事を質問してみても良いかもしれません。
ちなみに、「Amazonで1ペニー祭り」でのエラーも、この部分でのチェック対策があれば、祭りになっていなかったはずです。
あなたの物販致命的な影響を及ぼしかねない部分に関する事ですから、販売側技術的な質問をしてみるのが一番です。

チェック機能を欠くようであれば、同様な事が起こりうる可能性はあります。
販売者側は、責任を取らないような文言を購入時に用意しているはずですから、契約上の責任は利用者本人が背負う必要が出てくるはずです。
システム面での恐怖心をぬぐうには、「厳しいチェック機能がどこの箇所に含まれているのか?」が最重要です。

■ まとめ

今や価格改定は、EC事業者にとって無くてはならない、重要な武器の一つです。
その武器をライバルに向けているつもりが、暴発してしまうなんて事が無いように、安全装置が常に動作しているかどうかを確認してください。

また、次回以降の記事で、Amazonが提供する「Automate Pricing」という価格改定機能の分析レポを共有したいと思います。
私の考えだと、この「Automate Pricing」は内部構造的に価格情報取得から反映までの速度は最速だと推測しています。

しかし、注意してください。
Amazonと言えど、大きな仕様変更がある際に良くサーバーが落ちるように、何があるか分かりません。
それでも、Amazonが提供する機能ですから何かエラーがあった場合は、Amazon側が必ず保証してくれる事でしょう。

その安心感は、どの価格改定システムにも勝ります
最初はあまり頼り過ぎず、徐々に移行するか利用していく事をお勧めします。

この記事を書いた人

TAITOBA
自らがECとしてのプレイヤーである傍ら、年がら年中、Amazonの実験や解析に打ち込む。 そんな日々から得た貴重なデータやどうでもいいデータ、さらにECについて思う事などを好きなだけ語り尽くします。

シェア!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です