トラフィックデータ内のクローラーの検出とフラグ付けの改善

管理ダッシュボードは、おそらくクローラーのトラフィック(実在のブラウザのJavaScriptを使用するが、人間の訪問者ではない自動ボットやスクレイパー)を識別できるようになり、それらのページビューを本物のトラフィック数値から分離できます。

本トピックでは、このトラフィックの識別にどのように取り組んだか、そしてこの機能を今日からどのように有効にできるかについて共有します。

:microscope: 変更点

Discourse は以前から、標準的なボットユーザーエージェント(例:Googlebot)で自己識別する Crawlers を、サイトトラフィックデータの別のカテゴリにフィルタリングしてきました。しかし、最新の自動トラフィックはより巧妙です。完全なブラウザを実行し、JavaScript を実行し、まるで本物の訪問であるかのようにページビューデータに混在します。管理者は、Anonymous(匿名)のページビューにおけるトラフィックの急増が実際にはスクレイパーによるものであることが判明したり、AI ボットによって訪問者数が水増しされていたりすることを見ていましたが、それらと真の匿名(つまりログインしていない)人間トラフィックとの区別をつける手段がありませんでした。

今回のアップデートでは、サイトトラフィックデータに Likely Crawlers(おそらくクローラー)というカテゴリが追加されました。改良されたクローラー検出が有効になると、私たちのヒューリスティック(経験則)によりおそらく自動化されたものとしてフラグが立てられたページビューが別途表示されるため、人間トラフィックの数値がより正確になります。

検出の仕組み

システムは、行動シグナルのセットを使用して、各ブラウザのページビューにスコアを付けます:

  • Automation user agent(自動化ユーザーエージェント) — ユーザーエージェントがヘッドレスブラウザや自動化ツール(HeadlessChrome、Playwright、Puppeteer、Selenium、PhantomJS、jsdom)を明示的に示している
  • Verified crawler ASN(検証済みクローラーASN) — IPアドレスの自律システム番号(ASN)が既知のクローラーネットワーク(Baidu、Ahrefs、Yandex、Internet Archive など)である
  • Datacenter ASN(データセンターASN) — IPアドレスが主要なクラウドプロバイダーやホスティングプロバイダーのアドレス空間内にある
  • Velocity(速度) — IPアドレスとユーザーエージェントの組み合わせが、1時間あたり異常に多くのページビューを生成している
  • Rapid navigation(高速ナビゲーション) — ページビュー間の中央値の間隔が5秒未満である
  • Session churn(セッションの入れ替わり) — 同じIPアドレスとユーザーエージェントから、短いセッション(主に1ページずつ)が多数発生している
  • Missing engagement(エンゲージメントの欠如) — セッションとその前後のセッションにおいて、人間らしいインタラクション(マウス移動、キー入力、スクロール)が記録されていない
  • Bad referrer ratio(リファラー比率の悪化) — ほとんどのページビューがリファラーなし、または外部のリファラー付きで到着しており、サイト内でのナビゲーションではなく、URLへの直接アクセスを示唆している
  • Single direct request(単一の直接リクエスト) — リファラーのない単一の無反応なページビュー。URLにロケールパラメータが含まれている場合はスコアが高くなる
  • Rapid IP rotation(高速IPローテーション) — 1つのセッション内で複数のIPアドレスが使用され、人間が操作するよりも速く切り替わっている
  • Stale Chromium(古いChromium) — エンゲージメントシグナルがない古いバージョンのChrome

複数のシグナルからのスコアは累積されます。ページビューが上記のシグナルを一定量持っている場合、それを likely crawler(おそらくクローラー)として分類します。

:gear: コミュニティで改良されたクローラー検出を有効にする方法

現時点では、これは実験的な変更とされています。 検出ヒューリスティックの調整を続けており、フィードバックを歓迎しています。

これを有効にするには、管理エリアの Upcoming changes(今後の変更)ページに移動し、Improved crawler detection(改良されたクローラー検出)項目を探してください。Enabled for…(有効にする対象…)フィールドを更新して、サイトをオプトインしてください。

有効にすると、管理ダッシュボードのサイトトラフィックセクションに、おそらくクローラーが別のカテゴリとして表示されます。

:warning: 重要な注意点:

  • これは完璧な科学ではなく、私たちは時間をかけてヒューリスティックを洗練させていきます。ただし、これらの計算を更新しても、過去のデータへのバックフィル(遡及適用)は行いません。
  • ページビューを「おそらくクローラー」と分類しても、リクエストを拒否したり、レート制限を適用したりするわけではありません。
  • 「おそらくクローラー」のページビューは、リファラー、国、その他のトラフィック内訳から除外されます。これは、現在既知のクローラーが処理されているのと同じ方法です。

:mega: 皆さんの意見は?

フィードバックをお待ちしています。特に、異常なトラフィックパターンや説明のつかない急増に気づいたコミュニティからの声を求めています。あなたのサイトにとって数値は正しく見えますか?実在のユーザーのように見える訪問がフラグされているものはありますか?本トピックで、あなたが確認していることを共有してください。

「いいね!」 20

いいですね。これらのシグナルについて、ログイン済みユーザーも対象になりますか?

「いいね!」 1

おそらく likely crawler は、毎月のページビュー制限にカウントされますか? :slightly_smiling_face:

「いいね!」 1

モデルを使用しながら何かを貼り付けた際、そのURLを編集し忘れていました。その結果、建設中のフォーラムで35,000%という急増が発生しました。

今後は、私が作業している内容への実際の参照をクリーンアップするために、小さなローカルモデルをインストールするという未処理タスクが残っています。

このオプションを第二のフィルターとして活用できるのは素晴らしいです。作成してくださってありがとうございます。

良いご質問ですね。まだ決定していませんが、クローラー検出モデルの微調整が必要になると予想しており、これはオプションの機能であるため、ページビュー上限にどのような影響があるのか(あるいは影響があるのか)は現時点ではわかりません。

社内でこの件について検討し、後ほどお知らせいたします!

「いいね!」 3

お取り組みありがとうございます。検出アルゴリズムに満足が得られた時点で、それらに対してアクションを実行する機能をロードマップに追加する予定はありますか?

「いいね!」 2

特定したユーザーエージェントの一覧、あるいはボット/クローラーと判断される可能性が高いユーザーエージェントの一覧が取得できれば、非常に助かります。

これにより、それらをブロック対象またはレート制限対象のグループに追加できます。

「いいね!」 2

はい、ログインユーザーによる自動化も検出するようにしています。Metaでは、信頼レベル0の「ユーザー」がサイトをスキャンしているのを数件発見しました。

「いいね!」 1

課題は、「クローラーの可能性が高い」とされるものの多くが、正当なユーザーエージェントを使用しているという点です。ブラウザのバージョンがかなり古いように見えることもありますが、それだけではボットと判断する十分なシグナルとは言えません。そのため、私たちは多くのメトリクスを収集し、それらを組み合わせることで可能性を評価しています。

クローラーが Bingbot や Googlebot のようなユーザーエージェントで正直に自己紹介した場合、それは直接「クローラー」のカテゴリに分類されます。

「いいね!」 1

確かに。チームディスカースがバックエンドから取得できる統計情報によると、アクセスパターンが一時的に増加する、より obscure なユーザーエージェント(ユーザーエージェントが特定しにくいもの)が対象となることが多く、ユーザーに影響を与えることなくリストからいくつか除外することができました。

これは厳密な科学ではありません。特定の地理的場所(ジオ)にマッピングできれば、それらの管理においてより高い解像度が得られる可能性があります。

「いいね!」 2