レビュー監視は一見レポーティングの問題に見えるが、実態はデータ収集の問題として振る舞う。レビューは公開されており、ページは読みやすい。ところが本格的な収集を始めると、この作業を一筋縄ではいかなくする2つの要因にぶつかる。レビューページの表示内容はリクエスト元によって変わること、そして毎日同じページをリクエストするというトラフィックパターンは、まさにアンチボットシステムが検知するよう調整されているものだということだ。
この記事では、プロキシがこの問題にどう関わるか、何を収集すべきか、そしてスケジュール運用に乗せたレビュー収集パイプラインを安定させ続ける方法について解説する。
プロキシなしでは実際に何が破綻するか
まずローカライゼーションから見ていこう。Googleレビュー、各種アプリストア、Trustpilotの国別ドメイン、そして大手マーケットプレイスはいずれも、リクエスト元の地域によって出力内容を変える。星評価の平均値が異なり、レビューの集合が異なり、翻訳版が表示される地域とされない地域があり、マーケットプレイスでは商品リスト自体がその国に存在しない場合すらある。1つのオフィスIPから監視しているチームは、グローバルな全体像を見ているのではない。1つの国の姿を見て、それをグローバルだと思い込んでいるだけだ。
次にボリュームの問題がある。数百の商品、あるいは数百の店舗を追跡しているブランドは、毎日変わらない固定アドレスから、1日あたり数千ページをリクエストすることになる。これはフィンガープリントそのものだ。反応として最初に起こるのは、たいていハードなブロックではなく、劣化である。応答が遅くなる、インタースティシャルが挟まる、レビューリストが途中で切られる、有効な200を返しながら中身が空のチャレンジページが返される、といった具合だ。これをチェックしないパイプラインは静かにゼロを記録し続け、ダッシュボードには実際には起きていないレビューの枯渇が表示されることになる。
プロキシはこの両方に対処する。ジオターゲティングによってリクエストを、レビューを取得したい市場に位置づけることができ、大規模なレジデンシャルプールにトラフィックを分散させることで、どの1つのアドレスも、サイトが警戒し始める閾値を大きく下回るレベルに保たれる。
どのプロキシタイプがどのターゲットに合うか
一般消費者向けのレビュー面は難しいケースだ。Google、Trustpilot、G2、Capterra、App StoreとPlay Store、Amazon、および各地域のマーケットプレイスは、いずれも成熟したボット管理の背後にある。これらにはレジデンシャルIPが必要になる。なぜなら、これらのアドレスは実在する消費者の接続に属しており、サイトが評価対象とする信頼プロファイルを持っているからだ。これがほとんどのレビュー収集プログラムの大部分を占める。
ISPプロキシが力を発揮するのは、フローに状態が伴う場面だ。店舗を選ぶ、配送先を設定する、あるいは自分が所有する販売者アカウントにログインした後にのみレビューが表示されるような場合、これらのステップを通じて安定したアドレスを保つことは、ローテーションよりも価値がある。ISPアドレスは静的でありながら消費者ルーティングされているという組み合わせが、このシナリオが必要とするものだ。
データセンタープロキシはロングテールにおいてはなお理にかなっている。ニッチな業界のレビューサイト、フォーラム、公開フィードなど、防御が軽いものにはこれが適している。リクエストあたりのコストは低く、信頼面でのペナルティも受けにくい。しかしこれをGoogleレビューに向けて送るのは、チームがお金を無駄にするポイントだ。安いリクエストでもチャレンジページが返ってくるなら、それは決して安くない。
成熟した運用の多くは、1つのタイプを選ぶのではなく、ターゲットごとにルーティングを行う。難易度の高い消費者向けプラットフォームにはレジデンシャル、状態を持つフローにはスティッキー、残りの簡単な部分には最も安いものを使う。スクレイピング時のブロック回避についての記事では、同じ問題のリクエストレベルの側面を扱っている。
ローテーション、セッション、ペーシング
レビュー収集の大半は単純なページ読み取りだ。URLをリクエストし、レビューをパースし、次に進む。リクエストごとにローテーションするのが正しいデフォルトであり、これはローテーティングプロキシのレジデンシャルエンドポイントが、こちら側で何も作業しなくても行ってくれることだ。
スティッキーセッションが重要になるのは例外的なケースだ。レビューリストのページネーションは、サイトがセッションに対して発行するカーソルに依存していることが多く、位置情報によって表示が制限されるレビューは、サイトがそのセッションに対して保存した選択に依存する。フローの途中でIPを切り替えるとその状態がリセットされ、1ページ目が再び表示されるか、空の結果が返ってくることになる。フローの長さの分だけセッションを保持し、その後で破棄すること。
ペーシングはチームが過小投資しがちな部分だ。レビュー数はゆっくりと変化する。基礎となるデータが週単位でしか動かないのに、商品ページを毎時間叩く価値はなく、そうすることのコストは、本当に重要なページでのブロック率上昇として跳ね返ってくる。クロール頻度は、そのターゲットでレビューが蓄積する速さに合わせるべきだ。高ボリュームなマーケットプレイスの商品ページやアプリストアには毎日、ほとんどのB2Bソフトウェアディレクトリには週次、そしてローンチやキャンペーン時など急増が予想されるタイミングにはイベント駆動で対応する。
何を収集するかを選ぶ
すべてを取得しようとするのが本能的な発想だ。しかし、より有用なパイプラインは、意思決定を支える項目だけを収集し、残りは捨てる。
商品ごと、店舗ごと、市場ごとの評価とレビュー数は、トレンドラインを提供してくれる。レビュー本文、日付、言語は内容そのものを提供し、言語情報は苦情を読める言語のチームへ振り分けることを可能にする。認証済み購入フラグとレビュアー履歴は、本物のシグナルとキャンペーンによるものを区別する材料になる。販売者やリスト自体の識別情報はマーケットプレイスでは重要だ。同じ商品を偽造業者が販売している場合、そのレビューは知っておく価値があるが、自社の平均には混ぜたくないものだからだ。
抵抗すべき点が2つある。分析に必要以上の個人データを保存することは、何のメリットもないままレビューパイプラインをデータ保護上の問題に変えてしまう。レビュアー名がその見返りに値することはめったにない。そしてレビュー本文は他人が書いたものであるため、分析のために集約することと、サイトコンテンツとして再公開することは全く別の話である。
レビューへの関心が分析的なものではなく評判に関するものであるチームにとっては、ブランド保護とソーシャルリスニングが、同じ苦情が最初に現れることの多い隣接領域をカバーしている。
パイプラインの構築
仕組み自体はありふれたものだ。スケジューラーが市場別のURLワークリストを駆動し、各リクエストはその行に対応する国が設定されたプロキシエンドポイント経由で送信され、レスポンスはパーサーへ渡され、パース済みのレビューはプラットフォーム、商品、市場をキーとしてストレージに格納され、同じレビューが二重にカウントされることはない。
しかし、これが本番環境で実際に生き残れるかどうかを左右するのは、もっと目立たない部分だ。
ステータスコードを鵜呑みにせず、レスポンスを検証すること。チャレンジページは200を返しながら、パースするとレビュー0件になるためだ。昨日は400件のレビューがあったページで突然レビューが見つからなくなったランは、ビジネス上の出来事ではなく収集の失敗であり、パイプラインはそのことを明示すべきだ。
安価に取得すること。レビューページには画像、フォント、アナリティクススクリプトが含まれているが、これらはパースには何ら貢献しない。これらをブロックすることで帯域幅を大幅に削減でき、帯域幅課金のプランでは、月間数GBで済むか、議論になるような請求額になるかの分かれ目になる。
必要な場合にのみレンダリングすること。レビューセクションの一部はサーバーサイドでレンダリングされており、単純なHTTPリクエストで十分な場合がある。それ以外はヘッドレスブラウザを必要とし、帯域幅・時間ともに桁違いにコストがかかる。すべてをデフォルトでブラウザに任せるのではなく、ターゲットごとに確認すること。
生のレスポンスを短期間保持すること。プラットフォームがマークアップを変更してパーサーが壊れることは必ず起こるが、その際に前日のHTMLがあれば、修正は10分の作業で済み、再クロールする必要がなくなる。
こうしたすべてを維持する意欲がチームにない場合、スクレイピングAPIを使えば構造化された出力がそのまま返ってくる。ローテーション、レンダリング、リトライロジックはリクエストあたりより高い価格で吸収される。そのトレードオフはお金とエンジニアリング時間の間のものであり、1日数千ページを回すレビュープログラムにとっては、そのプログラムが小規模なうちに限って公平な取引と言える。
コストはどれくらいか
レビュー監視は比較的安価なプロキシワークロードの1つだ。アセットのダウンロードをやめればページは小さくなり、クロール頻度も低いためだ。
$1.00/GBから始まるレジデンシャル料金では、数千の商品ページと複数の市場にわたる日次スイープは、通常、1桁台の月間帯域幅数値に収まる。これを動かす変数は、ヘッドレスブラウジング、画像読み込み、過度に頻繁なクロールの順であり、いずれもプロキシ料金の問題というよりエンジニアリング上の判断の問題だ。これはプロキシ請求額を責める前に知っておくべき有用な事実である。
Shifterのこの分野での強みはごく標準的なものだ。195以上の国にまたがる2億500万以上のレジデンシャルIP、市区町村レベルおよびASNターゲティング、同一アカウントでのローテーティングおよびスティッキーセッション、そして同時接続数無制限により、市場全体のスイープを逐次ではなく並行して実行できる。ネットワーク挙動に関する独立した数値は、ここで主張するのではなくベンチマークページに掲載している。
インフラではない部分
収集は簡単な方の半分にすぎない。レビューを監視する価値があるのは、その結果として何かが実際に起こる場合のみであり、成果を上げているプログラムは、否定的なレビューを誰も開かないダッシュボードにではなく、その製品を担当するチームへ振り分けている。
つまり、何がアクションの引き金になるかをあらかじめ決めておく必要がある。特定の市場で評価がある閾値を下回ること、あるキーワードに言及するレビューの急増、見覚えのない販売者の下にリストが出現すること、自社が守っているカテゴリーで競合の評価が上回ること、などだ。プロキシ層が存在する目的は、これらのシグナルが自社が販売するすべての市場にわたって完全かつ最新であることを保証するためだ。それに対して何をするかが、実際の仕事である。
次に読む: プロキシを使ったローカルビジネスデータのスクレイピング方法。同じ収集問題の、地域レベルのバージョンを扱っている。