「Amazonに最適なウェブスクレイピングAPI」という問いに単一の答えはない。Amazonの監視は単一の作業ではないからだ。5つのマーケットプレイスにわたる2000のASINの価格を追跡すること、自社リスティングでバイボックスを誰が保持しているかを監査すること、あるカテゴリのベストセラーの入れ替わりを観察すること、これらはすべてAmazonに関わる作業だが、APIに求めるものはそれぞれ異なる。
そこで、四半期のうちに古くなり、自分のワークロードについては何も教えてくれないベンダーのランキングリストではなく、このガイドは選択肢を種類別に整理し、優れたAmazon APIと使えるAmazon APIを実際に分ける基準を示し、契約前に自社のASINで候補を検証する方法を提供する。
まず、合わないものを除外する
Amazon自身のAPIは、自社アカウントで作業するセラーやアフィリエイト向けに設計されており、独自の適格性条件と利用規約がある。自社のリスティング、注文、在庫にとっては正しいツールだ。しかし、カタログ全体にわたって競合の出品や価格、ランキングを監視する手段ではない。それがこのガイドの主題である。
その作業には3種類のAPIがある。
Amazon向けAPIの3種類
専用のeコマースAPI。 Amazonの各サーフェスごとに構造化されたエンドポイントを持つ。商品、検索、ベストセラー、セール、カテゴリ、セラープロフィール。ASINやクエリを送信すると、解析済みのJSONが返される。セレクタもパーサーの保守も不要で、Amazonがマークアップを変更しても、その変更をプロバイダーが吸収する。
汎用のウェブスクレイピングAPI。 任意のURLを送信すると、APIがプロキシ、レンダリング、リトライを処理し、自分で定義した抽出ルールに基づくHTMLまたはJSONが返される。どのリテーラーのどのページでも動作するため柔軟性が高いが、パース処理は自分で所有することになり、マークアップが変わった際の保守も自分の責任になる。
自己管理プロキシ。 ブラウザまたはHTTPクライアント、パーサー、リトライロジックをすべて自分で運用し、レジデンシャルプロキシを経由させる。最大限の制御と、非常に大規模な場合の最低単価コストが得られる一方、最もエンジニアリングの負担が大きい。このアプローチについてはプロキシを使ったAmazon商品データのスクレイピングで扱っている。
| 専用のeコマースAPI | 汎用のスクレイピングAPI | 自己管理プロキシ | |
|---|---|---|---|
| 出力 | サーフェスごとの構造化JSON | HTML、またはルールに基づくJSON | 自分で構築するもの |
| パーサーの保守 | プロバイダー | 自分 | 自分 |
| Amazon以外での利用 | 対応サイトに限定 | 任意のサイト | 任意のサイト |
| エンジニアリング負担 | 最小 | 中程度 | 最大 |
| 最適な用途 | 大量のAmazon処理、迅速な開始 | 複数リテーラーの混在監視 | 非常に大規模、カスタムフロー |
成熟した価格インテリジェンススタックの多くは、結局2種類以上を併用している。Amazon用の専用APIと、構造化エンドポイントが対応していない多数のリテーラーをカバーする汎用スクレイピングAPIだ。
Amazonにおいて実際に重要な基準
機能一覧はどれも似たように見える。しかし、以下の特性がデータが使えるかどうかを決める。
マーケットプレイスのカバレッジ。 Amazonは、同じASINに対して価格、セラー、在庫状況が異なる各国のストアフロントの集合である。米国だけでなく、自社が販売しているすべてのマーケットプレイスが対応しているかを確認する。
サーフェスのカバレッジ。 価格インテリジェンスには通常、商品ページ以上のものが必要になる。検索ランキング、ベストセラーの変動、セール情報、そして自分が誰と競合しているかを特定するためのセラーデータだ。自社のワークフローが必要とするサーフェスを列挙し、それぞれを確認する。
オーガニックとスポンサードの分離。 検索結果は有料掲載とオーガニック掲載が混在している。これらを区別せずに1つのリストとして返すAPIは、ランキング分析を静かに破壊する。
デバイス間の等価性。 モバイルとデスクトップでは結果の順序が異なる場合がある。顧客がモバイルで購入している場合、モバイルの結果が必要になる。
出力の安定性。 構造化APIは、そのスキーマが維持される場合にのみ価値がある。破壊的変更がどのように通知されるかを確認し、サンプルレスポンスを信頼するのではなく、トライアル期間中にフィールドの完全性を観察する。
成功時のみの課金。 ブロックされたリクエストや失敗したリクエストに対して支払うと、不安定な対象が予算の問題に変わる。成功したレスポンスに対してのみ課金するプロバイダーを優先し、「成功」の定義を確認する。
並行性と新鮮さ。 並行性の上限が、カタログをどれだけ速く更新できるかを決め、それが価格がどれだけ古くなり得るかを決める。
Amazonのパイプラインをすべて狂わせる1つの詳細
価格は、そのマーケットプレイス固有の形式による表示文字列として返され、通貨記号だけでは通貨を識別できない。$はamazon.com、amazon.ca、amazon.com.auでそれぞれ3つの異なる通貨を表す。記号とマーケットプレイスを組み合わせてISO通貨を解決し、パース済みの金額とともに元の文字列も保存する。完全なロードパターンはウェブスクレイピングAPIデータをSQLへ移行するにある。
バイボックスも同様の問題がある。勝利したオファーは配送先地域やその時点でアクティブなセラーによって変わり得るため、どのAPIも「バイボックス」ではなく、バイボックスの「ある視点」を返す。自分がどの視点を得ているかを把握し、すべての観測結果にマーケットプレイスとタイムスタンプを記録する。
候補を自社データで評価する方法
ドキュメント内のサンプルレスポンスは、自社のカタログについては何も証明しない。実際の作業を模したトライアルを実施する。
- 固定サンプルを選ぶ: 自社にとって重要なマーケットプレイスにわたる、実際のASINを数百件、最も重要な商品に重み付けして選ぶ。
- 1週間、スケジュールに従って実行する、本番で使う予定のケイデンスで。
- フィールドの完全性を測定する、フィールドごと、マーケットプレイスごとに。ドイツの商品の8%で価格フィールドが空であるなら、それは実際の発見だ。
- 正確性を抜き取り検査する、返された価格の一部をランダムに選び、同時刻の実際のページと比較する。
- 成功率とレイテンシを記録する、マーケットプレイスごとに、集計値ではなく。あるプロバイダーは米国では優秀でも、他の地域では弱いことがあるからだ。
- 使用可能なレコード1件あたりのコストを計算する、つまり完全で正確、正しく帰属付けされた行のことであり、リクエスト1件あたりのコストではない。
すべての候補を同じサンプル、同じ週、同じケイデンスで実行する。異なる条件下でテストされたプロバイダーを比較することが、購入判断を誤らせる原因であり、これは私たち自身のベンチマークにも適用している原則と同じものだ。
Shifterの位置づけ
Shifter Amazon APIは専用のeコマースAPIである。typeパラメータを持つ単一のエンドポイントが、検索、商品詳細、ベストセラー、本日のセール、カテゴリ、セラープロフィール、セラー商品、セラーフィードバックをカバーし、19のAmazonマーケットプレイスにわたって、デスクトップまたはモバイルの結果を、デフォルトでJSON形式で提供する。
curl "https://ecom.shifter.io/v1?engine=amazon&api_key=YOUR_API_KEY&type=product&product_id=B08C1W5N87&domain=amazon.de"検索レスポンスでは、スポンサード掲載がオーガニック結果とは別のフィールドに保持され、ページネーションはレスポンス内で公開される。Amazon向けの呼び出しはSERP APIプランのクォータを消費するため、両者に対して1つのキープールと1つのプランが存在する。エンドポイントとパラメータはAmazon APIのドキュメントにあり、プランはSERP APIの料金ページにある。
Shifter Web Scraping APIは、構造化エンドポイントがカバーしていないすべて、つまり他のリテーラー、ブランドサイト、そして自分で抽出したい任意のページをカバーする。リクエストに応じてJavaScriptをレンダリングし、抽出ルールを通じてJSONを返し、リクエストごとに国を指定でき、ページネーションを含むフローのためにセッションを保持し、失敗したフェッチを自動的にリトライし、成功したレスポンスに対してのみ課金する。詳細はWeb Scraping APIのページを参照。
Shifterレジデンシャルプロキシは、ブラウザとパーサーを完全に制御したいチーム向けの自己管理オプションである。
作業とツールの対応
| 作業 | 最適な選択 |
|---|---|
| マーケットプレイス全体にわたる固定ASINリストの価格追跡 | 専用のAmazon API |
| 検索順位とシェア・オブ・シェルフの監視 | 専用のAmazon API、スポンサードとオーガニックを分離した状態で |
| Amazonおよび他のリテーラーにわたる競合価格調査 | Amazon APIと汎用スクレイピングAPIの組み合わせ |
| 自社リスティング上のセラー識別 | 専用APIのセラーエンドポイント |
| 構造化エンドポイントが公開していないカスタムフロー | 汎用スクレイピングAPIまたは自己管理プロキシ |
| 社内でスクレイピングエンジニアリングを行う非常に大規模なカタログ | 自己管理プロキシ |
その後の活用方法についてはリアルタイムの競合価格フィードの構築、大規模なMAP遵守の徹底、自社リスティングを乗っ取る第三者セラーの検出で扱っている。
FAQ
競合の価格を監視するために、Amazon自身のAPIを使えますか?
Amazon自身のAPIは、自社アカウントで作業するセラーやアフィリエイト向けに、独自の利用規約の下で構築されている。カタログ全体を監視する目的では、専用のeコマースAPI、汎用のスクレイピングAPI、またはプロキシを使うのが一般的だ。
専用のAmazon APIは、汎用のスクレイピングAPIより常に優れていますか?
対応しているAmazonのサーフェスに関しては、通常はより速く統合でき、保守コストも安い。他のリテーラーも同時に監視する場合や、構造化エンドポイントがカバーしていないページが必要な場合は、汎用のスクレイピングAPIが優位に立つ。
Amazonの価格はどのくらいの頻度で更新すべきですか?
自社のカテゴリが実際にどれだけ速く動くかにケイデンスを合わせる。これはトライアル期間中に測定できる。多くのチームは優先ウォッチリストを1日に数回、その他の多数を1日1回更新している。
Amazon APIを購入する際の最も一般的な間違いは何ですか?
サンプルレスポンスで評価するのではなく、自社のマーケットプレイスにわたる自社のASINで、1週間かけて評価すべきなのに、それをしないことだ。米国以外でのフィールドの完全性は、多くの選択肢が最も差がつく部分だ。
結論
Amazonに最適なウェブスクレイピングAPIというものは単一には存在せず、与えられた作業に対する最適な適合があるだけだ。専用のeコマースAPIは、マーケットプレイス全体にわたって構造化されたAmazonデータを得る最速の手段である。汎用のスクレイピングAPIは、同じパイプラインを他のすべてのリテーラーへ拡張する。自己管理プロキシは、非常に大規模で非常にカスタムな運用に適している。
マーケットプレイスとサーフェスのカバレッジ、オーガニックとスポンサードの分離、出力の安定性、そして成功時のみの課金を基準に選び、契約前に1週間、自社のASINでその選択を検証する。より広い利用例はprice intelligenceのページにある。