GA4とBigQueryの連携方法を完全解説【2026年最新版】

GA4のデータをもっと深く分析したい、でもGA4の管理画面だけでは限界を感じていませんか?

ユーザー単位の詳細な行動分析やLTV計算、他システムとのデータ統合など、GA4の標準機能では実現できない高度な分析ニーズが日々増えています。その解決策がGA4とBigQueryの連携です。

本記事では、GA4とBigQueryを連携する具体的な手順から、実務で使える分析例、よくあるトラブル対処法まで、初心者の方にもわかりやすく完全解説します。この記事を読めば、BigQueryを活用した次世代のデータ分析環境を構築できるようになります。

それでは、GA4×BigQuery連携の全てを見ていきましょう。


目次

GA4とBigQueryを連携する3つのメリット

GA4とBigQueryを連携することで、GA4単体では実現できない高度なデータ分析が可能になります。ここでは連携によって得られる3つの主要なメリットを解説します。

GA4では不可能な柔軟なデータ分析が実現

BigQueryとの連携により、生のイベントデータをSQLで自由に集計・加工できるようになります。

GA4の管理画面では事前定義されたレポートや探索機能に限定されますが、BigQueryではイベント1件=1行として格納された生データに直接アクセスできます。このため、ユーザー単位の詳細な行動履歴分析や、独自のKPI定義に基づいた集計、複雑な条件でのセグメント作成など、GA4の標準機能では不可能だった柔軟な分析が実現します。

例えば、特定のユーザーが最初の訪問から購入に至るまでにどのようなページを何回閲覧したか、どのイベントを何回発火させたかといった詳細な行動パターンを時系列で追跡できます。また、LTV(顧客生涯価値)分析では、ユーザーごとの累計購入金額や購入頻度を自由に集計し、コホート分析と組み合わせることも可能です。

さらに、カスタムファネル分析では、自社ビジネス特有の転換ステップを定義し、各ステップでの離脱率や所要時間を詳細に可視化できます。SQLの知識があれば、分析の自由度は無限大に広がります。

他システムデータとの統合分析が可能に

BigQueryでは、GA4データと他のビジネスデータを統合し、横断的な分析ができます。

CRMシステムの顧客データ、オフラインの購買データ、広告配信プラットフォームのコストデータなど、様々なデータソースをBigQuery上で結合できます。これにより、Webサイトでの行動データとビジネス成果を紐付けた高度な分析が可能になります。

特にB2B企業では、Webサイトでのリード獲得からMQL(Marketing Qualified Lead)、SQL(Sales Qualified Lead)を経て受注に至るまでの一連のプロセスを、GA4データとCRM/MAツールのデータを統合して分析できます。どの流入チャネルやコンテンツが最終的な受注に貢献しているかを正確に把握し、マーケティングROIを最適化できます。

また、Google広告やFacebook広告などの広告費データとGA4のコンバージョンデータを結合すれば、真のROAS(広告費用対効果)やCPA(顧客獲得単価)を算出できます。データサイロを解消し、ビジネス全体を俯瞰した意思決定が可能になります。

データの長期保存と高度な可視化

BigQueryでは、GA4の保存期間制限を超えた長期データ保管と、高度な可視化が実現します。

GA4の標準プロパティではデータ保存期間が最大14ヶ月(イベントレベルデータは2ヶ月)に制限されますが、BigQueryにエクスポートしたデータは永続的に保存できます。年単位のトレンド分析や、過去数年分のデータを使った季節性分析など、長期的な視点でのデータ活用が可能になります。

Looker Studio(旧Google データポータル)との連携では、BigQueryをデータソースとして、リアルタイム更新されるダッシュボードを構築できます。経営層向けのKPIダッシュボードや、マーケティングチーム向けの施策効果レポートなど、用途に応じた高度な可視化が実現します。

また、TableauやPower BIなどのBIツールとも連携可能で、組織全体でのデータ民主化を推進できます。さらに、BigQuery MLを活用すれば、機械学習モデルによる予測分析(解約予測、購入確率予測など)も実装でき、データドリブンな意思決定を次のレベルへ引き上げられます。


GA4からBigQueryへエクスポートできるデータの種類

GA4からBigQueryへのデータエクスポートには、用途に応じて3つの方式があります。それぞれの特徴と使い分けを理解することが重要です。

日次エクスポート(Daily Export)

日次エクスポートは、前日の全イベントデータを1日1回まとめて書き出す方式です。

毎日深夜から早朝にかけて、前日分(0時〜23時59分59秒)のイベントデータがBigQueryのevents_YYYYMMDD形式のテーブルに自動的にエクスポートされます。例えば、2025年1月5日のデータはevents_20250105というテーブル名で格納されます。

標準GA4プロパティでは、1日あたり100万イベントまでエクスポート可能です。この上限を超える場合は、GA4管理画面でイベントフィルタを設定し、重要なイベントのみをエクスポートする設定が必要です。一方、GA4 360プロパティでは、イベント数の制限はありません。

日次エクスポートは最も基本的な方式で、コストも抑えられます。前日までのデータを翌日以降に分析する用途であれば、この方式で十分です。週次レポートや月次レポートの作成、トレンド分析など、リアルタイム性が求められない分析に適しています。

ストリーミングエクスポート(Streaming Export)

ストリーミングエクスポートは、当日データをほぼリアルタイムでBigQueryに反映する方式です。

イベント発生から数分以内に、events_intraday_YYYYMMDD形式のテーブルにデータが書き込まれます。例えば、2025年1月5日の当日データはevents_intraday_20250105に随時追加されていきます。このテーブルは日中何度も更新され、当日のデータを準リアルタイムで確認できます。

翌日になると、前日分の確定データがevents_YYYYMMDDテーブルに移行されます。そのため、events_intraday_テーブルは当日の暫定データ用、events_テーブルは確定データ用という位置付けになります。

ストリーミングエクスポートは、1GBあたり0.05ドルの追加料金が発生します。リアルタイムモニタリングが必要なキャンペーン期間中や、異常値の早期検知が求められる場合に有効ですが、コストと必要性を天秤にかけて判断する必要があります。通常は日次エクスポートのみで十分なケースが多いでしょう。

GA4 360限定の高頻度エクスポート

GA4 360では、「毎日(高頻度)」オプションで1日を通じて高速・高頻度にデータを更新できます。

この方式は、ストリーミングエクスポートよりもさらに高頻度でデータが更新され、エンタープライズレベルの大規模サイト向けの機能です。リアルタイムに近い精度で当日データを確認しながら、確定データとしてのevents_YYYYMMDDテーブルも高頻度で更新されます。

大規模ECサイトのセール期間中や、大量のトラフィックが発生するキャンペーン実施時など、即座にデータを確認して施策を調整したい場合に適しています。ただし、GA4 360は有料版(年間150万円〜)のため、費用対効果を慎重に検討する必要があります。

通常の企業サイトやメディアサイトであれば、標準プロパティの日次エクスポート、必要に応じてストリーミングエクスポートを追加する形で十分な分析環境を構築できます。


GA4とBigQueryの連携手順【画像付き完全ガイド】

GA4とBigQueryの連携は、4つのステップで完了します。初めての方でも迷わず設定できるよう、各ステップを詳しく解説します。

ステップ1: GCPプロジェクトの準備

まず、Google Cloud Platform(GCP)のアカウントとプロジェクトを準備する必要があります。

Google Cloud Platform(https://console.cloud.google.com/)にアクセスし、Googleアカウントでログインします。初めて利用する場合は、利用規約への同意が求められます。GCPコンソールにアクセスできたら、画面上部のプロジェクト選択ドロップダウンから「新しいプロジェクト」を選択します。

プロジェクト名は、用途が分かりやすい名前(例:「GA4-BigQuery-Analytics」など)を設定します。組織に所属している場合は組織を選択し、個人利用の場合は「組織なし」のままで構いません。プロジェクトIDは自動生成されますが、カスタマイズも可能です。

次に、請求先アカウント(Billing)の設定が必要です。画面左上のメニューから「お支払い」→「請求先アカウントをリンク」を選択し、クレジットカード情報を登録します。BigQueryには無料枠(月1TBのクエリまで無料、ストレージ10GBまで無料)がありますが、請求先アカウントの登録は必須です。初回登録時には300ドル分の無料クレジットが付与される場合があります。

請求先アカウントの設定が完了すれば、GCPプロジェクトの準備は完了です。このプロジェクトIDを後ほどGA4側の連携設定で使用します。

ステップ2: BigQuery APIの有効化

作成したGCPプロジェクトで、BigQuery APIを有効化します。

GCPコンソールの左側メニューから「APIとサービス」→「ライブラリ」を選択します。検索ボックスに「BigQuery API」と入力し、検索結果から「BigQuery API」をクリックします。

BigQuery APIの詳細画面が表示されたら、「有効にする」ボタンをクリックします。数秒で有効化が完了し、「APIが有効」というステータスが表示されます。

また、GA4からのデータエクスポートには適切な権限設定も必要です。GCPコンソールの「IAMと管理」→「IAM」で、GA4がデータを書き込むための権限を確認します。通常、GA4連携時に自動的に必要な権限(BigQuery データ編集者)が付与されますが、組織のポリシーによっては手動での権限追加が必要な場合もあります。

BigQuery APIが有効化されていることを確認したら、次のステップに進みます。この設定は一度行えば、同じGCPプロジェクト内では再設定不要です。

ステップ3: GA4管理画面でのリンク設定

GA4の管理画面から、BigQueryとの連携設定を行います。これが最も重要なステップです。

GA4の管理画面(https://analytics.google.com/)にログインし、画面左下の「管理」(歯車アイコン)をクリックします。プロパティ列から、BigQueryと連携したいGA4プロパティを選択します。

プロパティ設定の中から「BigQueryのリンク」を選択し、「リンク」ボタンをクリックします。BigQueryプロジェクトの選択画面が表示されるので、ステップ1で作成したGCPプロジェクトのプロジェクトIDを入力または選択します。

次に、データセットの場所(ロケーション)を選択します。日本からのアクセスが主な場合は「asia-northeast1(東京)」または「asia-northeast2(大阪)」を選択すると、クエリ実行速度が向上します。データセット名は自動的に「analytics_<プロパティID>」という形式で設定されますが、カスタマイズも可能です。

エクスポート頻度は「毎日」(日次エクスポート)または「ストリーミング」を選択できます。初めての場合は「毎日」を選択し、必要に応じて後からストリーミングを追加することをお勧めします。

すべての設定を確認したら、「送信」ボタンをクリックします。これでGA4とBigQueryの連携設定は完了です。

ステップ4: 連携確認とデータセット確認

連携設定が正しく完了しているか、BigQueryコンソールで確認します。

GCPコンソールでBigQuery(https://console.cloud.google.com/bigquery)を開きます。左側のエクスプローラーに、ステップ3で設定したデータセット名(例:analytics_123456789)が表示されているはずです。

初回のデータエクスポートは、連携設定後24時間以内に開始されます。翌日以降、データセットを展開するとevents_YYYYMMDD形式のテーブルが自動生成されていることを確認できます。

テーブルをクリックすると、「スキーマ」「詳細」「プレビュー」の各タブで、データ構造や実際のデータを確認できます。プレビュータブでは、実際にエクスポートされたイベントデータの一部を見ることができます。

簡単なクエリを実行して、データが正しく取得できるかテストしてみましょう。例えば、以下のクエリで前日のイベント数を確認できます:

SELECT COUNT(*) as event_count
FROM `プロジェクトID.analytics_123456789.events_20250105`

クエリが正常に実行され、件数が返ってくれば、連携は成功しています。これでGA4のデータをBigQueryで自由に分析できる環境が整いました。


BigQueryのコスト構造と無料枠の活用法

BigQueryは従量課金制ですが、無料枠を活用すれば小規模サイトなら実質無料で運用できます。コスト構造を正しく理解し、効率的に活用しましょう。

BigQueryの料金体系

BigQueryの料金は、ストレージ料金とクエリ(分析)料金の2つで構成されます。

ストレージ料金は、BigQueryに保存しているデータ量に応じて課金されます。最初の10GBまでは完全無料で、それを超えた分は1GBあたり月額0.02ドル(アクティブストレージ)です。90日間アクセスされていないデータは長期保存扱いとなり、1GBあたり月額0.01ドルとさらに安価になります。

クエリ料金は、SQLを実行してスキャンしたデータ量に応じて課金されます。月1TBまでのクエリは完全無料で、それを超えた分は1TBあたり5ドルです。つまり、月に1TB以内のデータスキャンであれば、クエリコストは発生しません。

ストリーミングエクスポートを有効にした場合は、ストリーミングインサート料金として1GBあたり0.05ドルが追加されます。日次エクスポートのみであれば、この費用は発生しません。

例えば、1日10万イベント(約100MB)のサイトの場合、月間約3GBのデータ蓄積となり、ストレージ料金は無料枠内に収まります。クエリも適切に最適化すれば、月1TBの無料枠で十分運用可能です。

サンドボックス(無料枠)での運用方法

BigQueryのサンドボックスを活用すれば、小規模サイトは実質無料で長期運用できます。

サンドボックスは、クレジットカード登録なしで利用できるBigQueryの無料枠です。ただし、GA4連携には請求先アカウントの登録が必須のため、正確には「請求先アカウントは登録するが、無料枠内で運用する」という形になります。

無料枠内で運用するための重要なポイントは、クエリの最適化です。SELECT文では必要なカラムのみを指定し、SELECT *でテーブル全体をスキャンすることを避けます。また、WHERE句で日付範囲を明示的に指定することで、スキャンデータ量を大幅に削減できます。

例えば、以下のように日付パーティションを活用します:

-- 悪い例(全データをスキャン)
SELECT * FROM `analytics_123456789.events_*`

-- 良い例(特定期間のみスキャン)
SELECT event_name, COUNT(*) as cnt
FROM `analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20250101' AND '20250107'
GROUP BY event_name

さらに、コスト監視のためにBudget(予算)とアラート設定をお勧めします。GCPコンソールの「お支払い」→「予算とアラート」から、月額予算(例:1ドル)を設定し、超過時にメール通知を受け取れます。これにより、予期せぬコスト発生を防げます。

標準プロパティの制限事項

GA4標準プロパティには、1日100万イベントのエクスポート上限があります。

この制限は、BigQueryへのエクスポート対象イベント数に適用されます。自社サイトのイベント数がこの上限を超える場合、GA4管理画面のBigQueryリンク設定で「イベントフィルタ」を設定できます。

イベントフィルタでは、特定のイベント名を除外したり、特定の条件に合致するイベントのみをエクスポートしたりできます。例えば、「page_view」「click」「scroll」など重要度の低いイベントを除外し、「purchase」「form_submit」などコンバージョン関連イベントのみをエクスポートすることで、上限内に収められます。

また、複数のGA4プロパティがある場合は、各プロパティごとに1日100万イベントの上限が適用されます。サイトを複数プロパティに分割することで、実質的な上限を拡張できます。

1日100万イベントを恒常的に超える大規模サイトの場合は、GA4 360へのアップグレードを検討する価値があります。GA4 360では、イベント数の制限がなくなるだけでなく、SLA(サービスレベル保証)や高頻度エクスポート、BigQuery Export以外の高度な機能も利用できます。年間費用は約150万円〜ですが、データ駆動型経営を重視する企業には十分な投資対効果があります。


H2: エクスポートされるデータのテーブル構造とスキーマ

BigQueryにエクスポートされるGA4データは、独特のスキーマ構造を持っています。この構造を理解することが、効果的な分析の第一歩です。

H3: データセットとテーブルの命名規則

GA4からBigQueryへエクスポートされるデータは、データセット内に日付別テーブルとして格納されます。

データセット名は、連携設定時に指定した名前(デフォルトはanalytics_<プロパティID>)になります。例えば、GA4プロパティIDが「123456789」の場合、analytics_123456789というデータセットが作成されます。

このデータセット内には、日次エクスポートの場合events_YYYYMMDD形式のテーブルが毎日自動生成されます。例えば:

  • events_20250105: 2025年1月5日の確定データ
  • events_20250106: 2025年1月6日の確定データ

ストリーミングエクスポートを有効にしている場合は、events_intraday_YYYYMMDDテーブルも作成されます:

  • events_intraday_20250105: 2025年1月5日の当日暫定データ

各テーブルには、その日に発生した全イベントが1イベント=1行として格納されます。つまり、1日に10万イベントが発生すれば、そのテーブルには10万行のデータが入ります。

テーブルの自動生成タイミングは、日次エクスポートの場合、通常は日本時間の午前中(前日分が確定)です。ストリーミングの場合は、イベント発生から数分以内にevents_intraday_テーブルに反映されます。

複数日のデータを一括で扱いたい場合は、ワイルドカード(events_*)を使って複数テーブルを結合できます。これは後述するクエリ最適化で重要なテクニックになります。

GA4イベントデータの基本スキーマ

GA4のイベントデータは、階層的な構造を持つ複雑なスキーマで格納されます。

主要なカラムは以下の通りです:

カラム名データ型説明
event_dateSTRINGイベント発生日(YYYYMMDD形式)
event_timestampINTEGERイベント発生時刻(マイクロ秒単位のUNIXタイムスタンプ)
event_nameSTRINGイベント名(page_view, click, purchaseなど)
event_paramsRECORD(REPEATED)イベントパラメータの配列
user_idSTRINGユーザーID(設定している場合)
user_pseudo_idSTRINGGA4が自動生成する匿名ユーザーID
user_propertiesRECORD(REPEATED)ユーザープロパティの配列
deviceRECORDデバイス情報(category, operating_systemなど)
geoRECORD地理情報(country, city, regionなど)
traffic_sourceRECORD流入元情報(source, medium, campaignなど)

特に重要なのはevent_nameで、これによってイベントの種類を識別します。GA4の標準イベント(page_view, session_start, first_visitなど)やカスタムイベントがここに記録されます。

event_paramsは、各イベントに付随する詳細情報を格納します。例えば、page_viewイベントであればpage_location(URL)、page_title(ページタイトル)などがevent_paramsに含まれます。purchaseイベントであれば、value(購入金額)、currency(通貨)、transaction_id(トランザクションID)などが格納されます。

devicegeotraffic_sourceなどは、GA4のディメンションに相当する情報で、セグメント分析に使用します。例えば、device.categoryで「mobile」「desktop」「tablet」を区別したり、geo.countryで国別分析を行ったりできます。

ネストされたデータ構造の理解

GA4のBigQueryエクスポートデータは、ARRAY型とSTRUCT型(RECORD型)がネストした複雑な構造になっています。

RECORD型(STRUCT型)は、複数のフィールドをまとめた構造体です。例えばdeviceは RECORD型で、その中にdevice.categorydevice.operating_systemdevice.browserなどのフィールドが含まれます。

ARRAY型(REPEATED)は、同じ構造のデータが複数存在する場合に使われます。event_paramsがその典型例で、1つのイベントに複数のパラメータが付随するため、配列として格納されます。

このネストされたデータを展開するには、UNNEST関数を使用します。例えば、イベントパラメータから特定の値を取り出すクエリは以下のようになります:

SELECT
  event_name,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'engagement_time_msec') AS engagement_time
FROM
  `analytics_123456789.events_20250105`
WHERE
  event_name = 'page_view'
LIMIT 10

よく使うカラムの抽出パターンとしては:

  • ページURL: (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location')
  • ページタイトル: (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_title')
  • 購入金額: (SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'value')
  • トランザクションID: (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'transaction_id')

このUNNEST構文は最初は難しく感じるかもしれませんが、パターンを覚えれば応用が効きます。GA4の公式ドキュメントにもサンプルクエリが豊富に用意されているので、参考にすると良いでしょう。


GA4×BigQueryでできる実践的な分析例7選

BigQueryを活用することで、GA4だけでは実現できない高度な分析が可能になります。実務で即活用できる7つの分析例をSQLサンプル付きで紹介します。

ユーザー単位の詳細行動分析

ユーザーごとの行動履歴を時系列で追跡し、コンバージョンまでのカスタマージャーニーを可視化できます。

GA4の管理画面では、セッション単位の分析が中心ですが、BigQueryではユーザー単位で複数セッションにまたがる行動を追跡できます。例えば、初回訪問から購入に至るまでに何回サイトを訪問したか、どのページを何回閲覧したか、どのイベントを発火させたかといった詳細な行動パターンを分析できます。

以下は、特定ユーザーの行動履歴を時系列で取得するSQLサンプルです:

SELECT
  user_pseudo_id,
  event_timestamp,
  event_name,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url,
  device.category AS device_type,
  traffic_source.medium AS medium
FROM
  `analytics_123456789.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20250101' AND '20250107'
  AND user_pseudo_id = '1234567890.1234567890'
ORDER BY
  event_timestamp ASC

また、コンバージョンまでの接触回数分析では、購入ユーザーが購入前に何回サイトを訪問したかを集計できます:

WITH user_sessions AS (
  SELECT
    user_pseudo_id,
    COUNT(DISTINCT session_id) AS session_count,
    MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) AS has_purchase
  FROM (
    SELECT
      user_pseudo_id,
      event_name,
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id
    FROM
      `analytics_123456789.events_*`
    WHERE
      _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  )
  GROUP BY
    user_pseudo_id
)
SELECT
  session_count,
  COUNT(*) AS user_count,
  SUM(has_purchase) AS purchaser_count,
  ROUND(SUM(has_purchase) / COUNT(*) * 100, 2) AS conversion_rate
FROM
  user_sessions
GROUP BY
  session_count
ORDER BY
  session_count

このクエリで、「1回の訪問で購入したユーザー」「2回の訪問で購入したユーザー」といった分布が分かり、購入までの典型的なカスタマージャーニーが見えてきます。

カスタムファネル分析

自社ビジネス特有の転換ステップを定義し、各ステップでの離脱率を詳細に分析できます。

GA4の探索機能にもファネル分析はありますが、BigQueryでは完全にカスタマイズされたファネルを構築できます。例えば、ECサイトであれば「商品閲覧→カート追加→決済情報入力→購入完了」といったステップごとの転換率と離脱ポイントを可視化できます。

以下は、4ステップのファネル分析SQLサンプルです:

WITH funnel_events AS (
  SELECT
    user_pseudo_id,
    MAX(CASE WHEN event_name = 'view_item' THEN 1 ELSE 0 END) AS step1_product_view,
    MAX(CASE WHEN event_name = 'add_to_cart' THEN 1 ELSE 0 END) AS step2_add_cart,
    MAX(CASE WHEN event_name = 'begin_checkout' THEN 1 ELSE 0 END) AS step3_checkout,
    MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) AS step4_purchase
  FROM
    `analytics_123456789.events_*`
  WHERE
    _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  GROUP BY
    user_pseudo_id
)
SELECT
  'Step 1: Product View' AS step_name,
  SUM(step1_product_view) AS user_count,
  NULL AS conversion_from_previous
FROM funnel_events
UNION ALL
SELECT
  'Step 2: Add to Cart',
  SUM(step2_add_cart),
  ROUND(SUM(step2_add_cart) / NULLIF(SUM(step1_product_view), 0) * 100, 2)
FROM funnel_events
UNION ALL
SELECT
  'Step 3: Begin Checkout',
  SUM(step3_checkout),
  ROUND(SUM(step3_checkout) / NULLIF(SUM(step2_add_cart), 0) * 100, 2)
FROM funnel_events
UNION ALL
SELECT
  'Step 4: Purchase',
  SUM(step4_purchase),
  ROUND(SUM(step4_purchase) / NULLIF(SUM(step3_checkout), 0) * 100, 2)
FROM funnel_events
ORDER BY
  step_name

この分析により、どのステップで最も離脱が発生しているかが明確になり、UI改善の優先順位を付けられます。

LTV(顧客生涯価値)分析

ユーザーごとの累計購入金額や購入頻度を集計し、顧客セグメントごとのLTVを算出できます。

LTV分析では、ユーザーの初回訪問日(コホート)ごとにグループ化し、その後の購買行動を追跡します。これにより、「1月に獲得したユーザーの3ヶ月後のLTVはいくらか」といった分析が可能になります。

以下は、ユーザーごとの累計購入金額を算出するSQLサンプルです:

SELECT
  user_pseudo_id,
  COUNT(DISTINCT CASE WHEN event_name = 'purchase' THEN event_timestamp END) AS purchase_count,
  SUM(CASE WHEN event_name = 'purchase' THEN 
    (SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'value') 
  END) AS total_revenue,
  MIN(event_date) AS first_visit_date,
  MAX(event_date) AS last_visit_date
FROM
  `analytics_123456789.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20240101' AND '20250131'
GROUP BY
  user_pseudo_id
HAVING
  purchase_count > 0
ORDER BY
  total_revenue DESC
LIMIT 100

さらに、コホート別LTV推移を見るクエリ:

WITH user_cohort AS (
  SELECT
    user_pseudo_id,
    MIN(event_date) AS cohort_date
  FROM
    `analytics_123456789.events_*`
  WHERE
    _TABLE_SUFFIX >= '20250101'
  GROUP BY
    user_pseudo_id
),
user_revenue AS (
  SELECT
    user_pseudo_id,
    event_date,
    SUM(CASE WHEN event_name = 'purchase' THEN 
      (SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'value') 
    END) AS daily_revenue
  FROM
    `analytics_123456789.events_*`
  WHERE
    _TABLE_SUFFIX >= '20250101'
  GROUP BY
    user_pseudo_id, event_date
)
SELECT
  uc.cohort_date,
  DATE_DIFF(PARSE_DATE('%Y%m%d', ur.event_date), PARSE_DATE('%Y%m%d', uc.cohort_date), DAY) AS days_since_first_visit,
  COUNT(DISTINCT ur.user_pseudo_id) AS active_users,
  SUM(ur.daily_revenue) AS cumulative_revenue,
  ROUND(SUM(ur.daily_revenue) / COUNT(DISTINCT ur.user_pseudo_id), 2) AS avg_ltv
FROM
  user_cohort uc
  JOIN user_revenue ur ON uc.user_pseudo_id = ur.user_pseudo_id
GROUP BY
  uc.cohort_date, days_since_first_visit
ORDER BY
  uc.cohort_date, days_since_first_visit

この分析により、獲得チャネル別や施策別のLTVを比較し、真のROIを測定できます。

リアルタイムダッシュボード構築

ストリーミングデータを活用して、当日のパフォーマンスをほぼリアルタイムで監視できます。

ストリーミングエクスポートを有効にしている場合、events_intraday_テーブルのデータをLooker Studioに接続することで、リアルタイム更新されるダッシュボードを構築できます。キャンペーン実施中の成果モニタリングや、異常値の早期検知に有効です。

Looker Studioとの連携方法は以下の通りです:

  1. Looker Studio(https://lookerstudio.google.com/)を開く
  2. 「作成」→「データソース」を選択
  3. 「BigQuery」を選択し、該当するGCPプロジェクトとデータセットを選択
  4. events_intraday_YYYYMMDDテーブルを選択(ワイルドカードevents_intraday_*も可)
  5. データソースを保存し、レポートを作成

ダッシュボードの更新頻度は、Looker Studioの設定で「15分ごと」「1時間ごと」など調整できます。リアルタイム性を重視する場合は、更新頻度を高く設定します。

リアルタイムダッシュボードの活用例:

  • ECサイトのタイムセール中の購入数・売上のリアルタイム監視
  • 広告キャンペーン開始直後のCV数・CPA推移の確認
  • サーバーダウンやトラッキング不具合の早期検知

ただし、ストリーミングエクスポートにはコストがかかるため、本当に必要な期間のみ有効化することをお勧めします。

B2Bリード獲得分析

フォーム送信からMQL・SQLへの転換を追跡し、リード獲得チャネルのROIを正確に測定できます。

B2B企業では、Webサイトでのリード獲得がゴールではなく、その後のMQL(Marketing Qualified Lead)、SQL(Sales Qualified Lead)化、さらには受注までを追跡する必要があります。BigQueryでは、GA4データとCRM/MAツールのデータを結合することで、この一連のプロセスを分析できます。

まず、GA4側でリード獲得を計測するために、フォーム送信時にgenerate_leadイベントを発火させ、user_idパラメータにメールアドレスやリードIDを含めます。

次に、CRMデータ(例:SalesforceやHubSpot)をBigQueryにインポートします。多くのCRM/MAツールはBigQueryへのデータエクスポート機能を提供しています。

そして、以下のようなクエリでGA4データとCRMデータを結合します:

WITH ga4_leads AS (
  SELECT
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'user_id') AS lead_email,
    MIN(event_timestamp) AS first_touch_timestamp,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source') AS first_source,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'medium') AS first_medium
  FROM
    `analytics_123456789.events_*`
  WHERE
    _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
    AND event_name = 'generate_lead'
  GROUP BY
    lead_email, first_source, first_medium
)
SELECT
  gl.first_source,
  gl.first_medium,
  COUNT(DISTINCT gl.lead_email) AS total_leads,
  COUNT(DISTINCT CASE WHEN crm.stage = 'MQL' THEN crm.lead_id END) AS mql_count,
  COUNT(DISTINCT CASE WHEN crm.stage = 'SQL' THEN crm.lead_id END) AS sql_count,
  COUNT(DISTINCT CASE WHEN crm.stage = 'Closed Won' THEN crm.lead_id END) AS won_count,
  ROUND(COUNT(DISTINCT CASE WHEN crm.stage = 'MQL' THEN crm.lead_id END) / COUNT(DISTINCT gl.lead_email) * 100, 2) AS mql_rate,
  SUM(CASE WHEN crm.stage = 'Closed Won' THEN crm.deal_amount END) AS total_revenue
FROM
  ga4_leads gl
  LEFT JOIN `project.dataset.crm_data` crm ON gl.lead_email = crm.email
GROUP BY
  gl.first_source, gl.first_medium
ORDER BY
  total_revenue DESC

この分析により、どの流入チャネルが最も質の高いリードを生み出しているかが明確になり、マーケティング予算の最適配分が可能になります。

セグメント別のページパフォーマンス分析

デバイス・流入元別の直帰率やCVRを詳細に分析し、セグメントごとの最適化施策を立案できます。

GA4の管理画面でもセグメント分析は可能ですが、BigQueryではより柔軟な条件設定と複雑な指標算出が可能です。例えば、「スマホ×自然検索」「PC×広告」といった掛け合わせセグメントごとに、ランディングページのパフォーマンスを評価できます。

以下は、デバイス・流入元別の直帰率とCVRを算出するSQLサンプルです:

WITH page_sessions AS (
  SELECT
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    device.category AS device_type,
    traffic_source.medium AS medium,
    traffic_source.source AS source,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS landing_page,
    COUNT(*) AS event_count,
    MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) AS has_conversion
  FROM
    `analytics_123456789.events_*`
  WHERE
    _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
    AND event_name IN ('session_start', 'page_view', 'purchase')
  GROUP BY
    session_id, device_type, medium, source, landing_page
)
SELECT
  device_type,
  medium,
  source,
  landing_page,
  COUNT(*) AS total_sessions,
  SUM(CASE WHEN event_count = 1 THEN 1 ELSE 0 END) AS bounced_sessions,
  ROUND(SUM(CASE WHEN event_count = 1 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS bounce_rate,
  SUM(has_conversion) AS conversions,
  ROUND(SUM(has_conversion) / COUNT(*) * 100, 2) AS conversion_rate
FROM
  page_sessions
GROUP BY
  device_type, medium, source, landing_page
HAVING
  total_sessions >= 100
ORDER BY
  total_sessions DESC
LIMIT 50

この分析により、「スマホユーザーの直帰率が高い特定のLPを改善する」「広告経由のPCユーザー向けにCTA配置を最適化する」といった具体的なアクションにつながります。

イベントパラメータのカスタム集計

scroll_depthやvideo_progressなど、カスタムパラメータを活用した詳細なユーザー行動分析ができます。

GA4では、標準イベントに加えて独自のイベントパラメータを送信できます。例えば、スクロール深度、動画再生率、クリック位置、フォーム入力進捗など、サイト固有の重要指標をパラメータとして計測できます。

以下は、scroll_depthパラメータから平均スクロール深度を算出するSQLサンプルです:

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url,
  COUNT(*) AS scroll_events,
  AVG(CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'percent_scrolled') AS INT64)) AS avg_scroll_depth,
  COUNTIF((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'percent_scrolled') >= 75) AS deep_scroll_count,
  ROUND(COUNTIF((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'percent_scrolled') >= 75) / COUNT(*) * 100, 2) AS deep_scroll_rate
FROM
  `analytics_123456789.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  AND event_name = 'scroll'
GROUP BY
  page_url
HAVING
  scroll_events >= 100
ORDER BY
  avg_scroll_depth DESC
LIMIT 20

また、クリックイベントのヒートマップデータ化では、クリック座標パラメータを集計してヒートマップツールにインポートすることで、ページ内のどこがクリックされているかを可視化できます。

これらのカスタム集計により、GA4の標準レポートでは見えない、自社サイト特有のユーザー行動インサイトを得られます。


よくあるトラブルと解決方法

GA4×BigQuery連携では、設定ミスやデータ構造の理解不足により、いくつかの典型的なトラブルが発生します。ここでは主要なトラブルと解決方法を解説します。

データがBigQueryに反映されない

連携設定後24時間以上経過してもデータが表示されない場合、設定に問題がある可能性があります。

まず、GA4管理画面で連携設定を確認します。「管理」→「BigQueryのリンク」で、リンクステータスが「アクティブ」になっているか確認しましょう。「保留中」や「エラー」と表示されている場合は、設定に問題があります。

次に、BigQuery APIが正しく有効化されているかチェックします。GCPコンソールの「APIとサービス」→「有効なAPIとサービス」で、「BigQuery API」が一覧に表示されているか確認してください。表示されていない場合は、APIを有効化する必要があります。

権限エラーの対処法としては、GCPプロジェクトのIAM権限を確認します。GA4からのデータエクスポートには、「BigQuery データ編集者」権限が必要です。GCPコンソールの「IAMと管理」→「IAM」で、GA4サービスアカウント(通常は @analytics-processing-dev.iam.gserviceaccount.com 形式)に適切な権限が付与されているか確認します。

また、GCPプロジェクトの請求先アカウントが正しく設定され、有効な状態か確認することも重要です。請求先アカウントが無効だと、データエクスポートが停止します。

それでも解決しない場合は、一度BigQueryリンクを削除し、再度設定し直すことで解決するケースもあります。ただし、過去のエクスポートデータは残るので、設定のやり直しによってデータが失われることはありません。

クエリ実行時のエラー対応

SQLクエリ実行時に発生する典型的なエラーとその対処法を解説します。

スキーマ変更によるエラーは、GA4がイベントパラメータの構造を変更した場合に発生します。例えば、以前はstring_valueだったパラメータがint_valueに変更された場合などです。この場合、クエリ内でデータ型を明示的にキャストする必要があります:

-- エラーになる例
SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'value'

-- 修正例(安全なキャスト)
SELECT SAFE_CAST(value.string_value AS FLOAT64) FROM UNNEST(event_params) WHERE key = 'value'

UNNEST関連のよくあるミスとしては、UNNEST構文の誤用があります。event_paramsから値を取得する際は、サブクエリとして記述する必要があります:

-- 間違った書き方
SELECT event_params.value.string_value FROM table UNNEST(event_params)

-- 正しい書き方
SELECT (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url FROM table

タイムアウト対策としては、クエリの最適化が重要です。特に大量データを扱う場合は以下の点に注意します:

  1. WHERE句で日付範囲を明示的に指定し、スキャンデータ量を削減する
  2. SELECT *を避け、必要なカラムのみ選択する
  3. 複雑な集計は段階的にCTE(WITH句)で分割する
  4. パーティションテーブルを活用する

また、クエリ実行前に「クエリ検証」ボタンでスキャンデータ量を確認し、予想外に大きい場合はクエリを見直すことをお勧めします。

コストが想定より高くなる場合

BigQueryのコストが想定より高額になった場合の原因特定と対策方法を解説します。

まず、GCPコンソールの「お支払い」→「レポート」で、どのサービス・どの操作にコストがかかっているか確認します。BigQueryの場合、「クエリ(分析)」と「ストレージ」のどちらにコストが発生しているかを特定します。

パーティションテーブルの活用により、クエリコストを大幅に削減できます。GA4のエクスポートデータは日付別にパーティション化されているため、WHERE句で日付範囲を指定すれば、該当する日付のパーティションのみスキャンされます:

-- パーティション活用(コスト低)
SELECT * FROM `analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20250101' AND '20250107'

-- パーティション未活用(コスト高)
SELECT * FROM `analytics_123456789.events_*`
WHERE event_date BETWEEN '20250101' AND '20250107'

クエリのWHERE句最適化では、フィルタ条件を可能な限り早い段階で適用することが重要です。JOINの前にWHEREで絞り込むことで、処理するデータ量を削減できます。

マテリアライズドビュー(Materialized View)の検討も有効です。頻繁に実行する集計クエリがある場合、その結果をマテリアライズドビューとして保存しておけば、毎回の集計コストを削減できます:

CREATE MATERIALIZED VIEW `analytics_123456789.daily_summary`
AS
SELECT
  event_date,
  COUNT(*) AS event_count,
  COUNT(DISTINCT user_pseudo_id) AS user_count
FROM
  `analytics_123456789.events_*`
GROUP BY
  event_date

また、ストリーミングエクスポートが本当に必要か再検討することも重要です。リアルタイム性が不要であれば、日次エクスポートのみに切り替えることで、ストリーミングインサート料金を削減できます。


GA4×BigQuery連携のQ&A

GA4とBigQueryの連携に関してよくある質問と回答をまとめました。

Q1: 過去データは遡ってエクスポートできますか?

いいえ、BigQuery連携を設定した日以降のデータのみがエクスポートされます。過去データの遡及エクスポートはできません。

BigQueryへのデータエクスポートは、連携設定を完了した翌日から開始されます。設定前のGA4データは、BigQueryには送信されません。したがって、過去のデータも分析したい場合は、できるだけ早期にBigQuery連携を設定することをお勧めします。

ただし、GA4の管理画面やデータエクスポート(Google スプレッドシートへのエクスポート)を使えば、過去データの一部は取得できます。また、GA4 APIを使って過去データをプログラマティックに取得し、BigQueryにインポートすることも技術的には可能ですが、手間とコストがかかります。

長期的なデータ分析を見据えて、GA4導入と同時、あるいはできるだけ早い段階でBigQuery連携を設定することが重要です。無料枠内で運用できるため、データ量が少ない初期段階から連携しておくことをお勧めします。

Q2: 複数のGA4プロパティを1つのBigQueryプロジェクトに連携できますか?

はい、複数のGA4プロパティを同一のBigQueryプロジェクトに連携できます。それぞれ別のデータセットとして格納されます。

1つのGCPプロジェクト内に、複数のGA4プロパティからのデータをエクスポートする設定が可能です。各GA4プロパティごとに個別のデータセット(例: analytics_123456789analytics_987654321)が作成され、データは分離されて管理されます。

この設定により、複数サイトのデータを一元管理し、クロスサイト分析や統合レポートの作成が容易になります。例えば、企業サイトとECサイトを運営している場合、両方のデータを同じBigQueryプロジェクトに集約し、ユーザーの行動を横断的に分析できます。

ただし、データセットが増えるとストレージコストが増加するため、本当に必要なプロパティのみを連携することをお勧めします。また、各データセットへのアクセス権限は個別に設定できるため、セキュリティ要件に応じた権限管理も可能です。

Q3: BigQueryの知識がなくても使えますか?

基本的なSQL知識があれば、GA4×BigQueryの活用は十分可能です。初心者向けのリソースも豊富に用意されています。

BigQueryはSQLベースのクエリエンジンなので、SQLの基本構文(SELECT、WHERE、GROUP BY、JOINなど)を理解していれば、データ抽出や集計ができます。プログラミング経験がなくても、SQL入門書やオンラインチュートリアルで学習すれば、数週間で実務レベルのクエリが書けるようになります。

Googleの公式ドキュメントには、GA4×BigQuery向けのサンプルクエリが多数掲載されており、これらをベースにカスタマイズすることで、多くの分析ニーズに対応できます。また、Looker Studioと組み合わせれば、SQLクエリを書かずに視覚的にレポートを作成することも可能です。

とはいえ、UNNEST構文やウィンドウ関数など、GA4特有のデータ構造を扱うには、ある程度の学習が必要です。最初は公式のサンプルクエリを使いながら、徐々にSQL知識を深めていくアプローチをお勧めします。

BigQueryのコンソールには「クエリエディタ」があり、構文エラーをリアルタイムで指摘してくれるため、初心者でも試行錯誤しながら学習できる環境が整っています。

Q4: データの保存期間に制限はありますか?

BigQueryに一度エクスポートされたデータは、ユーザーが削除しない限り永続的に保存されます。保存期間の制限はありません。

GA4の管理画面では、イベントレベルデータの保存期間が最大14ヶ月に制限されますが、BigQueryにエクスポートしたデータには保存期間の制限がありません。10年前のデータでも、テーブルを削除しない限りずっと保存され、いつでもクエリで分析できます。

この特性を活かして、長期的なトレンド分析や年次比較、過去数年分のデータを使った機械学習モデルの構築などが可能になります。また、法令やコンプライアンス要件で一定期間のデータ保存が義務付けられている業界では、BigQueryが有効なソリューションになります。

ただし、データを永続的に保存するということは、ストレージコストが累積していくことを意味します。とはいえ、90日以上アクセスされていないデータは「長期保存」扱いとなり、ストレージ料金が半額になるため、過去データの保存コストは比較的安価です。

不要になったデータは定期的に削除するか、アーカイブストレージ(Google Cloud Storageなど)に移行することで、コスト最適化も可能です。

Q5: GA4 360でなくても連携できますか?

はい、無料版のGA4(標準プロパティ)でもBigQueryとの連携は可能です。ただし、1日100万イベントの制限があります。

GA4の標準プロパティ(無料版)でも、BigQueryへのデータエクスポート機能を利用できます。これはGA4の大きな利点の一つで、以前のUniversal Analytics(UA)では有料版(Google Analytics 360)でしか使えなかった機能です。

標準プロパティの主な制限は、1日あたり100万イベントのエクスポート上限です。多くの中小企業サイトやメディアサイトでは、この上限内に収まります。1日100万イベントは、月間約3,000万イベントに相当するため、かなり大規模なサイトでない限り問題になりません。

もし上限を超える場合は、GA4管理画面でイベントフィルタを設定し、重要なイベントのみをエクスポートすることで対応できます。または、GA4 360(年間約150万円〜)にアップグレードすることで、イベント数制限が撤廃されます。

標準プロパティと360の主な違いは、エクスポート上限の他に、SLA保証、高頻度エクスポート、Googleサポートの優先度などがあります。しかし、基本的なBigQuery連携機能自体は標準プロパティでも十分活用できます。


まとめ:GA4×BigQuery連携で実現する次世代データ分析

GA4とBigQueryの連携は、データドリブンなマーケティングを次のレベルへ引き上げる強力な手段です。

本記事で解説した通り、BigQuery連携により以下のメリットが得られます:

  1. 分析の自由度向上: SQLで生データを自由に集計・加工し、GA4単体では不可能な詳細分析が実現
  2. データ統合: CRM、MA、広告プラットフォームなど他システムとのデータ結合により、真のROI測定が可能に
  3. 長期保存: GA4の保存期間制限を超えた永続的なデータ保管と、年単位のトレンド分析
  4. コスト効率: 無料枠を活用すれば、小規模サイトは実質無料で高度な分析環境を構築可能

連携設定は4ステップで完了し、初心者でも1時間程度で実施できます。BigQueryの基本的なSQL知識があれば、実務レベルの分析は十分可能です。

まずは日次エクスポートから始め、必要に応じてストリーミングエクスポートや高度なクエリに挑戦していくことをお勧めします。本記事で紹介したSQLサンプルを活用しながら、自社ビジネスに最適な分析環境を構築してください。

GA4×BigQuery連携は、データ分析の民主化を推進し、すべての企業が高度なデータ活用を実現できる可能性を開きます。ぜひこの機会に、次世代のデータ分析環境を構築してみてください。


関連記事・参考リソース

関連記事

ブログ一覧に戻る

ご相談はこちら