UC-FEED-003Data FeedsLv3

Amazon 商品・レビュー・セラー収集

商品・レビュー・セラー・検索結果を構造化収集し、EC 分析に使う。

Amazon Scraper API

KPI 例

ASIN 数
更新遅延
レビュー欠損率

Amazon を対象に価格、商品属性、レビュー、セラー情報、検索結果を自前で取り続けると、取得そのものよりも構造変化への追従が重くなります。このユースケースでは、Amazon Scraper API を使って構造化データを取得し、EC 分析や競合監視に必要なテーブルを早く作ることを目的にします。

誰の課題か

価格監視、競合比較、レビュー分析を行う EC チーム
商品カタログとレビューを同じパイプラインに載せたいデータエンジニア
Amazon の HTML 解析ではなく、分析可能な構造化データから始めたいアナリスト

ポイントは、何でも取ることではなく「商品」「レビュー」「セラー」「検索結果」のどれを業務に使うかを先に決めることです。必要な粒度が決まっていれば、後段の保存設計も安定します。

推奨製品セット

製品	役割	このユースケースでの位置づけ
Amazon Scraper API	Amazon 向け既製抽出	商品、レビュー、セラー、検索結果を構造化取得する
API Access	認証	サーバーやバッチから Bearer 認証で呼ぶ
Data Feeds	継続供給	定期取得に移行したい場合の選択肢

まずは Amazon Scraper API で単発取得を確認し、対象フィールドが足りるか見ます。
毎日または定期的に流し込みたい場合だけ Data Feeds まで拡張します。

最小実装イメージ

このリポジトリの Step 4 と同じ流れで、まず検索ジョブを作成し、返ってきた snapshot_id を後で結果取得に使います。

curl -X POST "https://api.brightdata.com/v1/scrapers/amazon/search" \
  -H "Authorization: Bearer $BRIGHTDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "keyword": "wireless headphones",
    "max_results": 100,
    "region": "us",
    "output": "json"
  }'

Python 側では snapshot_id を保存してから結果を取りにいくと、非同期ジョブでも扱いやすくなります。

import os
import requests
 
API_KEY = os.getenv("BRIGHTDATA_API_KEY")
SNAPSHOT_ID = os.getenv("BRIGHTDATA_SNAPSHOT_ID")
 
resp = requests.get(
    f"https://api.brightdata.com/v1/snapshots/{SNAPSHOT_ID}/results",
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()
items = resp.json()
print(type(items))

keyword で始めると、ASIN 固定よりも PoC の初動が速くなります。
本番化するときは、どのジョブがどの検索条件に対応していたかを必ず記録します。

運用ポイント

価格監視とレビュー分析では更新頻度が異なります。1 つのバッチにまとめず、用途ごとにジョブを分けたほうが管理しやすくなります。
snapshot_id を永続化しないまま処理すると、再取得時にどの結果を見ているか分からなくなります。
API キーは USER か OPS を使い、ADMIN キーを分析ジョブに埋め込まないようにします。
検索結果、商品詳細、レビューはスキーマが別なので、DWH でも別テーブルで持つ前提にしたほうが後続分析が楽です。
公開情報であっても、社内利用ルールと対象サイトの扱い方は事前に確認してから運用に載せます。

誰の課題か

推奨製品セット

最小実装イメージ

運用ポイント

関連リンク