同じサイト、同じ期間を見ているのに数字が合わない。
GA4の画面ではA。データ探索ではB。Data APIから取ったらC。BigQueryで集計すると、また少し違う。
ウェブ解析をしていると、珍しくありません。
私自身、1,000店舗を超えるアクセス集計で「店舗別ユーザーを合計した数字と全体ユーザーが合わない」こともあれば、1分単位のアクセスピークを調べた際に、単日取得と複数日取得で結果の見え方が変わったこともあります。
こういうときに、いきなり「GA4がおかしい」と考えると遠回りします。
最初に確認したいのは、もっと基本的なことです。
本当に、同じ条件で同じものを数えているのか。
私が数字のズレを調べるときは、だいたい次の順番で切り分けます。
期間 → 指標 → 抽出条件 → 集計単位 → データの表示・処理 → 取得方法 → 実装
複雑な原因から疑うのではなく、手前から潰していく方が結果的に早いです。
1. 期間は本当に同じか
最初は期間です。
「8月の数字」と言っても、8月1日〜31日なのか、直近30日なのか。タイムゾーンは同じか。比較対象は前月なのか前年同月なのか。
さらにGA4では、直近のデータは処理状況によって数字がわずかに変わる場合があります。Googleも、過去48時間程度のデータでは処理タイミングによる差が生じる場合があると案内しています。
月次レポートなら、私は「対象期間」だけでなく、いつ取得したデータかも揃えます。
同じ月を比較しているつもりでも、取得条件が毎回違えば、差が施策によるものなのか処理タイミングによるものなのか判断しづらくなるからです。
2. 同じ名前でも、同じ指標とは限らない
次に見るのが指標です。
GA4には、総ユーザー数、アクティブユーザー、新規ユーザーなど、複数の「ユーザー」に関する指標があります。
セッションとエンゲージメントのあったセッションも別物です。
「ユーザー数が違う」という相談でも、実は片方がActive users、もう片方がTotal usersだった、ということがあります。
大事なのはラベルの日本語ではなく、その指標が何を数えているのかです。
レポートの数字を受け取ったときも、「ユーザー数」「アクセス数」のような曖昧な名称だけで引き継がず、GA4上の正式な指標名まで残しておくと事故が減ります。
3. 「Instagram経由」の定義は同じか
条件の違いも、数字がズレる典型です。
たとえば「Instagram経由」を集計するとします。
- 初回流入を見るのか、セッション単位の流入を見るのか
instagram.comだけか、l.instagram.comなども含めるのか- Default Channel GroupのOrganic Socialで見るのか
- 自分たちで定義したSNSグループで見るのか
これだけでも数字は変わります。
だから私は、「SNS」「Instagram」のようなラベルだけで集計条件を残さないようにしています。
誰があとからやっても同じ抽出になる条件まで書いておく。
定例レポートでは、この再現性が数字そのものより重要になる場面があります。
4. ユーザー数を足していないか
実務でかなり多いのが、集計単位の問題です。
店舗Aのユーザーが100人、店舗Bが80人。
だから全体180人、とは限りません。
20人が両方の店舗ページを見ていれば、店舗別では100＋80と表示されても、全体では160人です。
私は多店舗サイトの定例集計で、このズレを何度も扱っています。
ここで重要なのは、「GA4のユーザー数は変だ」と考えることではありません。
行ごとのユニーク数を足すことと、全体でユニークに数え直すことは計算が違うと理解することです。
この問題はページ別、流入元別、デバイス別でも起こります。
5. 画面に「すべて」が出ているとは限らない
大量のディメンション値を扱うと、GA4では一部の値が(other)へまとめられることがあります。
ユーザー属性などでは、プライバシー保護のためデータしきい値が適用される場合もあります。処理量が大きい探索やData APIのクエリでは、データ品質アイコンやサンプリングの有無も確認します。
特に、多数のURL、店舗ID、細かな流入元を扱う分析では重要です。
「画面に見えている表を全部足したから、これが全件」とは限らない。
まず、GA4がどのような状態でその表を返しているかを確認します。
6. GA4画面・Data API・BigQueryは役割が違う
Data APIは、GA4のレポートデータをプログラムから取得するための仕組みです。Reporting identityなど、プロパティ側のレポート設定を反映します。
一方、BigQuery Exportでは、GA4が収集したイベント単位のデータを扱います。Googleの比較ガイドでは、BigQueryへのエクスポートはDevice IDに基づくデータであり、標準レポート側のレポート用識別子やモデリングなどと条件が異なる場合があると説明されています。
そのため、GA4画面とBigQueryの数字が完全一致しないこと自体はあり得ます。
私がBigQueryを使うときも、「GA4画面を完全再現する」ことを目的にはしていません。
GA4画面では答えづらい問いを調べるために使います。
取得方法が違うなら、何を比較してよいかも確認する。
ここを飛ばすと、「20件違う。どちらかが間違いだ」という議論になりやすくなります。
7. 最後は計測実装を疑う
ここまで揃えても説明できないなら、実装へ戻ります。
- GTMのタグが二重発火していないか
- 同じGA4タグが複数設置されていないか
- Thanksページの再読み込みでCVが増えていないか
- 特定ページだけ計測タグが抜けていないか
- URL条件やイベント条件が間違っていないか
ツールの高度な仕様を調べ続けた結果、原因は単純なタグの重複だった、ではもったいない。
だから私は、順番を決めて切り分けます。
「正しい数字」より「再現できる数字」
もちろん、明らかな計測ミスは修正しなければいけません。
ただ、アクセス解析で本当に困るのは、数値が1％違うことより、なぜその数値になったのか説明できないことです。
今月は標準レポート。来月は別のLooker Studio。翌月はBigQuery。
毎回違う定義で数字を出していたら、増減そのものを比較できません。
だから私は、数字が合わないときに最終的に確認したいことを2つに絞っています。
その数字がどう作られたか説明できるか。
翌月も同じ条件で作り直せるか。
数字は、報告書を埋めるためではなく、次の判断をするためにあります。
「数字が合わない」はトラブルですが、同時に、計測と集計の設計を見直す良いきっかけでもあります。
関連する知見
数字の取得だけでなく、比較できる定義と改善判断まで設計します。
