「レビュー分析」の成果物はたいてい一段落の文章です。買い手は主にバッテリー、梱包、配送について不満を述べている、といったもの。
もっともらしく読めますが、誰もそれを使って動けません。この三つは担当者も費用もまるで違うのに、要約が一文に押し潰してしまったからです。
役に立つレビュー分析は、代わりに三つに分けた結論を出します。
三つの結論、三つの費用
| 分類 | 見分け方 | 誰が直すか | 費用 |
|---|---|---|---|
| 商品を直す | 実物が本来の機能に届いていない | サプライチェーン / 開発 | 高く、期間も長い |
| リスティングを直す | 実物に問題は無く、期待がずれていた | 運用担当、当日でも可能 | 低い |
| 何も直さない | 個別事例、配送、商品と無関係 | 誰も | ゼロ |
二番目が最も誤読されます。
「写真と違う」「思ったより小さい」「電池付きだと思った」というレビューが指しているのは商品ではなく、説明と実物の差です。ここで商品を変えても解決せず費用だけかかります。メイン画像、サイズ表記、箇条書きの一行を直せば済みます。
二番目を一番目として処理することが、レビュー分析で最も高くつく間違いです。問題が一枚の写真だったのに、金型変更に数か月かけることになります。
判定は単純です。「事前に知っていたら、それでも買ったか」と問う。
- 買う。ただし事前に知る必要があった → 二番目、説明を直す
- 買わない → 一番目、商品を直す
内容を読む前に基準を正す
一件も読み始める前に、そもそもどのレビューを分析に入れるかを確定させます。
レビューは verified、vine、free、experience の四つの出どころ標識を持ちます。商品の判断をするときは、基準を実購入のレビューだけに置くべきです。無償で受け取った人には「その価格に見合うか」という判断が欠けており、二番目の分類はまさにそこに依存します。
各フィールドの意味と、混ぜて平均すると使い物にならない理由はAmazon レビューの四つの出どころにあります。
上から順に読まず、四つの軸で切る
最初から最後まで読むのが最も非効率です。四つの軸が情報を集約します。
一、星で切る。 stars は配列を取るので、1〜2 星を引けばそれが不具合一覧です。最も具体的な記述が欲しければ 3 星の層を。5 星は一行の賛辞、1 星は感情を伴いがちで、3 星が最も明瞭に書かれます。
二、バリエーションで切る。 skus でグループ化します。低評価が特定のバリエーションに集中していれば、商品ライン全体ではなくその SKU の問題である公算が高い。親ページは全バリエーションを合算するので、分けないと見えません。
三、影響力で切る。 likes で並べ替えます。高評価のレビューは上位に並び、はるかに多くの買い手に読まれます。47 票が付いた画像付きの低評価は、0 票のテキストだけのものより転換への影響がはるかに大きい。 上位 20 件を先に処理するほうが、200 件を読むより買い手の見ているものに近づきます。
四、時間で切る。 date で低評価の分布を見ます。最も飛ばされやすい軸ですが、他のどの軸でも答えられないことに答えます。
時間軸に現れる信号：ロット問題
ある種類の不満がある時点以降に集中して現れ、それ以前にはほとんど無い場合、それはおそらく設計の問題ではなくロットの問題です。仕入先が材料を変えた、ラインの班が替わった、梱包の仕様が動いた。
この区別は重要です。対応がまったく違うからです。設計の問題は設計をやり直す必要があり、ロットの問題はその期間の製造記録を当たればよい。後者のほうがたいてい早く解決し、商品そのものに触れずに済みます。
逆に、同じ不満が発売初月から一様に存在するなら、それは設計由来であり、ロットを追っても解決しません。
ですからレビュー分析表にはレビュー日の列が要ります。 しかも取得日とは分けて。Amazon レビューを表に書き出して分析するの表が二つの日付を別の列にしているのはこのためです。
レビュー取得 APIASIN 単位のページング取得と星での絞り込み。出どころの標識、バリエーション SKU、参考になった数、日付、メディアの有無を返します一件のレビューより再現率
低評価が一件あっても何も言えません。同じ問題を十人が独立に述べて初めて結論になります。
記録するときは二つの数を残してください。その問題が何回現れたか、そして分析済みレビューに占める割合。「バッテリーについて指摘があった」とだけ書けば、三か月後にそれが 1 件だったか 30 件だったか誰にも分かりません。
実務的な閾値を一つ。再現率がおおむね 5% を下回るうちは、商品に手を入れないでください。 個別事例か使い方の違いである可能性が高く、変更しても低評価率が下がるとは限らない一方、費用は確実に発生します。
競合のレビューの使い方
同じ API は競合の ASIN にも使えます。そして競合の低評価は自社のものより価値があります。買い手がすでに言葉にしていて、相手がまだ満たしていない需要だからです。
進め方は、相手の 1〜2 星を取り、上の四軸で切り、一番目の分類の中で繰り返し現れる項目を探すこと。自社の商品にたまたまその問題が無ければ、それはそのまま箇条書きに書ける差別化点になります。
境界を一つ。これは公開レビューを読む行為であって、レビューに介入する行為ではありません。 本記事はレビューを操作する手法を一切扱いません。
できない三つ
真偽の判定はできません。 API が返すのはプラットフォームが公開している出どころであって、真正性の判定ではありません。
分類の代行はできません。 どのレビューを数えるか、どれが影響力を持つかはフィールドが示しますが、「これらの不満が同じ一件か」は人の確認が要ります。モデルに一次分類を任せてもよいのですが、人が検証し、出力は事実の列ではなく判断の列に入れます。
レビューが無ければ結論も出ません。 新商品でレビューが少ないうちは標本が足りません。そのときは自社より競合のレビューを読むほうが有用です。
よくある質問
何件分析すれば十分ですか。 再現率が安定するまでです。たいてい 50〜100 件を過ぎると主要な問題の順位は動かなくなります。それ以上はロングテールの網羅性が上がるだけです。
低評価に返信すべきですか。 それは運用側の施策であって分析ではありません。分析の成果物は「何を変えるか」で、返信は別件です。同じ表に混ぜないでください。
競合のレビューを要件定義として使えますか。 そのままは使えません。需要の手がかりであって、自社の費用と供給体制の判断を通す必要があります。相手が解決していないのは、解決に値しないからということもあります。
モデルで自動分類できますか。 できますし、最も向く工程です。ただし要約ではなく「商品 / リスティング / 何もしない」の三分類を出力させてください。要約こそ、この記事の冒頭で挙げた使えない成果物です。