ソーシャルデータを収集する際にブロックを避けるべき理由は、たいていのチュートリアルが挙げているものとは違う。ブロックがボリュームを犠牲にするから、ではない。ブロックはランダムではないからだ。
プラットフォームがスロットリングを始めるとき、それは均一なサンプルを間引くわけではない。結果セットの深いページ、ボリュームの多いクエリ、あなたが最も速く収集していた期間を落とす。それらはまさにあなたが気にしている会話と相関している。なぜなら議論の急増はあなたのリクエストレートの急増でもあるからだ。つまり失われるサンプルは重要だった瞬間のサンプルに偏っており、その後計算するセンチメントスコアは、あなたには見えない方向に向かって自信満々に間違ったものになる。
これが持続可能な収集を行うべき本当の理由だ。スループットではない。妥当性だ。
まずAPIから始める
これらすべてに取り組む前に、プラットフォームが公式に何を提供しているかを確認すべきだ。APIが存在し、必要なフィールド、ボリューム、履歴をカバーしているなら、それを使うべきだ。安定しており、許可されており、カバレッジが密かに変わることもなく、エンジニアリングの一大分野をロードマップから取り除いてくれる。
現実的な立場としては、APIは問題の一部しかカバーしない。過去データの深さはしばしば限られており、レート上限は本格的なモニタリングプログラムが必要とする水準を下回ることが多く、最も重要なコミュニティの多くはそもそもAPIを持たない。公開ページからの収集がその残りを埋めることになり、この記事の残りの部分はそこに当てはまる。
クローラーではなく読者のように振る舞う
ブロックされないことの大部分は、人間には生成できないようなトラフィックを発生させないことに尽きる。その手法は地味だが、機能する。
人が現実的に生成しうるペースにリクエストを合わせる。 6時間持続する秒間1リクエスト、ではない。メトロノームのようにではなく、ばらつきを持たせて一日全体に収集を分散させる。
エグジットごとの同時実行数を制限する。 グローバルな同時実行数の上限を小さなプールに不均等に振り分けると、負荷が少数のアドレスに集中する。集計だけでなく、アドレスごとに制限すべきだ。
抵抗の最初の兆候でバックオフする。 チャレンジ、遅い応答、切り詰められた結果セット。即座にリトライしたくなる衝動こそが、緩やかなスロットリングをハードブロックに変えてしまう。ジッター付きの指数バックオフ、そして繰り返しの失敗の後にターゲットへのアクセスを完全に停止するサーキットブレーカーについては、rate limiting and request throttlingで扱っている。
セッションの一貫性を保つ。 4つの異なるアドレスから読まれたページ分割されたスレッドは、現実的な閲覧セッションではない。論理的な作業単位1つの間は、1つのセッションを維持すべきだ。
公開されているものを収集する。 ログインの背後にあるコンテンツは法的にも倫理的にも別の話であり、アカウントベースの収集こそがプログラムが本当に問題を起こす領域だ。公開ページ、公開投稿、公開スレッドを対象にする。
プロキシ層が担う役割
センチメント分析の作業において特に重要な性質が2つある。
第一に、単一アドレスからのリクエストボリュームは、あなたが読者ではないことを示す最も明確なシグナルだということだ。Residential proxiesはそのボリュームを実際のISP割り当てアドレス全体に分散させる。これにより、アドレスごとのレートを妥当な範囲に保ちながら、全体のスループットは有用な水準を維持できる。
第二は地理であり、これはセンチメント分析の作業においては過小評価されがちだ。ソーシャルプラットフォームは地域ごとに異なるコンテンツを提供する。トレンドのトピック、表示される返信、そもそもどの投稿が浮上するかまで違う。単一国の視点から計算されたグローバルなセンチメント数値は、実際にはその国のセンチメントにグローバルというラベルを貼っただけのものだ。あなたの製品に国際的なユーザーがいるなら、収集は彼らの市場から行わなければならない。
Shifterのゲートウェイでは、両方ともp.shifter.io:443に対する認証情報の中に組み込む。
customer-USERNAME-country-jp-sid-topic-4417-ttl-600:PASSWORDcountry-jpが視点を設定し、sid-topic-4417が1つのスレッドとそのページネーションの間、1つのエグジットを保持し、ttl-600がそのアドレスを10分間維持する。sidがなければゲートウェイはリクエストごとにローテーションする。これは独立したクエリには適しているが、連続性が必要な処理には不適切だ。ソーシャル収集についてのより広い視点はsocial media data collectionのページにあり、アカウント側の実践についてはsocial media proxiesにある。
特定のターゲットでアドレスがチャレンジを受け始めた場合の、診断と復旧の手順はwhat to do when residential proxy IPs get bannedにある。
パイプライン、順を追って
collect -> dedupe -> language detect -> filter -> score -> aggregate各段階には、結果を静かに汚染するそれぞれのやり方がある。
スコアリング前に重複排除する。 そうしなければ、同じ発言のリポスト、引用、スクリーンショットが1つのうるさい投稿をトレンドに変えてしまう。固定ルールを使い、コピーは正規のレコードにリンクさせたまま保つべきだ。拡散はボリュームとは別のシグナルだからだ。
スコアリング前に言語を検出する。 英語のセンチメントモデルを多言語混在のテキストに走らせても、派手に失敗するわけではない。理解していないテキストに対して自信ありげな数値を返してくる。複数の市場から収集するようになれば、多言語コーパスは通常のケースになる。
キーワードだけでなく関連性でフィルタリングする。 一般的な単語でもあるブランド名は、あなたとは無関係なテキストを引き込んでしまう。これはクエリ設計の問題であり、下流のどんなモデルも解決してくれない。
カバレッジ指標を添えて集計する。 すべてのセンチメント数値は、同じ期間の収集成功率と共に提示されるべきだ。それによって読者は、意見の変化と、見えていたものの変化とを区別できる。
センチメントスコアリングこそ、誠実なプログラムが誠実であり続けるべき場所
出力を利用する人に対して率直に述べておくべき限界がいくつかある。
皮肉や風刺は依然として信頼性が低く、まさに人が不満を述べる場でこそ過剰に表れる。ドメイン特有の語彙は極性を反転させる。「sick」「insane」「unreal」は一部のコミュニティでは称賛の言葉だ。星評価とレビューテキストはしばしば食い違い、食い違う場合はたいていテキストの方が真実に近い。そして大きな中立クラスは発見ではなく、多くの場合、モデルが解析できなかったテキストに対して何の意見も持っていないことのサインだ。
最も有用な規律は、水準ではなく変動を報告することだ。0.62という絶対的なセンチメントスコアは誰にとっても意味を持たない。同じ方法で計算された、比較可能なカバレッジに基づく先月からの変化には意味がある。これはあらゆる縦断的なウェブパネルに当てはまるのと同じ測定ロジックであり、そのまま借用する価値がある。
個人データと、どこで止めるべきか
ソーシャル投稿は人によって書かれており、その点が価格をスクレイピングする場合とは異なる。
公開投稿を収集し、必要のないものは保存して自制を約束するのではなく、取り込み時点で取り除くべきだ。ユーザー名、プロフィールリンク、テキスト中に現れる連絡先情報は、集計センチメントを計算するのにほとんど必要ない。あなたの出力がトレンドラインであるなら、あなたのストレージは個人のデータベースである必要はない。
各プラットフォームの明記された利用規約を尊重し、ボリュームを適切に保ち、認証の背後にあるコンテンツは対象外として扱う。一般的な枠組みはethical residential proxies for AI data collectionにあり、対象が企業ではなく人である分、ここではより強く当てはまる。
FAQ
Residential proxiesを使えばブロックされなくなりますか?
最も一般的な原因、つまり1つのアドレスや見分けのつくデータセンターの範囲からの集中したボリュームを取り除いてくれる。しかし人間には生成できないリクエストレートを埋め合わせることはできない。ペース配分とバックオフが依然として仕事の大部分を担っている。
センチメント分析には実際どれくらいのデータが必要ですか?
トレンド検出のためには、たいていのチームが想定するより少なくて済む。しかし細分化のためには、想定より多く必要になる。安定した週次トレンドには、ボリュームよりも一貫性が必要だ。市場、製品、トピックごとにセンチメントを分解すると、各セルが意味を持つために必要なサンプル数が掛け算式に増えていく。
製品がグローバルなら、複数の国から収集すべきですか?
そうすべきだ。そして集計する前に、各市場をそれぞれ独自の系列として扱うべきだ。混ぜ合わされたグローバル数値は、実際に動いている市場を隠してしまう。
最もよくある間違いは何ですか?
実際にはカバレッジの変化に過ぎないものを、センチメントの変化として報告してしまうことだ。成功率をスコアと並べて公開すれば、こうした間違いのほとんどを防げる。
結論
持続可能な収集はスループットの好みではなく、サンプリング上の要件だ。ブロックはサンプルを静かな期間に偏らせ、騒がしい期間から遠ざける。これはセンチメントプログラムが測定しようとしていることの正反対だ。
公式APIが存在する場合はそれを使い、読者のようにリクエストのペースを合わせ、セッションの一貫性を保ち、実際にユーザーがいる市場のレジデンシャルアドレス全体にボリュームを分散させ、スコアと並べてカバレッジを公開すべきだ。料金はpricing pageに掲載されている。