GA4の期間比較で施策の効果を見る｜数字が確定する時間と、欠ける条件

レポートの折れ線が上を向いていても、それだけでは施策が効いたとは言えません。GA4で前後を比べるときに結論を誤らせるのは、だいたい4つです。比べた2つの期間の切り方、まだ処理が終わっていない日を含めていること、しきい値や（other）で行が落ちていること、そしてGoogle側の集計やロギングに起因する動きです。どれも管理画面には警告として出てこないので、見た目の増減だけを根拠にすると、施策の評価を取り違えます。

ここでは Google アナリティクス ヘルプと Search Console ヘルプに書かれている内容だけを使って、期間比較で何をそろえるのか、いつの数字から判定してよいのか、差が出たときに何を先に疑うのかを順に見ていきます。ヘルプに記載を見つけられなかった項目は、推測で補わずに書かなかったものとして残しました。

比較の選択肢は3つあり、そろえるものが違う

まず期間の指定です。ヘルプは「期間を選択します。［過去 7 日間］、［過去 12 か月間］などの既定の期間から選択することも、右側のカレンダーで範囲を自由に選択することもできます」と説明しています。既定の期間を選ぶか、カレンダーで自分の施策に合わせて切るかの2通りです。施策を入れた日が月の途中なら、既定の期間ではなくカレンダーで切ることになります。

そのうえで、比べる相手を選びます。ヘルプに並んでいる選択肢は3つです。「前の期間（同じ曜日）」は、現在の期間のデータと、同じ曜日から始まる前の期間のデータが表示されます。「前の期間」は、現在の期間と前の期間のデータを比較します。「前年」は、現在の期間のデータと、前年の同じ日付で同じ期間のデータを比較します。

この3つは「何をそろえたいか」が違います。企業向けのサイトはアクセスが平日に偏るため、7日に満たない期間を直前とそのまま比べると、曜日の構成の違いがそのまま差になります。曜日の影響を消したいなら、同じ曜日から始まる比較を選びます。施策を入れた日の前後を同じ日数で切って見たいなら「前の期間」です。年末や新年度のように毎年決まった動きがある指標なら「前年」を選びます。

選択肢の名前は変わることがあります。ヘルプには「Google アナリティクスから［前年（同じ曜日）］オプションが削除されました。前年のデータを表示するには、［昨年］オプションを使用します」という注記があります。過去に作った手順書に無い選択肢が出てくる場合は、画面に並んでいる名前を正としてください。

なお、比較の前にそろえておくものがもう1つあります。見る指標の定義です。セッションとアクティブユーザー数では、同じ施策でも動き方が変わります。アクセス解析で見る指標の選び方の側で、ヘルプに書かれた定義から見る項目を絞る手順を扱っています。

直近の数字は、まだ確定していない

期間をそろえても、そこに入っている値が確定していなければ判定になりません。ヘルプの「データの更新頻度」には、標準プロパティの更新の間隔が区分ごとに示されています。リアルタイムは通常は数分、イントラデイは2〜6時間、毎日は12時間です。

さらに注意書きがあります。「データの処理には 24～48 時間かかることがあります。その間、レポートのデータに変化が生じる場合があります」。つまり、前日や当日を含めて前後を比べると、片側だけがまだ動く値ということが起こります。施策を入れた翌朝に比較を開いて「下がった」と判断するのは、この時間を無視した読み方です。

イントラデイと日次の関係にも記載があります。イントラデイ データは通常、レポートと API クエリの日次データより先に利用可能になるとされ、両者の間に一時的なギャップが生じることがあると説明されています。朝に見た数字と夕方に見た数字が違うのは、故障ではなくこの処理の順番によるものです。

Search Console も見ている運用では、待つ時間がさらに伸びます。Search Console ヘルプは「収集されたデータは通常、2～3 日以内に利用可能になります」と記載しています。2つを並べて報告する形にしているなら、判定の基準日は遅いほうに合わせることになります。そもそも両者は測っている場所が違うため、数字が一致しないのは前提です。その切り分けはSearch ConsoleとGA4の使い分けの側で扱っています。

行が欠けている数字で判定しない

処理が終わった期間を選んでも、レポートに出ている内訳が全部ではないことがあります。ヘルプが挙げているのは、しきい値と（other）行です。

しきい値は、個別のユーザーの身元や機密情報を推測できないようにするための仕組みです。ヘルプは、ユーザー属性データやユーザー属性データを使って定義されたオーディエンスが含まれている場合、また検索語句の情報を含む場合に、合計ユーザー数が十分な数に達していなければ該当データを含む行が除外されるとしています。適用されているかどうかは、レポート上部のデータ品質インジケーターから確認できます。しきい値そのものは調整できず、期間を広げるか BigQuery へエクスポートすることで影響を減らせる可能性があると書かれています。

ここが前後比較に効きます。短い期間で切ると、片側では母数が足りずに落ちた行が、もう片側では残ることがあります。内訳を足し合わせた値を比べているつもりで、実際には別の範囲を比べている状態です。属性別や検索語句別の増減を見たいときは、期間を広げるほうが判定に向きます。

（other）行は、ディメンションの値の種類が多いときに現れます。ヘルプは「値が 500 を超えるディメンションは高基数ディメンションとみなす必要があります」と説明し、あわせて「ディメンションあたり 500 という値は、上限ではなく目安です」と明記しています。上限はプロパティ タイプ、個々のレポート、クエリの複雑さによって異なるとされ、具体的な行数の上限は示されていません。回避の方向としては、カスタム ディメンションを作らずに既存のディメンションを使うことなどが挙げられています。

Search Console 側にも似た制約があります。ヘルプは、表には 1,000 行までしか表示されないため一部の行が省略される可能性があること、ユーザーのプライバシーを保護するためにまれなクエリは省略されることを記載しています。クエリ別の数字を足し合わせて前後で比べても、合計と内訳は一致しません。

何が起きるか	ヘルプの記載	前後比較への影響
しきい値で行が除外される	ユーザー属性データや検索語句の情報を含む行は、合計ユーザー数が十分な数に達していなければ除外される	期間を狭く切った側だけ行が落ち、増減が実態より大きく見える
しきい値は調整できない	しきい値そのものは調整できないが、期間を広げるか BigQuery へエクスポートすることで影響を減らせる可能性がある	判定のために期間を広げるかどうかを、先に決めておく必要がある
（other）行へまとめられる	値が 500 を超えるディメンションは高基数ディメンションとみなす必要がある。500 という値は上限ではなく目安	ページ別・キャンペーン別の内訳が追えず、どこが動いたかを特定できない
表の行数の上限（Search Console）	表には 1,000 行までしか表示されないため、一部の行が省略される可能性がある	クエリ別の合計を前後で足し合わせても一致しない
まれなクエリの省略（Search Console）	ユーザーのプライバシーを保護するために、まれなクエリは省略される	施策で新しく増えた検索語が、表に出ないことがある

動いた原因が、Google側にあることもある

自社で何もしていないのにグラフが折れている、という場面があります。Search Console には、それを調べるためのページが用意されています。ヘルプは「まれに、Search Console でレポートデータに影響する可能性がある事象が発生することがあります。たとえば、Google がデータ集計方法を変更した場合やロギングエラーがあった場合、グラフに急激な減少または増加が見られることがあります。このページには、過去 3～16 か月間に発生し、お客様のデータに影響する可能性のある既知の問題が記録されています」と説明しています。

実際に記録されている例を挙げます。「ロギングエラーにより、2026 年 8 月 13 日のデータで Discover パフォーマンス レポートのクリック数とインプレッション数が減少しました」、「ロギングエラーにより、2026 年 8 月 13 日～ 8 月 17 日のデータで、Google 検索の生成 AI パフォーマンス レポートのインプレッション数が減少しました」。この期間をまたいで前後を比べれば、施策とは無関係に数字が下がります。

判定の手順としては、差が出た日付をこのページと突き合わせ、該当するなら自社の施策の結果として数えない、という使い方になります。ただし逆は成り立ちません。このページに載っていない変動が自社サイト由来であるという説明は、確認した範囲では記載がありませんでした。載っていないことは、原因が特定できたという意味にはなりません。

比較機能で「どこが動いたか」を切り分ける

全体の数字が動いた理由を知るには、切り口を分ける必要があります。GA4のレポートには比較の機能があり、ヘルプの手順では、レポート右上のアイコンをクリックし、保存済みの比較を選ぶか新規作成をクリックして、ディメンションを選び、マッチタイプを指定し、ディメンション値を入力して適用します。端末別、流入元別といった切り口で、同じ期間を横に並べられます。

仕様に制限があります。1つの比較で作成できる条件は最大4つ、保存できる比較は GA4 プロパティごとに最大200個です。条件を足しすぎると対象が小さくなり、しきい値で行が落ちる側へ近づきます。なお、よく使う切り口は事前構築された比較として用意されていて、ノーリファラー、オーガニック トラフィック、ウェブ トラフィック、モバイル トラフィック用の比較が含まれると記載されています。自分で作る前に、同じものがあるかを見たほうが早いです。

前後の判定をするときに、とくに引っかかるのがオーディエンスを使う比較です。ヘルプは、オーディエンスの作成時点以降に収集されたデータにのみ比較が適用されると記載しています。施策を評価しようとして新しくオーディエンスを作っても、施策より前の期間には適用されません。「前」側のデータが空になるので、前後比較の軸には使えないということになります。

項目	ヘルプの記載	判定で気をつけること
条件の数	最大 4 つの条件を作成します	絞るほど母数が小さくなり、しきい値で行が落ちやすくなる
保存できる数	GA4 プロパティごとに、最大 200 個の比較を保存できます	毎回作り直さず、判定に使う切り口は保存して固定する
事前構築された比較	ノーリファラー、オーガニック トラフィック、ウェブ トラフィック、モバイル トラフィック用の比較が含まれる	同じ切り口が用意されていないかを先に確認する
リアルタイム レポート	リアルタイム レポートでは、空白のカードが表示される可能性が高くなります	当日の様子を見る用途であり、前後の判定には向かない
オーディエンスを使う比較	オーディエンスの作成時点以降に収集されたデータにのみ比較が適用されます	施策より前の期間にはさかのぼれない

切り分けの前提として、社内からのアクセスが数字に混ざっていないかも関わります。社内で検証した日だけ数字が伸びていると、切り口を分けても原因が追えません。除外の設定はGA4で自社のアクセスを除外するの側で扱っています。

判定の順番を固定する

ここまでの内容は、見る順番を決めておくと毎回同じ手順で回せます。最初に、比べた期間が処理の終わった日までで切られているかを見ます。次に、レポートにしきい値や（other）の表示が出ていないかを確かめます。そのうえで、差が出た日付が Search Console のデータ異常に記録されていないかを突き合わせます。この3つを外せたときに、はじめて比較でディメンションを分け、どの切り口が動いたのかを見にいきます。

毎週この順番を手作業でたどるのは続きません。見る切り口が決まったら、定例で開く形にしておくほうが確実です。配信の仕組みと更新の頻度はKPIレポートの作り方の側で扱っています。

ヘルプで確認できなかったこと

今回の確認では見つけられなかった項目があります。1つのレポートに同時に適用できる比較の数について、明示的な上限の記載は確認できませんでした。期間の比較に「カスタム」に相当する任意の2期間を指定する選択肢があるかどうかも、日本語のヘルプページでは確認できていません。比較を適用した状態でしきい値がどう働くかについても、個別の記載を見つけられませんでした。

社外の解説にはこれらの数字や挙動が書かれていることがありますが、出所をたどれないものを当サイトの確認済みの値として書くことはしません。実務では、画面に表示されている選択肢と、データ品質インジケーターの表示を根拠にしてください。そして判定に使った期間、比較の種類、確認した日を記録に残しておくと、翌月に同じ条件で見直せます。数字が動いたかどうかは、条件を固定したときにだけ比べられます。