GA4で除外・注意したいデータ｜内部アクセス・欠測・スパムの整理

この記事の目次

消す前に、除外の目的を言葉にする

内部アクセス、開発テスト、計測欠落、疑わしい流入を一括して「不要データ」にしないでください。収集時に除外するデータフィルターと、レポート上で絞る条件では影響が違います。アクティブな除外フィルターで処理されなかったデータは後から戻せません。

この手順はWebの内部アクセスをテスト状態で確認してから適用する流れです。必要なものはプロパティの編集権限、管理者が確認したネットワークのIP条件、社内外の確認担当者です。

品質・変更記録テンプレートを使えます。IPそのものをAIへ送る必要はありません。社内資料にはアクセス制限を付けます。

GA4管理のデータストリームから対象Webストリームを開き、タグ設定→すべて表示→内部トラフィックの定義へ進みます。ルール名とtraffic_typeの値を決め、管理者が確認したIP条件を登録します。

既定の値を使う場合はinternalです。自宅・VPN・動的IPなどでは条件が変わり得るため、会社の全員が同じIPになるとは限りません。プライベートIPや推測した範囲をそのまま入れず、実際の出口と一致するか担当者が確認します。

管理のデータフィルタで内部トラフィックを選び、除外対象のtraffic_typeを手順2と一致させます。最初はテスト状態で保存します。この時点で「社内アクセス除外済み」と記録しません。

テスト状態で分類されたデータを、探索の「テストデータのフィルタ名」など公式手順の確認軸で調べます。内部アクセスと外部アクセスをそれぞれ行い、意図したものだけが一致することを確認します。処理に時間がかかる場合は確認期間を記録します。

適用する場合は担当者が結果を確認し、フィルターをアクティブへ変更します。以後のデータへの影響は永続的です。誤りがあれば将来の除外を止めるために無効へ戻せますが、失った分は復元されません。過去データを消す操作でもありません。

国・参照元・ホスト名・イベント・日付などを比較し、広告施策や計測変更とも照合します。不審な地域というだけで除外する判断はしません。公式資料にはWebホスト名などのフィルターもありますが、ここで作った内部IPルールがすべてのスパムを止めるわけではありません。

確認中はレポートの比較・フィルターで、含めた場合と除いた場合の両方を保存します。取得段階の恒久的な除外へ進む前に、正常データを失わない条件を確認します。

この品質台帳を前提に分析してください。
欠測期間を0件と見なさず、除外前後の比較を同条件として扱わないでください。
疑わしい流入は原因未確定とし、結論が変わる可能性を示してください。
除外設定の変更やデータ削除は実行しないでください。

適用状態と期間が明確で、正常アクセスを残すテストが済み、分析者へ台帳を渡せれば完了です。実際のフィルター適用はこの記事の制作では行っていません。

AI支援で制作。公式資料の確認日：2026年10月5日。次回確認予定：2027年1月5日。実アカウントの操作・課金・公開、実務者監修、第三者再現は未実施です。掲載の記入例・数値例は架空の教材であり、実績ではありません。