GA4のBigQuery ExportとData APIの違い｜数字が合わない理由と使い分け

GA4のレポート値と収集イベントを混同しないための実務ガイド

調査日：2026年9月21日
対象：Google Analytics 4のBigQuery ExportとGoogle Analytics Data API v1
※Admin API、Measurement Protocol、Google広告APIは、必要な範囲を除いて対象外とします。

この記事の結論：BigQuery Exportは収集されたイベントを細かく分析するための出力、Data APIはGA4のレポート定義に沿った集計値を取得するためのAPIです。同じプロパティを見ていても、識別・モデリング・しきい値・(other)・遅延・設定の違いで数字は変わります。公式KPIはData API、独自分析やデータ結合はBigQuery、両方の説明責任が必要なら併用するのが基本です。

先に結論：Data APIは「レポート」、BigQuery Exportは「イベント」

GA4のBigQuery ExportとData APIは、同じGA4プロパティにつながっていても、同じデータを別の形式で返す仕組みではありません。データを見る段階と、集計の責任を持つ側が違います。

• BigQuery Exportは、GA4で収集されたイベントを、イベント行とネストしたフィールドとして保存するための仕組みです。
• Data APIのレポートメソッドは、GA4のレポートで使われるディメンションと指標の集計結果を、プログラムから取得するための仕組みです。
• Data APIのAudience Exportは、レポート行ではなく、オーディエンスに含まれるユーザーのスナップショットを作成・取得する別系統の機能です。通常のrunReportと同じものとして扱いません。

したがって、次のように考えると整理しやすくなります。

最も重要なのは、BigQuery Exportは「GA4レポートの完全な複製」ではないという点です。Googleは、標準レポートやData APIに対して、レポート用識別子、帰属、しきい値、サンプリング、モデリングなどの処理を行います。一方、BigQuery Exportは、GA4が受け取ったイベントを、より細かい粒度で扱うための出発点です。BigQuery Exportの公式説明でも、標準レポートや探索に付加された価値はイベントエクスポートに含まれないと説明されています。

ここでいう「収集データ」は、ブラウザやアプリから送られた通信の完全な生ログという意味ではありません。GA4が受け取り、エクスポート対象として整形・除外したイベントに近いデータです。

そのため、BigQueryで計算した値とData APIの値が一致しないことは、必ずしも実装ミスではありません。

1. データの流れを理解する

両者の違いは、データがどの段階で取り出されるかにあります。

図解1：BigQuery Exportはイベント行に近い出力、Data APIはGA4のレポート処理後の集計値を返します。

厳密には、GA4内部の処理は単純な一本のパイプラインではありません。それでも実務では、次の2行で整理すると迷いにくくなります。

• BigQuery Exportは、イベントを確認し、自社のロジックで再集計するためのデータです。
• Data APIは、GA4がレポートとして定義・集計した値を取得するための窓口です。公式ドキュメントでも、Data APIのレポートデータはGA4のユーザーインターフェースに表示されるデータと一致し、プロパティのレポート用識別子を反映すると説明されています。

つまり、BigQueryでData APIと同じ数字を作るには、GA4の識別・モデリング・帰属・集計ルールまで自分で再現しなければなりません。イベントを読めることと、GA4レポートを複製できることは別です。

2. BigQuery Exportとは何か

2-1. GA4イベントをBigQueryへエクスポートする仕組み

BigQuery Exportは、GA4の管理画面で作られたレポートをファイルに書き出す機能ではありません。GA4が受け取ったイベントを、分析しやすいスキーマでBigQueryへ届ける仕組みです。

GA4プロパティをBigQueryにリンクすると、通常は次のようなデータセットが作られます。

analytics_<property_id>

日次エクスポートでは、次のテーブルが日ごとに作成されます。

events_YYYYMMDD

Streaming Exportを有効にすると、当日の一時的なテーブルが作られます。

events_intraday_YYYYMMDD

events_intraday_YYYYMMDDは当日中に継続更新されます。日次エクスポートも有効にしている場合は、日次テーブルの作成が完了すると削除されるため、当日速報用の一時テーブルとして扱います。日次エクスポートを有効にしていない場合など、設定によって保持され方が異なるため、テーブルの存在だけで確定データと判断しません。

2-2. 何が1行になるのか

通常は、1件のイベントを中心に1行が作られます。代表的なフィールドは次のとおりです。

event_params、user_properties、itemsなどは、繰り返しフィールドやネストしたRECORDで保存されます。Data APIのようにあらかじめ列になったレポートを読むのではなく、UNNESTやサブクエリを使って展開する必要があります。

2-3. BigQuery Exportに含まれるもの、含まれないもの

BigQuery Exportに含まれる代表例は次のとおりです。

• 収集されたイベント
• イベントパラメータ
• ユーザープロパティ
• user_pseudo_idやuser_id
• ページ、画面、商品、取引の情報
• 収集されたUTMやクリック識別子
• Consent Modeの状態
• 利用可能なセッション流入元情報

一方、次のようなGA4のレポート側の付加処理は、そのまま同じ形では含まれません。

• Google Signals由来のデータ
• Consent Modeによる行動モデリング
• モデル化されたキーイベントデータ
• プロパティのレポート用識別子に基づく最終的なユーザー集計
• Data APIで返される集計済みの指標値
• GA4がレポート用に適用した一部の帰属処理

また、GA4にリンクされた商品データなど、GA4がクライアントから受け取るイベントそのものではない付加データは、BigQueryへ再エクスポートされません。

したがって、BigQueryのテーブルを見て「GA4の画面にあるすべての情報が、同じ形で入っている」と考えるのは危険です。

2-4. 導入前に確認する前提

BigQuery Exportは、SQLを書けばすぐ使える分析データではありません。リンク前に、少なくとも次を確認します。

設定方法と権限の詳細は、BigQuery ExportのセットアップとBigQuery Exportの制限をご参照ください。BigQuery Exportは、リンクした時点より前のイベントを自動で埋め戻す仕組みではないため、過去データの扱いも先に決めておきます。

3. Data APIとは何か

3-1. GA4のレポートをプログラムから取得するAPI

Google Analytics Data API v1は、GA4のレポートデータへプログラムからアクセスするためのAPIです。BigQueryのようにイベントを取り出して後から集計するのではなく、GA4側で定義されたディメンションと指標を、レポート行として受け取ります。

Googleの公式ドキュメントでは、Data APIから返るレポートデータはGA4のユーザーインターフェースのデータと一致し、プロパティに設定したレポート用識別子を反映すると説明されています。Data APIの概要

本稿では、runReportなどのレポートメソッドを「Data API」と呼びます。RESTリファレンスはv1betaのページで提供されているため、実装時は採用するクライアントライブラリとメソッドのバージョンを確認します。runFunnelReportは早期プレビュー、properties.audienceExportsはレポート行ではなくオーディエンスユーザーのエクスポートです。

代表的なメソッドは次のとおりです。

本稿で「Data API」と呼ぶ中心は、runReportなどのレポートメソッドです。Audience Exportはユーザーのスナップショットを扱う別系統の機能、プレビュー中のメソッドは仕様変更の可能性がある機能として、通常のレポート取得と分けて考えます。

3-2. Data APIのレスポンスはイベント行ではない

Data APIのrunReportは、通常、次のような「ディメンション値の組み合わせごとの指標」を返します。

{
  "property": "properties/123456789",
  "dateRanges": [
    {
      "startDate": "2026-09-01",
      "endDate": "2026-09-20"
    }
  ],
  "dimensions": [
    {"name": "date"},
    {"name": "sessionDefaultChannelGroup"}
  ],
  "metrics": [
    {"name": "sessions"},
    {"name": "activeUsers"},
    {"name": "keyEvents"},
    {"name": "totalRevenue"}
  ]
}

レスポンスは、日付とチャネルの組み合わせごとに、セッション数やアクティブユーザー数などを返します。イベント単位のevent_timestamp、任意のイベントパラメータ、ユーザーごとの行動履歴を直接取得するAPIではありません。

3-3. Data APIはプロパティのレポート用識別子を尊重する

Data APIは、プロパティに設定されているレポート用識別子を反映します。

• Blended：User-ID、デバイスID、モデリングを利用
• Observed：User-ID、デバイスIDを利用
• Device based：デバイスIDのみを利用

このため、Data APIのユーザー数は、プロパティのReporting identityの設定によって変わります。一方、BigQuery Exportは、Data APIの最終的なレポート用ユーザー集計を保存したものではありません。レポート用識別子の公式説明では、混合型はUser-ID・デバイスID・モデル化データを順に評価し、デバイスベースはデバイスIDのみを使うと整理されています。

4. 比較表：BigQuery ExportとData APIの違い

まずは、どちらが優れているかではなく、どの問いに答える仕組みかで比較します。

5. 数字が合わない主な理由

数字のズレは、「BigQueryが間違っている」「Data APIが間違っている」と一言で片づけられません。比較している段階が違えば、同じプロパティから出した値でも差が出ます。

図解2：乖離は、計測の入口だけでなく、識別・モデリング・表示制御・時間と設定の各層で生まれます。

5-1. レポート用識別子とUser-ID

同じ人がPCとスマートフォンを使えば、BigQueryでは複数のuser_pseudo_idとして記録されることがあります。Data APIでは、プロパティのReporting identityに応じてUser-ID・デバイスID・モデリングを使うため、単純なID件数とは一致しません。

現在のReporting identityにGoogle Signalsは含まれません。古い解説の「Google Signalsでレポートのユーザー数を重複除去する」という説明を、そのまま現在の比較に使わないようにしてください。識別方法は現在の公式仕様で確認します。

BigQuery側でも、収集したuser_idを使ってログインユーザーを端末横断で集計できます。その際は未ログイン時の扱いやIDの優先順位を定義します。

5-2. Consent Modeとモデルデータ

Consent ModeでユーザーがAnalyticsの保存を拒否した場合、GA4のレポート側では、条件を満たすプロパティに対して行動モデリングやキーイベントモデリングが使われることがあります。

BigQueryには、収集されたCookieレスのpingが含まれる場合があります。しかし、そのpingからGA4がレポート側で生成したモデル値が、そのままイベント行として追加されるわけではありません。

そのため、Consent Modeを実装しているサイトでは、次のような差が生じます。

• Data APIのアクティブユーザーと、BigQueryのID集計が異なります
• Data APIのキーイベント数と、BigQueryでイベント名を数えた値が一致しません
• セッションやユーザーの重複除去のされ方が異なります

5-3. サンプリング

Data APIでは、大規模なイベントデータを扱うレポートでサンプリングが発生する可能性があります。イベントレベルのクエリ上限や、標準プロパティ・360での違いは変更される可能性があるため、実装時はデータのサンプリングに関する公式仕様を確認します。

サンプリングが適用された場合、Data APIのレスポンスにはsamplingMetadatasが含まれます。サンプルに使われたイベント数と、対象データ全体のイベント数を確認できます。

BigQueryの日次エクスポートは、GA4レポートのサンプリングを通らないイベントデータです。ただし、BigQuery側でAPPROX_COUNT_DISTINCTなどの近似関数を使えば、当然ながら自分のクエリにも近似誤差が入ります。

5-4. HLL++によるユニーク数の近似

Data APIやGA4のレポートで表示される一部のユニーク指標は、常に単純な厳密カウントではありません。Google Analyticsは、性能と精度のバランスのため、HyperLogLog++（HLL++）を使ってユニーク数を推定します。

一方、BigQueryでは、次のような厳密カウントを行えます。

COUNT(DISTINCT user_pseudo_id)

この結果が、Data APIのactiveUsersやsessionsと少し違っていても、すぐにタグの二重発火と判断してはいけません。識別子の違い、HLL++、サンプリング、モデリング、集計期間を順番に確認する必要があります。

5-5. 高カーディナリティによる(other)行

Data APIでは、ページパス、検索語句、カスタムパラメータなど、値の種類が多いディメンションを組み合わせると、レポートの行数上限を超えることがあります。

この場合、頻度の低い値が(other)にまとめられます。

BigQueryでは、元のイベント行から自分で集計できるため、Data APIの(other)行を経由した情報損失は発生しません。ただし、BigQuery側で適切な期間・粒度・フィルタを設計しなければ、別の意味で集計ミスは起きます。

Data APIのレスポンスでは、dataLossFromOtherRowを確認できます。(other)行が結果に表示されていない場合でも、入力となった集計データに情報損失があれば、このフラグが立つ可能性があります。

5-6. しきい値はGoogle Signalsとは別の仕組み

ユーザー属性、インタレスト、検索語句など、個別ユーザーの身元や機微な情報を推測できる可能性があるデータには、GA4のレポートやData APIでしきい値が適用されることがあります。

Data APIでは、レスポンスメタデータのsubjectToThresholdingを確認できます。

しきい値は、少数のユーザーの特定につながる表示を抑制する仕組みです。Google Signalsを使っているかだけで適用の有無を判断せず、リクエストした項目とレスポンスメタデータを確認します。BigQueryにはGoogle Signals由来のデータが含まれず、APIで非表示になった属性を復元できるとは限りません。しきい値の公式説明

5-7. 遅延イベント、タイムゾーン、エクスポート設定

日次テーブルは、当日のイベントがすべて確定した瞬間に固定されるわけではありません。Firebase SDKやMeasurement Protocolから遅れて届いたイベントなどに対応するため、日次テーブルはイベント日から通常、テーブルの日付の3日後まで更新されます。たとえば1日分のテーブルが4日に更新される場合があるため、比較では「少なくとも72時間より古い日」を選ぶと安全です。テーブル更新スケジュール／Googleの比較解説

また、次の設定ミスも頻出します。

• GA4のプロパティタイムゾーンと、BigQueryクエリで使うUTCの扱いが違います
• BigQueryリンクで特定のデータストリームを除外しています
• 特定のイベントをBigQuery Exportから除外しています
• 日次テーブルとevents_intraday_YYYYMMDDを重複して集計しています
• event_dateとevent_timestampを同じタイムゾーンの値だと思っています
• GA4側のデータフィルタとBigQuery側の抽出条件が一致していません
• 標準プロパティで日次エクスポート上限を超えています

比較は、当日や翌日の速報値ではなく、少なくとも遅延イベントの影響が落ち着いたデータで行います。events_intraday_YYYYMMDDと日次テーブルを同じ期間で重ねて数えないことも重要です。

6. 指標ごとの違い

「数字が合わない」と言われたとき、最初に確認すべきなのは指標名ではなく定義です。同じ「ユーザー」「セッション」「売上」でも、GA4が計算したレポート指標と、BigQueryのイベントから再構成した指標では意味が変わります。

6-1. イベント数

イベント数は、両者を最初に比較しやすい指標です。ただし、完全一致が当然とは限りません。まずはユーザーやセッションのような派生指標ではなく、イベント総数から確認します。

比較する場合は、次の条件をそろえます。

1. 同じプロパティを見ます
2. 同じ日付とタイムゾーンを使います
3. 同じデータストリームを対象にします
4. BigQuery Exportから除外したイベントをGA4側でも除外します
5. events_YYYYMMDDの日次テーブルで比較します
6. 遅延イベントの影響が少ない日付を使います

Googleの比較手順では、設定をそろえたうえで、Analyticsのイベント数とBigQueryの行数を比較し、2〜5%程度の差は想定されるとしています。公式の比較手順にあるこの数字は、すべての指標に適用できる許容誤差ではなく、あくまでイベント総数の比較に関する目安です。

6-2. アクティブユーザー

BigQueryで単純に次を実行しても、Data APIのactiveUsersとは一致しないことがあります。

COUNT(DISTINCT user_pseudo_id)

BigQueryの現在のスキーマには、日次テーブルでis_active_userが提供されています。比較用の基本形は次のようになります。

SELECT
  COUNT(DISTINCT user_pseudo_id) AS active_users
FROM `project_id.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260920'
  AND is_active_user = TRUE;

ただし、これでも次の差は残ります。

• Data APIのReporting identity
• Consent Modeのモデリング
• HLL++による近似
• しきい値や権限制御

「BigQueryで厳密に数えたID数」と「Data APIのGA4レポート上のアクティブユーザー」は、同じ列に入れず、異なる定義の指標として管理する方が安全です。

6-3. セッション数

BigQueryでセッション数を作るには、一般にuser_pseudo_idとga_session_idの組み合わせを使います。

WITH events AS (
  SELECT
    user_pseudo_id,
    (
      SELECT value.int_value
      FROM UNNEST(event_params)
      WHERE key = 'ga_session_id'
    ) AS ga_session_id
  FROM `project_id.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260920'
)
SELECT
  COUNT(*) AS sessions
FROM (
  SELECT DISTINCT user_pseudo_id, ga_session_id
  FROM events
  WHERE user_pseudo_id IS NOT NULL
    AND ga_session_id IS NOT NULL
);

次の点に注意が必要です。

• session_startイベントの件数を数えるだけでは、Data APIのsessionsと同じになるとは限りません
• セッションが日付をまたいでも、日ごとに足し上げると二重計上する可能性があります
• Consent ModeやID欠損の影響を受けます
• Streaming Exportでは、同じセッションのレコードが複数のエクスポート周期にまたがって入ることがあります
• セッション流入元は、当日速報と日次確定で利用できる情報が違います

6-4. キーイベント

Data APIのkeyEventsは、GA4のプロパティ設定・レポート処理に基づく指標です。

BigQuery Exportで同じ値を作る場合、まず対象のイベント名を確定し、イベント数やユーザー数を自分で定義する必要があります。たとえば、generate_leadイベントをキーイベントとして扱っているなら、BigQueryではevent_name = 'generate_lead'を対象にします。

ただし、次の点に注意します。

• GA4側でキーイベントに指定したかどうかは、BigQueryのイベント行に単純なフラグとして現れるわけではありません
• イベントの重複除去やカウント方法の設定があります
• Consent Modeによるモデル化されたキーイベントは、BigQueryのイベント行には現れません
• Data APIの広告・アトリビューションレポートでは、イベント数と貢献度の指標を混同しません

6-5. 収益

BigQueryでは、ecommerce.purchase_revenue、ecommerce.transaction_id、items.item_revenueなどを使って、取引・商品単位の分析ができます。

Data APIでは、totalRevenue、purchaseRevenue、ecommercePurchasesなど、GA4で定義された指標を取得します。

違いを調べるときは、次を分解します。

• 購入イベントの件数
• 取引IDのユニーク数
• イベントの売上
• 商品単位の売上
• 払い戻し
• 通貨換算
• キーイベント・広告レポート上の貢献度

「購入イベントの値」と「Data APIの収益指標」は、名前が似ていても同じ計算式とは限りません。

6-6. 流入元・キャンペーン

現在のBigQuery Exportには、次のような流入元情報があります。

• collected_traffic_source：イベントとともに収集されたUTM、GCLIDなど
• traffic_source：ユーザー獲得に関する情報
• session_traffic_source_last_click：利用可能な場合のセッション単位のラストクリック情報

以前の「BigQueryには流入元がない」という説明は不正確です。現在のスキーマには、Google Ads、手動キャンペーン、クロスチャネル、SA360、DV360、CM360などのセッション流入元フィールドがあります。

ただし、BigQuery Exportの流入元フィールドがあることと、Data APIの広告・アトリビューションレポートを完全に再現できることは別問題です。

• Data APIはGA4のレポート定義・帰属設定を反映します
• BigQueryは収集情報とエクスポートされたセッション情報を使って分析します
• データドリブンアトリビューションによるキーイベントの貢献度を、単純なラストクリック列から再現することはできません
• 新しいGoogle Adsイベントの一部は、広告側の処理が終わる前にData Not Availableになることがあります
• BigQuery ExportにはwBRAID・gBRAID識別子が含まれません

流入元分析をBigQueryで行う場合は、「どの広告がセッションを開始したか」「どの広告にキーイベントの貢献度を配分したか」「収集時点のUTMは何だったか」を別の問いとして設計する必要があります。

7. 更新速度と完全性の違い

速く見えるデータが、必ずしも確定したデータとは限りません。速報性と完全性は別の軸で評価します。

7-1. Data APIのRealtime

Data APIのrunRealtimeReportでは、送信されたイベントが通常数秒後にリアルタイムレポートへ表示されます。通常は直近30分、360では最大60分のデータが対象となります。Realtimeは確定値を長期保存する仕組みではなく、直近の状況確認に使います。

これは長期間の確定データを取得するためのAPIではありません。直近の状況確認、イベント発火確認、キャンペーン開始直後の監視などに使います。

7-2. BigQuery Streaming Export

Streaming Exportは、当日のデータを数分以内にBigQueryへ届けます。イベント単位の監視や障害検知には便利ですが、日次エクスポートの代わりとして扱うものではありません。

しかし、次の制約があります。

• ベストエフォートであり、完全性のSLOはありません
• イベントの遅延やアップロード失敗による欠落があり得ます
• 新規ユーザー・新規セッションのユーザーアトリビューション情報が含まれません
• 既存ユーザーのユーザーアトリビューション処理にも約24時間かかることがあります
• events_intraday_YYYYMMDDは日次確定テーブルではありません

したがって、Streaming Exportを「リアルタイムの完全な正本」として扱うのは危険です。

7-3. BigQuery日次エクスポート

日次エクスポートは、速報値ではなく、前日のサンプリングされていないイベントデータを取得する用途に向いています。

• エクスポート時刻は固定保証されません
• プロパティのタイムゾーンを基準に処理されます
• 遅延イベントにより、イベント日から通常、テーブルの日付の3日後まで更新されます。たとえば1日分のテーブルが4日に更新される場合があります
• ユーザーアトリビューションなど、一部のデータには遅延があります
• 新しい日次テーブルを確認しただけで、最終確定と判断しません

7-4. 360の毎日（高頻度）エクスポート

Analytics 360では、Fresh Dailyと呼ばれることがある「毎日（高頻度）エクスポート」を利用できます。公式資料では、データは通常午前5時までに届き、1日を通して通常60分以内のバッチで更新されると説明されています。毎日（高頻度）エクスポートの公式仕様

Streamingより完全性を重視しており、通常の日次エクスポートより早くデータを取得できる方式です。ただし、以下の点は残ります。

• 360専用
• BigQueryの課金設定が必要
• モデリングではなく、観測されたラストクリックを使います
• Google Adsの帰属処理より先に届くと、Data Not Availableが残る場合があります

8. 費用・上限・運用制約

費用の発生場所も、両者を選ぶときの重要な違いです。BigQueryは保存・クエリ・ストリーミングの設計が中心になり、Data APIは呼び出し回数やレポートの重さ、同時実行数の管理が中心になります。

8-1. BigQuery Exportの制約

標準プロパティでは、日次のBigQuery Exportに1日100万イベントの上限があります。継続的に超えると日次エクスポートが一時停止され、過去日のエクスポートが再処理されない場合があります。BigQuery Exportの上限と方式

Streaming Exportにはイベント数の上限はありませんが、完全性が保証されるわけではありません。

360では、日次エクスポートの上限は1日200億イベントとされています。実際の契約・プロパティサイズ・選択しているエクスポート方式によって扱いは変わるため、導入前に公式の最新仕様を確認する必要があります。

費用は主に次の2つです。

• BigQueryのストレージ料金
• BigQueryのクエリ処理料金

Streaming Exportには追加費用が発生します。GoogleのBigQuery Exportヘルプでは、ストリーミングデータ1GBあたり0.05ドル、1GBはイベント約60万件に相当するという目安が示されています。ただし、イベントサイズで変動します。

8-2. Data APIの制約

Data APIでは、BigQueryのようにクエリしたデータ量に応じたスキャン料金を管理するのではなく、主にAPIのトークン割当と同時実行数が制約になります。すべてのリクエストに呼び出し元のGoogle Cloudプロジェクトが必要で、Core・Realtime・Funnelなどメソッドのカテゴリごとに割当が分かれます。Data APIの制限と割り当て

標準プロパティのCoreメソッドでは、現在の公式ドキュメント上、次の上限が設定されています。

runReportは、指定しない場合のデフォルトが10,000行で、1回のリクエストで最大250,000行まで返します。行数が多い場合はoffsetとlimitを使ってページングします。

APIを使った定例レポートでは、次のような設計が必要になります。

• 同じレポートを毎回フル取得しません
• 必要なディメンションと指標だけを取得します
• 複数レポートはbatchRunReportsでまとめます
• 日次スナップショットを保存し、再取得回数を抑えます
• returnPropertyQuota=trueを付け、レスポンスのpropertyQuotaで割当状況を監視します
• 429や一時的なエラーに対してリトライを実装します

9. 履歴データと保存の違い

「過去のGA4をどこまで残せるか」と「過去のレポートを後から取得できるか」は同じ問題ではありません。BigQueryはリンク後のイベントを自社で保存し、Data APIはGA4側に残るレポート値を取得します。

BigQuery Exportは「リンク後に貯め始める」

BigQueryリンクが完了すると、通常24時間以内にデータが流れ始めます。日次エクスポートでは、前日のデータが日次テーブルとして作成されます。

したがって、BigQueryを後から有効にしても、過去のGA4イベントが自動的にすべてBigQueryへ戻ってくるとは考えない方がよいでしょう。過去データが必要な場合は、Data APIで取得できる集計値、既存のエクスポート、広告媒体やCRMなど別のデータソースを確認します。

Data APIはレポートデータを返すが、生データを保存してくれない

Data APIでは過去期間のレポート値を取得できます。ただし、どの期間まで何が取得できるかは、指標・ディメンション・レポート種別・処理状況・データ保持の影響を受けます。取得できることと、イベント単位の履歴が復元できることは別です。

GA4のデータ保持設定は、ユーザー単位・イベント単位のデータに適用される一方、標準の集計レポートには影響しないと説明されています。標準プロパティでは、ユーザー単位とキーイベントのデータ保持は2か月または14か月、それ以外のイベントデータも2か月または14か月から選びます。Analytics 360では、イベントデータに26か月・38か月・50か月を選べる場合があります。年齢・性別・インタレストカテゴリは設定にかかわらず2か月です。データ保持の公式仕様

なお、この保持設定は標準の集計レポートには影響せず、データ探索やファネルレポートなどの非集計レポートに影響します。Data APIはGA4のレポートデータにアクセスしますが、すべての指標・ディメンションで無期限の詳細データが取れるという意味ではありません。

Data APIのレスポンスには、保持期間などを理由とするデータ切り捨て情報を返すdataTruncationReasonsがあります。履歴データを使う場合は、値だけでなくメタデータも保存するべきです。

一方、BigQueryに保存したデータは、BigQuery側のテーブル、パーティション、ストレージ、アクセス制御、削除ポリシーを自社で管理します。GA4の画面で後から見られるかどうかとは別に、データ基盤としての保存設計が必要になります。

10. Data APIのレスポンスメタデータを必ず確認する

Data APIの数値だけを保存すると、その値がどのような状態で返されたか分からなくなります。runReportなどのレスポンスに含まれるmetadataと、レスポンス本体のpropertyQuotaを分けて保存します。propertyQuotaはResponseMetaDataのフィールドではなく、リクエストでreturnPropertyQuota=trueを指定したときに返される割当情報です。runReportの公式リファレンス

特に、定例レポートで「前月比が急に変わった」場合は、データ本体だけでなく、これらのメタデータが変わっていないか確認します。

11. 実務での使い分け

使い分けは、機能の多さではなく「その数字を何のために使うか」で決めます。

図解3：出力経路は優劣で選ばず、公式値・独自分析・乖離監査のどこに使うかで分けます。

迷ったときの基準：GA4の画面や社内の公式KPIと一致させたいならData API、イベントの中身を調べたり別データと結合したりするならBigQueryです。両方が必要なら、同じ指標名で混ぜずに併用します。

Data APIを選ぶべきケース

• GA4の標準レポートと同じ定義で週次・月次レポートを作る
• GoogleスプレッドシートやBIツールへGA4指標を定期連携する
• sessions、activeUsers、keyEvents、totalRevenueなど、GA4の指標をそのまま使う
• GA4のReporting identityやチャネルグループを反映したい
• 取得したい行数が少なく、APIのクォータに収まる
• イベント単位の監査や個別ユーザー行動が不要

BigQuery Exportを選ぶべきケース

• 任意のイベントパラメータを分析したい
• ユーザー、セッション、イベント、商品をまたいで分析したい
• CRM、受注、会員、問い合わせ、広告費、商品マスタと結合したい
• 自社のセッション定義やアトリビューションモデルを作りたい
• GA4の標準レポートでは表現できないファネルや行動パスを作りたい
• 毎日の欠測、急増、ゼロ、タグ不具合を自動監視したい
• GA4のデータを長期保存し、後から再集計したい
• APIの行数・クォータ制約を避けたい

両方を使うべきケース

多くの企業では、どちらか一方に寄せるより、役割を分けて併用する方がよいでしょう。

ここで重要なのは、BigQueryを無条件に「正解」としないことです。経営会議でGA4の画面と同じ数字を使うなら、Data APIの値を公式KPIとして採用した方が説明しやすくなります。逆に、GA4の標準定義では不十分な分析をするなら、BigQueryで独自定義を作り、指標名と計算式を明示します。

12. GA4とBigQueryを比較する手順

比較の目的は、必ず同じ数字にすることではありません。まず同じ条件で比べ、差が仕様によるものか、計測やSQLの不具合によるものかを切り分けることが目的です。

図解4：比較対象の定義から始め、最後に独自指標の名前を分けて保存します。

Step 1：比較対象を明確にする

「ユーザー」「セッション」「コンバージョン」「売上」は、それぞれ複数の定義があります。

• Data APIの指標名
• BigQueryで使うフィールド
• 集計単位
• 複数期間の扱い
• IDの優先順位
• モデルデータを含めるか

を先に文書化します。

Step 2：設定をそろえる

• 同じGA4プロパティ
• 同じデータストリーム
• 同じプロパティタイムゾーン
• 同じ日付範囲
• 同じデータフィルタ
• BigQuery Exportで除外したイベントの扱い
• 比較時のReporting identity

公式の比較手順では、BigQueryとの比較時にGA4のReporting identityをDevice IDへ合わせることが案内されています。比較が終わったら、元の設定へ戻します。

Step 3：確定データで比較する

当日データ、前日データ、Streaming Exportを最初の検証対象にしません。遅延イベントや流入元処理が残っている可能性があるため、まずは少なくとも72時間より古い日次テーブルから始めます。日次テーブルもイベント日から通常、テーブルの日付の3日後まで更新されるため、比較日を固定した後に再確認します。

Step 4：Data APIの品質フラグを確認する

samplingMetadatas、dataLossFromOtherRow、subjectToThresholding、dataTruncationReasonsを確認します。クォータも確認する場合は、リクエストにreturnPropertyQuota=trueを指定し、レスポンス本体のpropertyQuotaを読みます。いずれかが示されているなら、単純な数値比較を続けず、差異の理由と取得時点を記録します。

Step 5：BigQueryの行数から確認する

いきなり複雑なSQLでユーザーやセッションを作らず、まず日次テーブルの行数を確認します。

SELECT COUNT(*) AS exported_event_rows
FROM `project_id.analytics_123456789.events_20260901`;

行数がGA4のイベント総数と大きく違う場合、まずリンク、ストリーム除外、イベント除外、日付、タイムゾーン、エクスポート上限を確認します。

Step 6：独自指標はGA4指標と別名にする

たとえば、BigQueryで厳密なID数を数えたなら、レポート上は次のように区別します。

• GA4 Active Users
• BQ Exact Pseudo Users
• GA4 Sessions
• BQ Reconstructed Sessions

同じ「ユーザー数」「セッション数」と呼ぶと、後から数字が合わなくなったときに原因を追えません。

13. よくある誤解

誤解1：BigQuery ExportはGA4画面の完全なバックアップである

そうとは限りません。BigQueryは収集データに近いイベントエクスポートであり、Google Signals、モデリング、レポート側の付加処理を含む完全なレポートバックアップではありません。

誤解2：Data APIはイベント単位のデータを取得するAPIである

そうではありません。Data APIはディメンションと指標によるレポート結果を返します。個々のイベントパラメータやユーザーの行動履歴を調べるならBigQueryが必要になります。

誤解3：BigQueryで数えた値が必ず正しい

そうではありません。BigQueryは細粒度データを扱えますが、ユーザーID、セッション、キーイベント、アトリビューションの定義を自分で決める必要があります。計算が厳密でも、問いの定義がGA4と違えば比較対象にはなりません。

誤解4：Data APIの値はいつでも完全な実数である

そうとは限りません。Data APIにはサンプリング、HLL++、(other)、しきい値、データ切り捨てがあり得ます。レスポンスメタデータを確認する必要があります。

誤解5：Streaming Exportは完全なリアルタイム正本である

そうではありません。数分以内に届きますが、ベストエフォートであり、欠落があり得ます。新規ユーザーや新規セッションの流入元情報にも制約があります。

誤解6：user_pseudo_idは人を表すIDである

そうではありません。WebではクライアントIDなど、アプリではアプリインスタンスIDなどに相当する仮名化IDであり、同じ人が複数のIDになることがあります。

誤解7：session_startを数えればGA4のセッション数になる

必ずしもなりません。GA4のセッション指標、ID欠損、日付またぎ、遅延イベント、セッション重複を考慮する必要があります。

誤解8：BigQueryを有効にすれば過去データも自動で入る

基本的に、BigQueryリンク後にエクスポートされるデータを前提にします。過去データの取得可能性はData APIや既存データソースを別途確認します。

誤解9：BigQueryの流入元情報は古い仕様のまま存在しない

現在のスキーマには、収集時点の流入元だけでなく、利用可能なセッション単位のラストクリック情報もあります。ただし、Data APIのレポート・アトリビューション値を完全に再現するという意味ではありません。

誤解10：同じGA4プロパティなら、どの出力経路でも同じ数字になる

収集データ、レポート処理、識別、モデリング、帰属、集計、遅延のどの段階を見ているかが違うため、同じになるとは限りません。

14. 推奨する実装方針

実務では、次の4層に分けると運用しやすくなります。

1. 収集監視層

BigQueryでイベント数、必須パラメータ、ユーザーID、Consent Modeの状態、欠測、急変を監視します。

2. GA4公式レポート層

Data APIで、経営KPIやGA4の標準指標を日次スナップショットします。取得時にレスポンスメタデータも保存します。

3. 独自分析層

BigQueryで、CRM、受注、広告費、商品データと結合し、独自のセッション・顧客・LTV・アトリビューションテーブルを作ります。

4. 説明層

「GA4準拠の値」と「自社定義の値」を同じダッシュボードに混在させないようにします。値の横に、データソースと計算定義を表示します。

まとめ

GA4のBigQuery ExportとData APIは、競合する選択肢ではありません。

• Data APIは、GA4のレポート定義に沿った値を取得するためのものです
• BigQuery Exportは、GA4の収集データに近いイベントを細かく分析するためのものです
• Google Signals、Consent Modeのモデリング、サンプリング、HLL++、(other)、しきい値、遅延イベントによって数字は変わり得ます
• GA4画面と一致させたいKPIにはData API、独自分析やデータ結合にはBigQueryを使います
• 両者を比較するときは、Reporting identity、タイムゾーン、対象期間、エクスポート設定、レスポンスメタデータを確認します

最も避けるべきなのは、BigQueryの値とData APIの値を、定義を確認せずに同じKPIとして扱うことです。

「GA4のレポートとしての数字」と「収集イベントから自社ロジックで計算した数字」は、どちらが正しいかではなく、何を測るための数字かが違います。この前提を社内で共有しておくことが、GA4データ基盤を安定運用する第一歩になります。

関連記事

• GA4に参照元は3つある｜Data APIとBigQueryで数値がズレる理由
• BigQueryの広告データを監視する｜欠測・ゼロ・急変をGASで毎朝検知する

参考資料

• BigQuery Export｜Analytics Help
• GA4 BigQuery Export スキーマ｜Analytics Help
• BigQuery Exportの設定・上限・料金｜Analytics Help
• Google Analytics Data APIの概要
• Data APIの制限と割り当て
• Method: properties.runReport
• ResponseMetaData
• Audience Exports（v1beta）
• GA4のレポートとBigQuery Exportを比較する
• Bridge the gap between the Google Analytics UI and BigQuery export
• Reporting identity
• データのサンプリングについて
• GA4の「(other)」行について
• GA4のデータのしきい値について
• データの保持
• BigQueryの毎日（高頻度）エクスポート（Analytics 360）