標準レポートで確かめた数字を、同じ期間・同じ指標で探索レポートに組み直したら、数値だけが小さくなった。この症状の原因は設定ミスではなく、画面ごとに参照するデータと保護の仕組みが別というGA4の設計にあります。直すのではなく、使い分けについて解説します。
この記事のまとめ#
- 探索と標準レポートの数値の差は、設定ミスではなくGA4の設計から生まれる
- 差を作る仕組みはサンプリング・(other)行・しきい値の3つ
- サンプリングと(other)行は標準レポート・探索・Data APIに共通で、対象外はBigQueryだけ
- 一致させにいくのではなく、どの数字をどの問いに使うかを先に割り当てる
- 割り当てた後も、どの仕組みが効いたかを数字を出すたびに確かめる反復は残る
1. 探索と標準レポートはどちらが正しいのか？#
どちらも正しい。これが結論です。
症状はいつも似た形で現れます。標準レポートでセッション数を確かめ、同じ期間・同じ指標の探索レポートを組む。すると探索の側だけ数%小さい。ディメンションを足すと、標準レポートにあった行が探索には見当たらない。片方を疑って設定を見直しても、この差は消えません。
なお、探索レポートそのものの組み方はGA4探索レポートの使い方｜ECは2つだけで扱ったので、この記事では省きます。Google Search ConsoleとGA4の数字が合わない話も、ツールをまたぐ別の症状です。そちらはGSCとGA4でAIの数字が合わない｜表示と訪問は別物で切り分けています。
差が消えないと分かると、多くの人は「どちらを基準にするか」を決めにいきます。ただ、この検討には終わりがありません。答えが二択の外にあるからです。標準レポートも探索も、それぞれの設計どおりの数値を返しています。決めるべきは信じる側ではなく、どの数字にどの問いを答えさせるかのほうです。
GA4は、標準レポート・探索・Data API・BigQueryという数字の出口ごとに、参照するデータの形と数値を守る保護の仕組みを別々に設計しています。この記事では、この出口を「面」と呼びます。同じ期間を指定しても、通る仕組みが別なら、面ごとに出てくる数値は別になります。次の節で、その仕組みを3つに分けます。
2. 数値を異ならせる3つの仕組み#
数値の差を作る仕組みは3つあります。サンプリング、(other)行、しきい値です。
1つ目はサンプリングです。イベント単位・ユーザー単位の詳細なデータを使う集計では、処理するイベント数が割り当ての上限を超えることがあります。そのときGA4は、全件の代わりに、利用できるデータの代表サンプルを使います[1]。上限は標準プロパティで1,000万イベントです[2]。期間を長く取り、ディメンションを自由に組み合わせる使い方ほど、処理するイベント数は膨らみます。上限に届いた集計はサンプルからの推計になるので、全件の集計とは数値がずれます。
2つ目は(other)行です。集計データを使う画面には、テーブルの行数に上限があります。データの行数がこれを上回ると、上回った分は「(other)」という1行にまとめられます[1][4]。まとめられやすいのは高基数のディメンション、つまり1日あたりの固有の値の数が500を超えるディメンションです[1]。ページURLのように値の種類が多い軸で起こります。集約のされ方は面と条件で変わるため、同じディメンションを指定しても、行の顔ぶれと内訳が一致しなくなります。
3つ目はしきい値です。掛かる場面は2つあります。ユーザー属性のデータや、それを使って定義したオーディエンスが含まれる場合。そして、検索語句の情報が含まれていて、合計ユーザー数が十分でない場合です[3]。掛かった行を、GA4は表示しません。データに含まれるシグナルから、個別のユーザーの身元や機密の情報を推測できないようにするための保護です[3]。消えた行は空欄として残らず、最初から無かったように見えます。行が消える症状の詳しい確かめ方はGA4で行が消える｜(other)としきい値の正体に譲ります。
この3つには適用範囲の線があります。公式ヘルプの比較表では、サンプリングも(other)行も、標準レポート・探索・Data APIの列に同じ文で書かれています。対象外はBigQueryだけです[1]。BigQueryへのエクスポートはイベントの生データなので、サンプリングも(other)への集約も掛かりません。ただし標準プロパティでは、エクスポートは1日100万イベントが上限です[1]。
3. 一致させる前に、使う場面を決める#
一致させる作業を打ち切って、割り当てを決めます。傾向の把握は標準レポート、明細の深掘りは探索、全件の監査はBigQuery。この3行が、この記事の答えです。
前月と比べる、チャネルの構成比を見る、急な増減に気づく。こうした傾向の問いは、多少のサンプリングや(other)への集約があっても結論が変わりません。標準レポートで足ります。
条件を組んで特定のセグメントを追う深掘りは、探索の場面です。ただし出てきた数値を使う前に、サンプリングの有無を確かめてください。探索の画面には、集計が全件から出たものかどうかを示す表示があります。掛かっていたら、期間を短くして、イベント数を上限の内側に収める方向で調整します。
1件単位の正確さが要る問い、返金の突合のような「全件でなければ意味がない」監査は、BigQueryの領分です。つなぐべきかどうかの判断はGA4のBigQuery連携は必要か｜売上を見るだけなら過剰で扱いました。
順序も決めておきます。3つの仕組みのどれが効いたかという原因の切り分けは、それ自体がゴールではありません。目の前の数字をどの問いに使ってよいかを決めるための手段です。切り分けで止まると、期間を変えた次の集計で、また同じ調査が始まります。
そして、この割り当ては一度作れば終わりというものでもありません。サンプリングが掛かるかどうかは期間とイベント数で毎回変わり、(other)への集約もしきい値も、条件しだいで現れたり消えたりします。数字を出すたびに「今回はどの仕組みが効いたか」を確かめ、数字と一緒に説明し続ける反復が残ります。
この反復を手で回すと、工程はこうなります。数字を1つ出すたびに、どの面から出したか、期間、サンプリングの有無、(other)行の有無を控える。前月の数字と比べるときは、まずその控えを突き合わせて、集計の条件が同じだったかを確かめる。差があれば、仕組みの差か実際の変化かを切り分けてから報告に載せる。判断の速度を決めているのは、数字を読む時間ではなく、この下ごしらえの反復のほうです。
RevenueScopeの解決策
「どのチャネルが売上に効いているか」のように、売上と結びつけて答える問いであれば、面の選択で迷う必要はなくなります。RevenueScope がこの問いを受け持ち、チャネル別のセッション・売上・RPS（1セッションあたりの売上）を1つの表で返します。数字は RevenueScope 自身の計測による1系統で、同じ問いには毎回同じ定義で答えます。GA4の面を置き換えるものではなく、投資判断の問いを受け持つ補完です。
MCP経由でChatGPTやClaudeに「直近30日、チャネル別のセッション・売上・RPSは？」と尋ねると、次の形で返ってきます。説明のために、架空店舗ラルゴの丸めた数字で書きます。
架空店舗ラルゴのチャネル別の内訳（イメージ）
| チャネル | セッション | 売上 | RPS |
|---|---|---|---|
| Google検索 | 4,000 | 52万円 | 130円 |
| Meta | 2,500 | 32万円 | 128円 |
| Direct | 2,000 | 20万円 | 100円 |
| Referral | 1,000 | 7万円 | 70円 |
| Yahoo!検索 | 500 | 3万円 | 60円 |
※ この表は説明用に置いた一事例で、店舗も数値も架空の丸めた値です。デモ画面が読んでいるのは見本ECのサンプルデータ（日々更新）なので、開いた日によって数値も行の構成も上の表とは異なります。
RPSの上位はGoogle検索の130円とMetaの128円で、2円しか離れていません。この2円をいくら見つめても、次の配分は出てきません。順番を決める条件は、この表の外にあります。帰属モデル、つまり1件の売上をどの接点のチャネルに割り当てるかのルールです。最後の接点で見るのがlast_touch、最初の接点で見るのがfirst_touchです。first_touchに切り替えると、Metaの売上は32万円から44万円に増えます。Google検索は52万円から40万円に減ります。合計の114万円とセッションの列は変わりません。変わるのは顔ぶれで、最初の接点で見たときに、Metaが入口として前に出ます。
つまりここでも、決めているのは問いのほうです。「入口を増やしたい」という問いなら、答えるのはfirst_touchの面。「最後のひと押しを評価したい」なら、last_touchの面。本文で決めた割り当てと同じ形が、この表の読み方にもそのまま続きます。
FAQ#
よくある質問#
Q. 探索レポートと標準レポートの数値は、結局どちらを信じればよいですか？
A. どちらも設計どおりの正しい数値です。選ぶ基準は正しさではなく問いのほうで、傾向の把握なら標準レポート、条件を組んだ深掘りなら探索を使います。
Q. 探索のサンプリングを完全に止める方法はありますか？
A. サンプリングは、集計に使うイベント数が割り当ての上限を超えると発生する可能性があります[2]。上限は標準プロパティで1,000万イベントです[2]。期間を短くしてイベント数を上限の内側に収めれば掛かりにくくなりますが、条件しだいで毎回変わります。出た数値ごとに有無を確かめる前提で使ってください。
Q. (other)行にまとめられた内訳を、元の行に戻せますか？
A. (other)行は、1日あたりの固有の値の数が500を超える高基数のディメンションで、行数の上限を上回った分がまとめられたものです[1][4]。対処は、集計の単位や期間を見直して、行数を上限の内側に収める向きになります。
Q. BigQueryにつなげば、この差の問題はすべてなくなりますか？
A. BigQueryのエクスポートにはサンプリングも(other)への集約も掛かりませんが[1]、標準プロパティでは1日100万イベントの上限があります[1]。集計のSQLも自分で書くことになるので、向いているのは全件の監査という問いです。傾向の把握まで移す必要はありません。
まとめ#
探索レポートと標準レポートの数値の差は、設定ミスではなくGA4の設計から生まれます。サンプリング、(other)行、しきい値という3つの仕組みが面ごとに働くので、同じ期間・同じ指標でも数値は一致しません。
だから、一致させにいく作業には出口がありません。先に決めるのは、どの数字にどの問いを答えさせるかです。傾向の把握は標準レポート、明細の深掘りは探索、全件の監査はBigQueryという割り当てが起点になります。そのうえで、数字を出すたびに、どの仕組みが効いたかを確かめる反復だけは残ります。
なお、GA4とShopifyの売上のように、ツールをまたいで数字が合わない話は、この記事とは別の軸です。そちらはGA4の売上がShopifyと合わない理由｜ズレ前提で予算を判断するで整理しています。
次に数値の差を見つけたとき、最初に問うのは「どちらが正しいか」でしょうか？それとも「この数字で何に答えたいか」のほうでしょうか？
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
