GA4に自分のアクセスはどれくらい混ざるか―内部トラフィックの確認と除外方法

Google Analyticsを入れてから、記事公開後に自分でサイトを確認する回数が増えた。

PCで開く。スマートフォンでも見る。修正したら再読み込みする。こうした確認も、そのままではGA4へ入る。

ゆまラボでGA4を導入したときも、bringain.comを自分で開いたあとにリアルタイムレポートを確認し、過去30分のアクティブユーザーが2、表示回数が3になった。ページパスには/と/privacy/が出ていた。導入時の経緯は第4回 Google Analyticsをゆまラボへ導入する―GA4を設定してリアルタイム計測まで確認に残している。

この時点の目的は「データが届くか」の確認なので問題ない。ただ、今後GA4のデータを人気記事表示にも使うなら、自分のアクセスを含め続けるかは別に考えた方がよい。

過去データから自分の割合を正確に出すのは難しい#

知りたかったのは、自分のアクセスが現在の数字へどれくらい混ざっているか。

GA4の通常レポートには、過去のイベントへ後から「これは自分」と印を付ける仕組みはない。Googleの公式説明では、GA4はIPアドレスを位置情報などの処理に利用するが、未処理のIPアドレスをログへ保存しない。

そのため、すでに集計されたデータをIPでさかのぼり、

この10ページビューは自分
この3ユーザーは外部の読者

のように正確に分離することはできない。

今回の導入確認では、自分でサイトを開いた直後にリアルタイムへ数字が入った。少なくとも自分の確認操作が計測対象になり得ることは分かっている。ただし、当時の2ユーザー / 3表示のうち何件が自分だったかは確定できない。

アクセスが少ない時期ほど影響は大きい。公開後に数回確認するだけでも、ページビュー、ユーザー、エンゲージメントへ混ざる。ゆまラボでは将来、直近30日のアクセスから人気記事を自動表示する予定なので、自分が何度も確認した記事が上位へ入りやすくなるのは避けたい。人気記事を自動表示するためにGoogle Analyticsを使うことにした記事にもつながる話になる。

GA4の内部トラフィック除外は2段階#

GA4には、自分や社内からのアクセスを「内部トラフィック」として扱い、レポートから除外する仕組みがある。

少し分かりにくいのは、IPアドレスを登録する場所と、除外フィルタを設定する場所が別になっていること。

最初にWebデータストリーム側で内部トラフィックを定義する。

管理
  ↓
データの収集と修正
  ↓
データ ストリーム
  ↓
対象のWebストリーム
  ↓
タグ設定を行う
  ↓
すべて表示
  ↓
内部トラフィックの定義

ここでルールを作り、自分の回線で外部へ出る公開IPアドレスを指定する。traffic_typeの値は標準ではinternalになっている。

次に、同じプロパティのデータフィルタへ移る。

管理
  ↓
データの収集と修正
  ↓
データフィルタ
  ↓
フィルタを作成
  ↓
内部トラフィック

ここでtraffic_type = internalに一致するイベントを「除外」にする。

つまり、データフィルタ画面へIPアドレスを直接入力するわけではない。先にデータストリーム側でイベントへtraffic_typeを付け、その値をデータフィルタが見る構成になっている。

※ 記事内の図は内容を整理するために作成した概念図です。各社の公式資料や実際の製品画面ではありません。

最初は「テスト」で確認する#

データフィルタにはテスト、有効、無効の状態がある。

最初から有効へ切り替えるより、まずテストで確認した方がよい。

テストでは、該当するデータを完全に捨てず、テストデータのフィルタ名というディメンションを使ってデータ探索で確認できる。Googleの案内では反映まで24～36時間かかる場合がある。

確認後に有効へ変更する。

ここは慎重にしたい。有効の除外フィルタに一致したデータは、その後GA4で処理されない。Googleは、除外したデータはAnalyticsだけでなくBigQueryでも利用できなくなると説明している。

後からフィルタ条件を間違えていたことに気付いても、除外された期間のデータは戻せない。

IPアドレスで除外するデメリット#

自分のアクセスを除外できるなら有効にして終わり、という設定ではない。特に個人ブログでは、IPアドレスを条件にすること自体に弱点がある。

公開IPが変わると除外されなくなる#

内部トラフィックの標準設定はIPアドレスで判定する。

固定IPではない家庭回線では、再接続や回線側の都合で公開IPが変わることがある。IPが変われば以前のルールには一致せず、自分のアクセスが再び通常データへ入る。

VPNを使った場合はVPNの出口側、スマートフォンをモバイル回線へ切り替えた場合は別の送信元になる。

つまり除外しているのは「自分」という人ではなく、「登録したIPから来た通信」になる。

同じIPを使う他の人も除外される#

反対方向の問題もある。

家庭内の同じ回線を使う家族や、会社の同じ出口IPを使う社員は、GA4から見ると同じ公開IPになる場合がある。そのIPを内部トラフィックとして扱えば、その回線から来たアクセスも対象になる。

会社全体を除外したいなら問題ない。一人だけを除外したい場合は粒度が粗い。

過去に混ざったデータは消えない#

データフィルタは作成後の受信データに対して動く。過去のレポートへさかのぼって自分のアクセスを消す設定ではない。

ゆまラボでGA4を導入してからフィルタを有効にするまでに入った自分のアクセスは、過去データに残る。

「有効」の誤設定は取り返せない#

これが一番大きい。

テストなら該当データを見ながら確認できるが、有効の除外は処理対象から外す。IP範囲を広くしすぎた場合、本来残したかったアクセスまで失う。

小規模サイトではデータ量が少ないため、数日分を誤って除外した影響も相対的に大きい。

フィルタ数には上限がある#

GA4では、データフィルタはプロパティごとに10個まで作成できる。

自宅、会社、VPN、別拠点などを細かく分けたくなっても無制限ではない。内部トラフィックのルール側で複数条件を使えるため、必要以上にフィルタを分けない方が管理しやすい。

IP除外が合わない場合#

自宅の公開IPが安定しているなら、GA4標準の内部トラフィックフィルタが分かりやすい。

IPが頻繁に変わる環境では、別の方法も考えられる。

GA4には内部トラフィックとは別に「デベロッパートラフィック」のフィルタがあり、デバッグモードで送信したイベントを通常レポートから除外できる。タグの実装確認やDebugViewには向くが、普通に本番サイトを開いたアクセスまで自動で除外するものではない。

もう一つは、自分が確認に使うブラウザ側でGoogle Analyticsの通信を止める方法。IP変更の影響は受けにくいが、ブラウザや端末ごとに設定が必要になり、そのブラウザではGA4が正常に動いているか確認できなくなる。

サイト側でCookieやLocal Storageを使い、特定ブラウザだけGoogleタグを読み込まない実装もできる。ただしGA4標準機能ではなく、自前の分岐と保守が増える。

ゆまラボで使うならこの順番#

現在のゆまラボは、記事公開後に自分でページを確認する回数が多い。さらにGA4のデータを将来の人気記事自動表示にも使う予定がある。

この条件なら、自分のアクセスを通常データから外す意味はある。

ただし、最初から有効にはしない。

現在の公開IPを確認
  ↓
Webデータストリームで内部トラフィックを定義
  ↓
traffic_type = internalを付与
  ↓
データフィルタを「テスト」で作成
  ↓
自分で数ページ開く
  ↓
データ探索でテストフィルタを確認
  ↓
問題なければ「有効」へ変更

その後は、公開IPが変わっていないかも確認する必要がある。

自分のアクセスが過去データへ何割混ざっているかを正確に出すことは難しい。それでも、今後の計測を分ける方法は用意されている。

個人サイトでは、除外すること自体より、何を条件に除外しているのかを把握しておく方が重要になる。

参考#

• Google Analytics ヘルプ - 内部トラフィックの除外
• Google Analytics ヘルプ - データフィルタ
• Google Analytics ヘルプ - デベロッパーのトラフィックを除外する
• Google Analytics ヘルプ - 地域でのデータ収集