GA4の日別の数字を足すと期間より多い｜足せる指標・取り直す指標を13週で確かめた

GA4 の日別の表の「ユーザー数」を足して週報や月報を作ると、期間を指定して見た数字と合わないことがあります。行を足して期間の数字に戻るのは、イベント数やビュー（表示回数）のように1件ずつ数える指標です。合計ユーザー数・アクティブ ユーザー数・セッションのように一意の数を推定する指標は、行に分けたときと期間全体とで別々に数えられるので、足しても期間の数字と一致する保証はありません。

当社は GA4 と Google タグ マネージャーでの計測の設計・実装から、週報・月報のような定例のレポートの数字の取り方までを支援している会社です。7つの指標を12通りに切って行の合計と期間の数字を比べたのは、週報・月報で日別の行を足すと期間の数字とどれだけ違うかを、指標ごとに確かめるためでした。測る前の計画では、日付をまたぐセッションが両方の日に入る分だけ、日別に足したセッションが期間よりわずかに多くなる、と見込んでいました。ところが、当社サイトの GA4 では月別に足したセッションが 1.020 倍で、日別の 1.016 倍より大きくなりました。境目が3つしかない月別の方が、90ある日別より多く重なるはずはありません。この食い違いを、指標ごとの定義と公式の説明に当てて読んだのがこの記事です。

照会したのは、当社のコーポレートサイトの GA4 プロパティ（標準のプロパティ、レポートのタイムゾーンは日本）です。2026年10月15日に Data API で、2026年7月13日（月）〜10月11日（日）の13週・91日を読みました。載せるのは「行の合計÷期間の数字」の比だけで、ユーザー数やセッション数の実数は出しません。1つのプロパティ・1つの期間で見た値なので、比の大きさはサイトによって変わりえます。GA4 の画面のレポート・探索・データポータル（旧 Looker Studio）・BigQuery へのエクスポートでは確かめておらず、率・キーイベント・収益の合計や、ほかの長さの期間も見ていません。数字が合わないときの原因の全体（サンプリング、スコープ、Search Console との違いなど）はGA4 の数値不整合の原因を確かめる記事に、BigQuery で推定を使わずに数える方法はGA4 と BigQuery の連携の記事に書いています。

7つの指標を12通りに切って足した結果

照会は、サービス アカウントの読み取り権限で runReport を13本送りました。期間と7つの指標はすべて同じで、1本目はディメンションを付けずに期間の数字を取り、残りの12本は下の表の左の列のディメンションのどれか1つで切りました。日付で切った1本の主な部分を REST の書き方に直すと、次のとおりです（Python のクライアント ライブラリで送り、プロパティ ID は伏せています）。

POST https://analyticsdata.googleapis.com/v1beta/properties/PROPERTY_ID:runReport
{
  "dateRanges": [{ "startDate": "2026-07-13", "endDate": "2026-10-11" }],
  "dimensions": [{ "name": "date" }],
  "metrics": [
    { "name": "totalUsers" }, { "name": "activeUsers" }, { "name": "newUsers" },
    { "name": "sessions" }, { "name": "engagedSessions" },
    { "name": "screenPageViews" }, { "name": "eventCount" }
  ],
  "metricAggregations": ["TOTAL"],
  "limit": "100000"
}

13本の応答は、どれもしきい値の適用（subjectToThresholding）が無く、サンプリングの情報も返らず、行が「(other)」にまとめられた印（dataLossFromOtherRow）もありませんでした。行が欠けたせいで合わない、という状態ではありません。12本の行を全部足し、1本目の期間の数字で割った比が次の表です。1.000 なら足すと期間の数字に戻り、1 より大きければ足しすぎ、小さければ足りません。

出典：当社サイトの GA4（上の照会）。行の切り方の名前は、GA4 ヘルプにあるものはヘルプの表記、無いもの（ISO 年の ISO 週・年、月・曜日の名前・ページ階層）は Data API の日本語の表示名にしました。ヘルプの「週」（01〜53）と「月」（01〜12）は、この表の ISO 年の ISO 週・年、月とは別のディメンションです。

足して戻ったのは、イベント数・ビュー・新規ユーザー数

イベント数とビューは、定義から分かります。GA4 ヘルプでは、イベント数は「ユーザーがイベントをトリガーした回数」、ビューは閲覧した画面やページの数で、同じページを繰り返し見た分も数えます（アナリティクス ヘルプ「アナリティクスのディメンションと指標」）。1回の表示、1つのイベントは、どの日にも、どのページにも1回しか入らないので、行に分けても重なりません。

新規ユーザー数は、名前に「ユーザー」と付き、定義も「first_open または first_visit イベントがログに記録された新しい一意のユーザー ID の数」と一意の数です（同じヘルプ。ヘルプの表記は「新規ユーザー」）。それでも当社の13週では、12通りすべてで 1.000 でした。初めて来たときのイベントで数えるので、1人が初めて来た日は1日しかなく、日で分けても重なりません。また、Google の開発者向けの解説が推定（後述の HLL++）の精度の表に挙げているのはセッション数・アクティブ ユーザー数・合計ユーザー数の3つで、新規ユーザー数は入っていません（Unique count approximation in Google Analytics）。ただ、ほかのプロパティや期間でも一致するかは、この照会からは言えません。

合計ユーザー数は、細かく切るほど足しすぎる

合計ユーザー数の定義は「イベントをトリガーした一意のユーザー ID の数」です（GA4 ヘルプ）。一意の数は、行ごとに重複を除いて数えます。月曜と木曜に来た人は、月曜の行でも木曜の行でも1人なので、日別の行を足すと2人になります。期間の数字では1人のままです。

当社の13週では、月別が 1.006 倍、週別が 1.026 倍、日別が 1.071 倍、日付と時間が 1.233 倍で、区切りが細かいほど大きくなりました。曜日の名前（1.056 倍）は13週分の月曜を1行にまとめる切り方なので、日別より小さく出ます。同じ人が複数の行にまたがりやすいほど大きくなる、一意の数の数え方どおりの並びです。

大きさは計画と違いました。計画では、日別に足した合計ユーザー数は期間よりかなり多いと見込んでいましたが、1.071 倍でした。一方、日付と時間で切ると 1.233 倍です。同じ人が同じ日の別の時間帯の行にも入る分（その日のうちに戻ってくる人や、時の境目をまたぐ訪問）が加わり、次の節で見る推定のずれも混ざっています。どの比も当社サイトの訪問のされ方で決まる値で、ほかのサイトに当てはめられる数字ではありません。

推定を使わない数え方でも、足すと多くなる

GA4 のユーザー数は推定値なので（次の節）、足しすぎが推定のせいだけではないことを、推定を使わない数え方で確かめました。Google が公開している GA4 のサンプルデータ（BigQuery の ga4_obfuscated_sample_ecommerce）の2021年1月で、日ごとに COUNT(DISTINCT user_pseudo_id) を数えて31日分足した値と、1月全体で数えた値を比べます。BigQuery で COUNT(DISTINCT) を使えば、推定ではなく正確な数になります（同じ開発者向けの解説、アナリティクス ヘルプ「アナリティクスのセッションについて」）。SQL は、使わない列を省いて整形しています。

WITH d AS (
  SELECT event_date, COUNT(DISTINCT user_pseudo_id) AS u, COUNT(*) AS ev
  FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131'
  GROUP BY 1
)
SELECT
  (SELECT SUM(u) FROM d) AS sum_daily_users,
  (SELECT COUNT(DISTINCT user_pseudo_id)
     FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
     WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131') AS month_users,
  (SELECT SUM(ev) FROM d) AS sum_daily_events,
  (SELECT COUNT(*)
     FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
     WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131') AS month_events

sum_daily_users  month_users  sum_daily_events  month_events
106565           94790        1210147           1210147

日別の人数を足すと 106,565、1月全体では 94,790 で、1.124 倍でした。イベント数は両方とも 1,210,147 です。重複を除いて正確に数えても、日別の人数の合計は期間の人数より多くなります。照会した2本の処理量は合わせて約 0.28 GiB でした。

アクティブ ユーザー数も同じ並び（日別 1.024 倍、日付と時間 1.176 倍）でした。

セッションは、月別に足すと日別より多かった

セッションは、日付で切ってもほとんど重ならないはずの指標です。1回の訪問が日付をまたぐときだけ、両方の日の行に入りえます。セッションは30分操作が無いと終わりますが、続く長さに上限はありません（アナリティクスのセッションについて）。日付をまたいだセッションを GA4 がどう数えるかは、このヘルプには見当たりませんでした。そこで、どれくらいのセッションが日付をまたぐかを、公開サンプルで数えました。セッションは user_pseudo_id と ga_session_id の組です。

WITH s AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS sid,
    COUNT(DISTINCT event_date) AS dates
  FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131'
  GROUP BY 1, 2
)
SELECT
  COUNT(*) AS sessions,
  COUNTIF(dates >= 2) AS cross_sessions,
  COUNTIF(dates >= 3) AS three_plus,
  SUM(dates) AS sum_session_days
FROM s

sessions  cross_sessions  three_plus  sum_session_days
118380    238             0           118618

2021年1月のセッション 118,380 のうち、event_date が2日にまたがるのは 238（0.20%）、3日以上は0でした。日ごとに数えて足すと 118,618 で、またいだ 238 が2回数えられた分だけ多くなります。数えたのは1月の表の中だけなので、12月31日から1月1日へ、1月31日から2月1日へまたぐセッションは入っていません。また、この表の event_date は日本時間の日付ではないので、日本時間で日を区切れば、またぐ数は変わります。

当社の13週では、日別と週別がどちらも 1.016 倍で、月別は 1.020 倍でした。期間は7月の途中から10月の途中までで、月の境目は3つしかありません。日付をまたぐ重なりだけなら、境目が90ある日別より月別の方が小さくなるはずです。セッションのデフォルト チャネル グループで切っても 1.024 倍でした。このディメンションは「セッションの開始に関連付けられた」チャネルで（GA4 ヘルプ）、1回のセッションは1つの行にしか入らないはずです。重なりでは説明できない分があります。

公式の資料で裏付けられるのは、セッション数が推定値だということです。ヘルプは「セッションとユーザーに関する指標は、推定値に基づいて算出されます」とし、ユニークなセッション ID の数を HyperLogLog++（HLL++）という方法で推定していると説明しています（アナリティクスのセッションについて）。推定の細かさ（precision）は、セッション数が12、アクティブ ユーザー数と合計ユーザー数が14です（Unique count approximation in Google Analytics）。誤差の大きさについては、別のヘルプが、ほとんどの場合差異率は1%未満で、複数の HLL++ の指標を組み合わせると高くなることがあるとしています（アナリティクス ヘルプ「データのサンプリングについて」）。行を足したときのずれについての記述は見当たりません。

月別の 1.020 倍、2つのチャネル別の 1.024 倍と 1.026 倍は、この「ほとんどの場合1%未満」を超える大きさです。推定のずれだけで説明できるのかは分かりません。当社の照会では、日付をまたぐ重なりと推定のずれを分けていないためです（今回の照会はセッション単位では数えておらず、当社のプロパティで日付をまたいだセッションの数は分かっていません）。言えるのは、重なりが無いはずの切り方でもセッションの行の合計は期間の数字からずれ、その大きさは当社の13週で2%台になることがあった、までです。

ページ階層で切ったときの 1.069 倍は、性質が違います。ページ階層は表示されたページごとに付く値なので、3ページを見た1回のセッションは3つの行に1回ずつ数えられます。セッションの最初のページビューのページパスを値にするランディング ページ（GA4 ヘルプ）なら、1回のセッションは1行に入り、当社では 1.015 倍でした。この値は、ランディング ページが (not set) の行も含めて足したものです。page_view の無いセッションが (not set) に集まる仕組みと、その行の割合は数値不整合の記事に書いています。ページ別のセッションを全ページ分足して「サイト全体のセッション」にしないこと、ページ別に足すならランディング ページで切り、(not set) の行も落とさないこと、の2つがここから言えます。

エンゲージメントのあったセッション数も、日別は小数3桁で 1.000 でしたが、週別 1.004、月別 0.998、ページ階層 1.106、ランディング ページ 0.997 と、1の上下に散りました。アナリティクス ヘルプ「アナリティクスのセッションについて」は、エンゲージメントのあったセッション数もセッションの指標として挙げ、セッションとユーザーに関する指標は推定値に基づくと説明しています（開発者向けの精度の表には入っていません）。扱いはセッションと同じです。

足りなくなる切り方もある：端末別・チャネル別のユーザー

デバイス カテゴリで切った合計ユーザー数は、パソコンとスマートフォンの両方で来た人が2つの行に入るので、足すと1を超えるはずの切り方です。当社の13週では 0.995 倍で、1を下回りました。

ユーザーの最初のデフォルト チャネル グループは「ユーザーを最初に獲得した」チャネルで（GA4 ヘルプ）、1人は1つの行にしか入りません。数え方が正確なら 1.000 になる切り方ですが、0.993 倍でした。1を下回る差は、行が重なることでは生まれません。3つの切り方の合計ユーザー数の差は0.3〜0.7%で、上のヘルプの「ほとんどの場合1%未満」の内に収まります。推定値どうしを足した差として扱える大きさで、別の期間の当社のデータで同じ判断をした数値不整合の記事とも同じ扱いです。

ここから言えるのは、「1を下回ったから計測漏れ」「1を超えたから端末をまたぐ人がこれだけいる」とは読めない、ということです。重なりで増える分と、推定のずれで上下する分が一緒に入っているので、比から端末をまたぐ人の数を逆算することはできません。

表の合計行は、行を足した値ではなかった

名前から誤解されやすいのが合計行です。Data API では、行といっしょに合計を返させる指定（metricAggregations の TOTAL）があり、リファレンスはこれを「SUM operator」と説明しています（MetricAggregation）。応答の説明でも totals は「指標を合計した値」です（RunReportResponse）。当社の12本では、合計行は7つの指標すべてで、行を足した値ではなく、ディメンションを付けずに取った1本目の期間の数字と同じでした。測る前の計画でも、合計行はディメンションを付けない応答と一致すると見込んでいて、結果はそのとおりでしたが、リファレンスの「SUM」という説明とは食い違います。

だから、合計行を「行の足し算の検算」に使うと、当社の照会では、ユーザーとセッションの列で期間の数字と合わない切り方がありました。推定値どうしなので、一致する保証もありません。合計行を期間の数字として使う場合も、リファレンスの説明と食い違う動きなので、自分のプロパティで一度、ディメンションを付けずに取った値と比べてからにします。

週報・月報の数字は、期間ごとに1回ずつ取る

Data API で取るなら、dateRanges に週や月の期間を入れ、ディメンションを付けずに送るのが基本です。週ごとの数字を1本で取るなら、ISO 年の ISO 週（isoYearIsoWeek）で切る方法もあります。期間の両端が週の途中なら、端の週は途中までの数になり、週の行を足して13週の数字にできないのは上で見たとおりです（1.026 倍）。GA4 ヘルプの「週」は01〜53の週番号のディメンションで、ISO 年の ISO 週とは別のものです。

すでに日別の足し上げで出した週報があるなら、ユーザー数とセッションの列は、取り直した数字と並べると一致する保証はありません。差し替えるときは「日別を足した値から、期間で数えた値に変えた」と取り方の違いを添えておくと、前の週報と比べる人が迷いません。

まず、自分の週報のユーザー数の列を見直す

手元の週報や月報を開いて、ユーザー数とセッションの列が、日別やページ別の行を足して作られていないかを見てください。足して作っていたら、直近の1週分を期間で1回取り、足した値と並べて比を出します。その比が、ほかの週の数字を取り直すかどうかを決める材料になります。

週報・月報の数字を、指標ごとの取り方まで決めて GA4 から自動で出す仕組みは、当社のマーケティングデータの支援で一緒に作れます。

仕様と項目名は、2026年10月15日に Google アナリティクス ヘルプと Google の開発者向けドキュメントで確かめました。公開サンプルの照会も同じ日です。