レビューを分析のために書き出すとき、多くの人はページを選択してコピーし、Excel に貼ります。
遅さは副次的な問題です。本当の問題は、そうして作った表には判断に必要な列が無いことです。タイトル、本文、星は手に入りますが、そのレビューが実購入かどうか、どのバリエーションのものか、何人が参考になったと押したかが落ちます。この三つこそ、そのレビューを結論に入れてよいかを決めるものです。
21 列を四つの組に
第一組、素性（4 列）。 サイト、ASIN、取得日、レビュー日。
取得日とレビュー日は分けてください。レビュー日はその声がどの時期のものかを決め、取得日はこの表がいつ古くなるかを決めます。片方しか残さないと、二か月後にまだ使える表か判断できません。
第二組、レビュー本体（4 列）。 星、レビュータイトル、内容抜粋、バリエーション SKU。
バリエーション SKU は手作りの表にたいてい無い列です。API の skus に対応し、そのレビューがどのバリエーションに付いているかを示します。親リスティングは全バリエーションのレビューをまとめて表示するからです。
第三組、出どころと影響力（8 列）。 購入確認、Vine、無償提供、先行体験、画像あり、動画あり、参考になった数、投稿者ラベル。
前半四つは verified、vine、free、experience の真偽値に対応し、そのレビューを基準に含めてよいかを決めます。後半四つは実際の影響力を決めます。47 票が付いた画像付きの低評価と 0 票のテキストだけの低評価は別物です。四つの出どころフィールドの意味はAmazon レビューの四つの出どころにあります。
第四組、あなたの判断（5 列）。 基準に算入、問題分類、該当工程、対応可能、備考。
この組は API が返さないので手で埋めます。だからこそ前の三組と物理的に分けます。観察と結論を同じ列に混ぜることは、推測が発見として世に出る典型的な経路です。
各列に対応する API フィールド
表の 3 行目がフィールド対応行で、ファイル内に直接書かれています。
| 列 | API フィールド |
|---|---|
| レビュー日 | date（タイムスタンプ） |
| 星 | star |
| レビュータイトル | title |
| 内容抜粋 | content |
| バリエーション SKU | skus |
| 購入確認 | verified |
| Vine | vine |
| 無償提供 | free |
| 先行体験 | experience |
| 画像あり / 動画あり | image / video |
| 参考になった数 | likes |
| 投稿者ラベル | authorLabels |
手で埋めるときもこの順で埋めれば、API に切り替えても列は動きません。 それがこの表の設計目的です。手作業版と API 版は同じ表です。
書き出し時の三つの落とし穴
一、配列フィールドはそのままセルに入れられません。
skus、images、videos、authorLabels はいずれも配列で返ります。そのままセルに入れると角括弧付きのテキストになり、並べ替えも絞り込みもできません。先頭の値だけ取るか区切り文字で連結するか、どちらでもよいのですが表全体で統一してください。カンマとセミコロンを混ぜると、CSV ではカンマが列をずらします。
二、date は日付文字列ではなくタイムスタンプです。
ミリ秒単位の値が返ります（ドキュメントの例は 1772380800000）。そのまま貼ると数字の羅列になり、日付で並べ替えると誤った順序になります。分析時ではなく書き出し時に YYYY-MM-DD へ変換してください。
三、真偽値は表記を一つに。
出どころの四フィールドは真偽値を返します。表では TRUE/FALSE か「はい / いいえ」のどちらかに統一し、混ぜないでください。混ざると「購入確認済みかつ Vine でない」を一つの絞り込みで選べなくなります。それは基準星評価を出す最初の一歩です。
ページングと星の絞り込み
API は ASIN 単位でページングし、stars パラメータが星の配列を受け取ります。
問題分析に全件は要りません。1〜2 星だけ取れば不具合の一覧になります。最も具体的な記述が欲しければ 3 星の層を取ります。
ページングで注意すべき点が一つ。レビューは増え続けます。 今日の 5 ページ目と来週の 5 ページ目が同じ内容とは限りません。ですから取得日の列は飾りではなく、その一群のデータの版番号です。
レビュー取得 APIASIN 単位のページング取得と星での絞り込み。リクエストパラメータと返却フィールドの全表はドキュメントにあります手作業の表で足りなくなるとき
一つの ASIN について 50 件を埋めるのに、おおよそ 30〜40 分かかります。
合わなくなる合図ははっきりしています。
- 見る ASIN が一つではない。 競合 5 件 × 50 件で半日以上
- 定期的に見直す。 レビューは増え続けるので、先月の表は今日をもう表していない
- バリエーション別に集計する。
skusで手作業の仕分けは一度ならよくても、毎月は無理
そこまで来たら定時ジョブにする頃合いです。表のデータを結論に変える手順はAmazon レビュー分析の進め方にあります。列は変える必要がありません。対応行にすでに API のフィールド名が書かれています。
よくある質問
一度の呼び出しで全件書き出せますか。 ページ単位で返るので、ページ送りは自分の側のループになります。ASIN が多いと呼び出し量に効くので先に見積もってください。
書き出した件数がページ表示より少ないのはなぜですか。
まず ASIN の階層を確認してください。親ページは全バリエーションをまとめており、照会したのは単一の子かもしれません。skus 列で突き合わせます。
表にレビュー全文を残すべきですか。 抜粋にしてください。全文は表を極端に読みにくくしますし、判断はたいてい最初の二文で足ります。原文が要るときはレビュー日と星で引き戻します。
問題分類はモデルに任せられますか。
任せられますし、この表でモデルに向くのはまさにその列です。ただし出力は「問題分類」列、つまり判断の組に入れてください。content のような事実の列とは分けておく必要があります。