「数字が消える・変わる・合わない」の正体
GA4のレポートを見ていて、次のような経験はないでしょうか。
- 日別では表示される数字が、期間を月単位に広げると変わって見える
- ディメンションの行を掘り下げると
(other)という行にまとまる - 内訳を足しても、上部の合計と一致しない
これらは不具合ではなく、GA4の仕様として起きる現象です。ただし原因は1つではありません。おもに「データしきい値」「(other)行（カーディナリティ）」「サンプリング」の3つが絡みます。
問題は、この3つが似た症状に見えるため混同されやすいことです。原因が違えば対処も変わります。まずは3つを切り分けて理解することが、正確なレポートへの近道になります。
データしきい値：少数ユーザーが表示されない仕組み
データしきい値は、プライバシー保護のための仕組みです。表示するデータが少数のユーザーに基づく場合、個人が特定される可能性を下げるため、その行やデータを表示しないよう制御します。
どんなレポートで発生するか
しきい値は、おもにユーザー属性（年齢・性別・インタレスト）やGoogleシグナルに関わるデータを含むレポートで発生しやすくなります。これらの情報は個人の特定につながりやすいため、少人数だと非表示の対象になります。
一方で、ユーザー属性を含まない集計では発生しにくい傾向があります。
確認方法：データ品質アイコン
しきい値が適用されているかどうかは、レポート右上に表示される「データ品質アイコン」で確認できます。アイコンにカーソルを合わせると、しきい値が適用されているかどうかの説明が表示されます。
| 状態 | アイコンの示す内容 | 意味 |
|---|---|---|
| 適用なし | 通常表示 | しきい値による非表示は起きていない |
| 適用あり | しきい値の注記 | 一部データがプライバシー保護で非表示 |
しきい値が効いていると、内訳の合計が上部の総数に届かないことがあります。この差分が「合計と合わない」の一因です。
(other)行：カーディナリティ上限による集約
(other) 行は、しきい値とはまったく別の仕組みです。ディメンションが持つ値の種類数（カーディナリティ）が、レポートで扱える上限を超えたときに発生します。
上限を超えた分の値は個別に表示されず、まとめて (other) という1行に集約されます。ページパスやイベントパラメータのように、値の種類が非常に多いディメンションで起きやすくなります。
(other) はデータが消えたわけではありません。総数には含まれたうえで、内訳としては1行にまとまっている状態です。しきい値のように「非表示になって合計から欠ける」現象とは性質が違います。
運用メモ：カーディナリティの具体的な上限値は環境や仕様の更新で変わりうるため、固定値として覚えるより「値の種類が多いディメンションで起きる集約」と理解しておくほうが実務では扱いやすくなります。
サンプリング：探索レポートでの推計
サンプリングは、分析対象のイベント数が上限を超えたときに、全データではなく一部の標本から全体を推計する仕組みです。GA4では、おもに探索レポートで発生します。
標準レポートとの違い
標準レポートは、あらかじめ集計された「集計テーブル」を参照するため、通常はサンプリングが発生しにくい設計です。一方、探索レポートは指定した条件でその場で集計するため、対象イベントが多いとサンプリングが起きることがあります。
| 項目 | 標準レポート | 探索レポート |
|---|---|---|
| 集計方法 | 集計済みデータを参照 | 条件指定でその場で集計 |
| サンプリング | 発生しにくい | 大規模データで発生しうる |
| 主な用途 | 全体傾向の俯瞰 | 仮説の深掘り |
探索レポートでも、右上のデータ品質アイコンでサンプリングの有無を確認できます。サンプリングが効いていると、100%のデータではないため、数値に推計の幅が生じます。
3つの見分け方
ここまでの3つを、症状・発生場所・確認方法・対処で並べて整理します。原因の当たりをつけるための早見表として使えます。
| 現象 | 主な症状 | 発生しやすい場所 | 確認方法 | 基本の対処 |
|---|---|---|---|---|
| データしきい値 | 少数データが非表示・合計に届かない | ユーザー属性/Googleシグナル系レポート | データ品質アイコン | 期間を広げる・属性を外す |
| (other)行 | 値が (other) に集約され内訳を追えない | 値の種類が多いディメンション | (other)行の有無 | 粒度を粗くする・探索やBigQuery |
| サンプリング | 数値が推計になり幅が出る | 探索レポート（大規模データ） | データ品質アイコン | 期間短縮・標準レポート・BigQuery |
3つに共通する確認起点は、レポート右上の「データ品質アイコン」です。まずここを見る習慣をつけると、原因の切り分けが速くなります。
実務での対処
原因ごとに対処は変わりますが、実務では次の順で考えると整理しやすくなります。
期間と粒度を調整する
しきい値は少数データで起きやすいため、期間を広げてユーザー数を増やすと、非表示が解消される場合があります。逆にサンプリングは対象イベントが多いと起きるため、期間を短くする方向が有効です。
(other) は、より粗い粒度のディメンション（例：個別ページではなくページグループ）に切り替えると、値の種類が減って回避しやすくなります。
レポートの使い分け
サンプリングを避けたいときは、可能な範囲で標準レポートを使うのが基本です。深掘りが必要で探索レポートを使う場合は、フィルタで対象を絞り、扱うイベント数を減らす工夫が効きます。
正確な数字が必要なとき
しきい値・サンプリング・(other)のいずれの影響も避けたい場合は、BigQueryエクスポートが選択肢になります。イベント単位の生データを直接集計できるため、UIレポート特有の丸めや集約の影響を受けにくくなります。
広告レポーティングでの注意
ここからは筆者の意見です。クライアント報告では、数字そのものより「なぜ数字が動くのか」の説明の準備が効いてきます。
日別の合算と月次の総数がずれる、内訳が総数に届かないといった指摘は、報告の場でしばしば出ます。このとき「不具合ではなく、プライバシー保護や集計の仕様です」と切り分けて説明できると、数字への信頼を保ちやすくなります。
以下は、報告前に確認しておきたいチェックリストです。
- レポート右上のデータ品質アイコンを確認したか
- しきい値・(other)・サンプリングのどれが効いているか切り分けたか
- 内訳の合計と総数がずれる場合、その理由を説明できるか
- 正確な絶対数が必要な指標は、BigQuery等の別ソースで裏取りしたか
- 前月と同じ条件（期間・粒度・ディメンション）で比較しているか
数字が動く仕組みを運用者側が先に押さえておくと、報告の場での説明が主体的になります。数値の丸めを前提にしたうえで、意思決定に足る精度かどうかを都度判断する姿勢が、実務では扱いやすいと考えます。