「アメリカの Amazon でのリサーチ」「日本の Amazon での商品の選び方」「ヨーロッパでのリサーチ」は、まるでマーケットプレイスごとに独自の秘訣があるかのように、別々の質問として聞かれることがよくあります。
実際には、判断の順序はどこでも同じです。まず参入できないカテゴリーを外し、残ったカテゴリーの中で需要と競争のずれを探す。マーケットプレイスによって変わるのは方法ではなくデータです。通貨、言語、カテゴリー構造は、どれもマーケットプレイスごとに独立しています。
ですから、マーケットプレイスを切り替えるときに明確にすべきなのは、何を流用でき、何をやり直す必要があるかです。
マーケットプレイスの指定：省略してもエラーにならず、黙って米国になる
マーケットプレイスのデータ API で指定できる marketplace は 13 種類あります。US、JP、UK、DE、FR、IT、ES、CA、IN、MX、BR、AU、AE です。一回の照会が答えるのは一つのマーケットプレイスだけで、「世界全体の販売数」も「全マーケットプレイス合計の検索数」もありません。
ほとんどの API では marketplace が必須で、省略するとエラーになります。ただし、よく使う四つの API は例外で、marketplace は任意であり、省略すると US になります。
| API | ドキュメント |
|---|---|
| トラフィックキーワード逆引き | キーワード逆引き |
| ASIN 詳細 | ASIN 詳細 |
| 競合照会 | ASIN の競合 |
| 販売数推計 | ASIN 販売数推計 |
これが複数マーケットプレイスのリサーチで最も気づきにくい落とし穴です。日本を分析しているときにこの指定を忘れても、API はエラーを返さず、黙って米国のデータを返します。しかもこの四つは、単一の商品を見るときに最もよく使う API です。
したがって複数マーケットプレイスでの基本動作は、任意であっても、すべてのリクエストで marketplace を明示することです。同じ照会をマーケットプレイスごとに一回ずつ実行し、結果は分けて保存し、すべての行にマーケットプレイスを記録してください。マーケットプレイスのコードと通貨の一覧は付録のマーケットプレイス表にあります。
通貨はレスポンスから読み、コードから推測しない
市場統計のレスポンスには currency フィールドがあり、例では USD です。avgPrice、avgRevenue といった金額フィールドはすべて、この通貨での値です。
これをあえて強調するのは、付録のマーケットプレイス表で、メキシコ、ブラジル、オーストラリア、アラブ首長国連邦の四つは通貨の欄が空欄になっているからです。マーケットプレイスのコードをキーに自前の通貨表を引くコードでは、この四つで問題が起きます。安全なのは、金額は常にレスポンスの currency に従い、推測しないことです。
マーケットプレイスをまたいで金額を比べるには、もう一つ前提があります。換算には自分で決めた日付付きの為替レートを使い、その日付を表に記録することです。API は通貨換算を行いません。
マーケットプレイスをまたぐ比較では、金額より比率のほうが使いやすい。 新商品比率、シェア、返品率などの比率は通貨の影響を受けず、そのまま横並びで比べられます。ただし先に、各比率フィールドが小数か百分率かを確認してください。この単位の問題はAmazon 市場分析で扱っています。
市場統計 APIマーケットプレイスとカテゴリーノードごとの統計を、currency と翻訳済みのカテゴリー名とともに返します「ヨーロッパ」は一つのマーケットプレイスではない
データの上で「ヨーロッパ」は、UK、DE、FR、IT、ES の五つのコードです。
このうち DE、FR、IT、ES の四つは同じ通貨（EUR）を使い、UK は GBP です。通貨が同じなので、四つを足し合わせて「ヨーロッパ市場」として扱いたくなりますが、需要も検索語も競争構造もそれぞれ独立しています。ドイツで人気の語とフランスで人気の語は、二つの言語による二つの語のセットであり、ドイツのカテゴリーで上位のブランドがイタリアでも同じ位置にいるとは限りません。
より妥当なのは、五つそれぞれで完全な分析を行い、そのうえで生の数字ではなく結論を並べて比べる順序です。
キーワードは各マーケットプレイスの言語で保存されている
注文キーワード逆引きのレスポンスでは、各語に keyword のほか、keywordCn と keywordJp という二つの翻訳フィールドが付きます。ドキュメントの例は次のとおりです。
| フィールド | 例 |
|---|---|
keyword | phone holder for desk |
keywordCn | 办公桌上的电话支架 |
keywordJp | デスク用フォンホルダー |
翻訳フィールドは読むための補助であって、キーワードリサーチの代わりではありません。日本の買い手は自分たちの言い回しで検索しており、米国のキーワード一覧を翻訳した語で検索しているわけではありません。直訳した語は誰も検索していないかもしれず、本当によく検索される語は思いつかないものかもしれません。
ですから日本やドイツでのキーワードリサーチの出発点は、そのマーケットプレイス自身のデータです。そのマーケットプレイスの ABA と逆引きの結果からライブラリを作り、翻訳フィールドは意味を理解するために使います。キーワードをマーケットプレイスごとに分けて扱うべき理由は、キーワードの最適化方法でも説明しています。
注文キーワード逆引き APIマーケットプレイスごとに注文につながった語を、中国語と日本語の翻訳フィールド付きで返しますカテゴリーパスはマーケットプレイスごとに定義されている
カテゴリーは nodeIdPath で特定します。例では 1064954:1069242:1069784:1069820:1069838:1069828 です。このノード ID はマーケットプレイスごとに定義されているので、米国の nodeIdPath が日本でも同じカテゴリーを指すと仮定しないでください。 マーケットプレイスを切り替えたら、そこでカテゴリーを改めて特定します。
市場統計 API は名称フィールドを二つ返します。nodeLabelPath はマーケットプレイス上のカテゴリー名のパスで、nodeLabelLocale は翻訳された名称です。ドイツや日本のカテゴリー構造を読むときは nodeLabelLocale がかなり役立ちますが、特定と記録には nodeIdPath を基準にしてください。
流用できるのは方法
マーケットプレイスを切り替えても、次のものはそのまま使えます。
- 判断の順序：まず外し、それから探す。Amazon の商品リサーチの進め方を参照
- カテゴリー構造の読み方：出品時期、出品者タイプ、価格の三つの分布。四つの分布でそのカテゴリーにまだ入れるかを決めるを参照
- フィールドの意味：
estで始まるものは推計値であること、productsとtotalProductsを区別することは、どのマーケットプレイスでも同じです
次のものはマーケットプレイスごとにやり直す必要があります。
- すべての閾値：「月間販売数がいくつなら大きいか」「新商品比率がどれくらいなら参入できるか」は、米国と日本で同じ数字ではありません
- キーワード：そのマーケットプレイスの言語で作り直します
- カテゴリーの特定：マーケットプレイスごとに
nodeIdPathを探し直します
このデータにできない三つのこと
物流、法規制、税務は含まれません。 配送方法、製品認証、税務上の義務はマーケットプレイスによって大きく異なり、そもそも参入できるかを左右しますが、どれも市場データには含まれていません。
通貨換算は行いません。 金額は各マーケットプレイスの通貨で返されるので、換算は自分で行い、レートの日付を記録してください。
現地化の力は判断しません。 日本のあるカテゴリーに余地があることはデータで分かりますが、リスティングの日本語が十分に自然か、アフターサービスが追いつくかは分かりません。
よくある質問
初めてなら、どのマーケットプレイスから始めるべきですか。 その決定はデータがしてくれるものではありません。候補のマーケットプレイスそれぞれに同じ指標を実行し、比率の結果を並べて比べ、そのうえで自社の供給体制と言語対応力を考え合わせるのが現実的です。
米国のデータで他のマーケットプレイスを代表できますか。 できません。需要、競争、価格帯はマーケットプレイスごとに独立しているので、米国での結論は他のマーケットプレイスで検証すべき仮説にすぎません。
同じ ASIN を別のマーケットプレイスで照会できますか。
できます。各照会で対応する marketplace を指定すれば、結果はマーケットプレイスごとに返ります。ASIN 詳細と販売数推計は省略すると米国になるので、他のマーケットプレイスでは必ず明示してください。ASIN が何を識別するかはASIN とはにあります。
複数マーケットプレイスのデータを一つの表にまとめられますか。 まとめられますが、マーケットプレイスの列と通貨の列を加え、マーケットプレイスをまたいで合計しないでください。キーワードのデータはマーケットプレイスごとに表を分けるのが望ましく、市場構造の判断はAmazon 市場分析にあります。