ボットの除外方法を調べていて、mitchellkrogza/apache-ultimate-bad-bot-blocker を見つけました。
内容を確認したところ、Google アナリティクスのフィルター定義(正確にはセグメント定義)がありました。
ボットのブロックをこの定義で実施できそうでしたので、実際に実施してみました。
結果を以下に記載します。

Google Analytics 上でのボット除外について

Google アナリティクス 上で、何故ボットが邪魔になるのか?

Google Analytics では以下の観点で邪魔になるのかと思います。

  • 計測結果が汚される。
    ボットのアクセス都合で、Page アクセス数が急増、施策の効果が測定しづらくなったりするのかと思います。

  • リファラースパム
    リファラーでアクセス可能な URL が記録され、気になってアクセスすると良くないソフトウェアがついてくるやつです。

Google アナリティクス 上の 一般的な ボット除外方法 について

Google Analytics での ボットの除外方法について、一般的に実施されている方法を記載します。

Google アナリティクス 以外でのボット除外方法について

先日、ボット、クローラのアクセスを除外する方法を調べてみた | Monotalk を書きました。
似たような内容ですので、よろしければこちらもご確認ください。

  • ボット除外の発動箇所
    通信経路上、以下のポイントでボットの除外ができます。
    Google アナリティクスのタグ発行の前にボットのアクセスを除去する方式になります。

    1. プロキシサーバ
      ベンダーの製品等はこのポイントでの除去が多いように思います。

    2. HTTP サーバ
      mitchellkrogza/apache-ultimate-bad-bot-blocker の Apache の設定ファイルでボットを除去する場合はこのポイントでの除去になります。

    3. robots.txt
      robots.txt に Disalow 定義を行うことで除外が可能です。ただ、悪質な ボットは おそらく無視してくるのであまり意味がないのかもしれません。
      アクセスを認めているボットに、細かい指示を出すのに使うのが良さそうに思います。

    4. GTM
      GTMで、Google Analytics のタグの発行条件を指定することでもボットのアクセスを除外できるように思いました。
      以下、コミニティの QA で話題に挙がっているような方法をとるのかと思います。
      GTMでの発火制御について - Google 広告主コミュニティ

  • 通信経路上での制御では除外できないアクセスについて
    ゴーストリファラ というスパムは、Google Analytics の Measurement Protocol を使っています。
    このケースはサイトを訪れず直接 Google Analytics にリクエスト送付を行なっているため、通信経路上で制御していたとしてもそれをすり抜けて記録されます。

  • AMPページでのアクセス
    AMPページは、自サイト外のCacheサーバー上でのページの配信になります。
    基本的な対策は実施されていると思いますが、自サイトでの設定とは異なる可能性があります。

Google アナリティクス 上で ボットを除去するか、それ以外のポイントで除去するかの判断

以下が言えるかと思います。

  • Google アナリティクス 上でのボットの除去は、ゴーストリファラ が存在するので実施したほうがいい。

  • HTTP サーバー等での除去は、ボットによるサーバーリソースの消費が無視できないほど大きい場合は実施したほうがいい。

Google Analytics の セグメントとしてボットを除外する

使用するリソースについて

_google_analytics_ghost_spam at master を元に、Google Analytics のセグメントを使ってボットを除外します。

フィルタとセグメントの違いとしては以下の点があります。

  • セグメントは記録後のデータに適用される。
  • フィルタは記録前のデータに適用される。
  • フィルタでも、セグメントでもホスト名を条件にできるが、フィルタは最大文字列の制限が厳しい。

_google_analytics_ghost_spam at master の文字列は、セグメントに適用する前提での文字列の長さになっているため、フィルタに適用すると、途中で切り捨てられます。

セグメントは<wbr>記録後の<wbr>データに<wbr>適用される。<wbr> ので後々でも適用できる。
そもそも、HTTPサーバー等で、同一文字列の適用を想定していそうで、セグメントで引っかかるアクセスの総量が少ない。
という判断から、セグメントでの提供なのだと思いました。

セグメントを作成する

以下の手順でセグメントを作成しました。

  1. 管理メニュー 、セグメントを適用したい VIEW を選択。セグメントをクリック。
    管理メニュー、<wbr>セグメント

  2. 新しいセグメントをクリック。
    新しい<wbr>セグメントを<wbr>クリック

  3. 条件に ホスト名を選択。google-exclude-01.txt 等 のテキストファイルの内容をコピー、ペースト。
    Ghost1

これをtxtファイルの数分実施します。

使い方

ページ解析時に作成したセグメントを追加します。
セグメントであれば過去のアクセスにも適用できるため、どれくらい ゴーストリファラ のアクセス があったのかが確認できます。
毎回セグメントを適用するのはたいへんなので、カスタムレポートを作成しておいたほうがいいかと思います。
また、アクセス自体が除外されるわけではないので、チェック用にセグメントを適用しておいて、アクセスを検知した場合、必要であればフィルタで除外設定をするのかと思います。

ちなみに、フィルタにはセグメントと同等の長さの文字列は設定できず、分割して設定する必要があります。
google-exclude-01.txt の文字列を分割、API で一括設定するのがよいのかと思います。

参考

以下、記事作成時に参考にしました。
* ゴーストリファラ対策～リファラスパムとつきあう方法～ | ウェブの実
* 参照元スパム対策をしてわかったこと | ウェブの実
* 急増するGAのリファラースパムを撃退！ スパム業者の手口とは？ | ＜特集＞ユニバーサルアナリティクスの新しい仕組み「Measurement Protocol」とは？ | Web担当者Forum

以上です。

コメント

カテゴリー

最近の投稿