なぜ GA4 を BigQuery に入れたくなるのか
Google Analytics 4（GA4）には、管理画面で見られるレポート機能があります。 ただ、運用していくと、必ずぶつかる壁があります。
- サンプリング：データ量が増えると、GA4 の探索レポートは自動的に「全体の一部だけ」を見ている状態になり、数字が信用できなくなる。 標準 GA4 は対象期間のイベントが 1,000 万を超えると発動、GA4 360 でも 10 億超で発動
- 長期保存：GA4 標準ではデータの保持期間に上限がある（最大 14 ヶ月）。 1 年以上前のコホート LTV を出したくても、データが消えている
- 横串分析：Shopify、Klaviyo、業務 DB などと結合して見たいが、GA4 の管理画面ではできない
- 探索の制約：GA4 の管理画面は、表現できる切り口に限界がある。 複雑な条件（A セグメントかつ B 経由かつ C 商品購入）を組み合わせるのは難しい
- AI 分析への展開：GA4 標準では、Slack 常駐 AI 分析エージェントから業務質問を投げて答えさせるのが難しい
これを解決するのが、GA4 のデータを BigQuery（Google Cloud のデータの倉庫）に流し込む 「BigQuery Export」という機能です。GA4 から無料で使える標準機能で、設定さえすれば数日後から自動的にデータが流れ始めます。
入れると、何ができるようになるか
- サンプリングなしの正確な数字が、いつでも SQL で取れる
- 長期保存：BigQuery に入れれば、5 年でも 10 年でも保管できる
- 横串分析：Shopify、Klaviyo、Stripe、広告チャネルと結合して、コホート LTV や MER を計算
- カスタム集計：複雑な条件の組み合わせも自由に
- AI 分析エージェントの接続：BigQuery 上にあれば、Slack に常駐する AI に業務質問を投げて、その場で答えが返ってくる
- BI ツールとの連携：Looker Studio、Tableau、Power BI などから直接ダッシュボード化できる
設定はクリック数回で済む（無料機能）
GA4 → BigQuery の連携設定は、初回だけ管理画面で数クリックです。 かかる作業は次の通り。
- Google Cloud Platform で、データを置く BigQuery プロジェクトを作る
- GA4 管理画面の「BigQuery のリンク」から、対象の Cloud プロジェクトを選択
- 連携の種類（後述の Daily / Streaming / Users）を選ぶ
- 2-3 日待つ（最初の 1 日分のデータが届く）
GA4 側の機能利用は無料です（GA4 360 ではない、無印の GA4 でも使える）。 BigQuery 側は、保管容量とクエリ実行量に応じた従量課金がかかりますが、 年商 1〜30 億規模の EC なら、月額数千円〜数万円のレンジに収まることが多いです。
日次 / リアルタイム / ユーザー別 — どれを使うか
BigQuery への流し方には、3 つの種類があります。 多くのケースで 「Daily Export」だけで十分です。
① Daily Export（日次）— 標準の選択
前日分のデータが、次の日にまとめて届く。 毎日決まった時間（だいたい朝 9-11 時頃）に events_YYYYMMDD という形のテーブルが追加される。 EC、SaaS、メディアの標準的な選択です。追加コストなし。
② Streaming Export（リアルタイム）— 必要な時だけ
イベントが起きた数秒後にデータが届く。events_intraday_YYYYMMDD という形のテーブルが、その日のデータをリアルタイム更新。
メリット：「今日のリアルタイム数値を AI に聞きたい」のような用途で使える。
デメリット：BigQuery のストリーミング挿入料金がかかる（GB 単位、月数千円〜数万円の追加）。
③ Users Export（ユーザー別）— 限定用途
ユーザー単位で再集計されたデータ。 ユーザー属性、初回流入、カスタム指標などをユーザー粒度で分析したい場合に使う。 多くの会社では使わないか、後から有効化する。
多くの会社は Daily Export だけで運用が回ります。 リアルタイム性が必要になってから Streaming を追加すれば十分です。
届いたデータの構造 — そのままだと使いにくい理由
BigQuery に届くデータは、「イベント単位で 1 行ずつ並ぶ」形式です。 1 イベント = 1 レコード。
1 つのレコードには、こんなデータが入っています：
- イベント名（page_view、scroll、click、purchase など）
- タイムスタンプ
- ユーザー識別子（user_pseudo_id、user_id）
- デバイス情報
- 地域情報
- イベントパラメータ（event_params）— ここがネスト構造
- ユーザープロパティ（user_properties）— ここもネスト構造
問題は、event_params と user_properties がネストされた配列構造になっていること。 「page_view イベントの URL は何か」を取るには、event_params の中から特定の key の value を抽出する SQL を書く必要があります。
ユーザー単位、注文単位、月次集計には、毎回ゼロから組み直す必要があり、 業務分析には使いにくい構造です。
入れた後にやること — 業務粒度に整形する
そこで、生データを「業務で使えるテーブル」に整形する手順を、dbt のようなツールでコード化します。 ネスト構造を平らに展開し、ユーザー / セッション / 月次の粒度のテーブルを作ります。
典型的な整形先：
- セッション単位のテーブル：流入元、滞在時間、コンバージョン、デバイス
- ユーザー単位のテーブル：初回流入チャネル、累積セッション、累積購入、LTV
- 月次・週次の流入チャネル別集計：広告との結合用
- コホート集計：獲得月別の継続率
- イベント別集計：特定イベント（add_to_cart、purchase など）の発生数
ここまで整形して、初めて GA4 のデータが「業務質問に答えられるテーブル」になります。 全体像はデータ基盤を組むときに考えることに書きました。
dbt 整形の典型パターン
staging（生データを軽く正規化）
- stg_ga4__events — ネスト構造を平らに展開
- stg_ga4__user_properties — ユーザープロパティを抽出
intermediate（複数を組み合わせた中間テーブル）
- int_sessions — セッション単位に集約（複数イベントを 1 セッションとして束ねる）
- int_users — ユーザー単位の累積集計
marts（業務で直接使うテーブル）
- fct_sessions — セッション粒度のファクトテーブル
- dim_users — ユーザー粒度のディメンション
- monthly_traffic — 月次のチャネル別流入
- cohort_retention — 獲得月別の継続率
コストの目安と、跳ねる原因
BigQuery 側の費用は、おおむね 2 種類です。
- 保管容量：流れてきたデータを保管する費用。 年商 1〜30 億規模で月数百円〜数千円が目安
- クエリ実行量：SQL を実行するときに、スキャンしたデータ量に応じて課金。 これがコスト変動の主因
月の請求が想定外に跳ねる原因
実際に「請求が 5 倍になった」事故の原因は、ほぼ次のどれかです。
- BI ツール（Looker、Tableau）が、毎時間フルスキャンを走らせている。 ダッシュボードのキャッシュが効いていない、または日付絞り込みなしの SQL が走る
- パーティション（日付ごとの区切り）を活用しない SQL が多い。
WHERE event_date BETWEEN ...を入れず、全期間スキャンしてしまう - 同じ集計を毎回ゼロから走らせる。 中間テーブルを作っていないので、同じデータを何度もスキャンする
- Streaming Export を不要に有効化。 「あったほうがいい」で入れると、月数千〜数万円が追加で乗る
解決策
- パーティションを使う SQL を徹底。日付絞り込みを必ず入れる
- 頻繁に使う集計は、事前に中間テーブル化しておく。dbt で日次ジョブで作っておく
- BI ツールのキャッシュ設定を有効化
- INFORMATION_SCHEMA から日次でクエリ統計を集計、上位コストクエリを Slack に通知
Consent Mode（同意管理）の影響
欧州（GDPR）対応や iOS 14.5 以降の追跡同意（ATT）の影響で、 ユーザーが追跡同意をしていない場合に GA4 のデータの集まり方が変わります。 これが Consent Mode v2 という仕組み。
整形時に注意すべき点
- 同意なしのユーザーのデータは、Cookie なしでモデル推定された数値になる場合がある
- user_id が取れていないユーザーが大量にいる
- ユーザー粒度の分析（同一人物の追跡）は、同意ありのユーザーのみで集計するか、推定込みで集計するかを決める
ヘッドフォン購買 / アパレル系のように iOS ユーザーが多い D2C ブランドでは、 GA4 上の数字と、Shopify の実際の注文数の差が 30〜 40% 出ることもあります。 GA4 の数字を「絶対値」と信じすぎず、Shopify などの実購入データと組み合わせて見る運用が標準です。
Shopify との結合 — EC/D2C で必須の連携
EC/D2C なら、GA4 の流入データと Shopify の注文データを結合するのが定番。 典型的な結合キーと用途：
- session_id × order：注文がどのセッション経由か紐付け（流入チャネル × 売上）
- user_id × customer_id：GA4 のユーザーと Shopify の顧客を紐付け（コホート LTV、リピート分析）
- transaction_id × order_id：個別の購入イベント
結合できると、こんな分析が可能になります：
- 「先月の Email 流入の LTV 高い顧客は誰か」
- 「初回 Google Ads 流入と、後の自然検索流入で LTV はどう違うか」
- 「カゴ落ちページからの離脱経路を、ユーザーセッション単位でトレース」
結合の詳細はShopify を BigQuery に入れる話に書きました。
よくある落とし穴 5 つ
- Streaming（リアルタイム）を最初から有効化する — 大半のケースで Daily で十分。Streaming は追加コストがかかるので、必要になってから足す
- BigQuery に入れただけで止まる — 整形しないと、ネスト構造で業務分析には使いにくい。dbt 整形までセットで考える
- パーティションを使わない SQL を書く — クエリコストが跳ねる。日付の絞り込みを必ず入れる
- Consent Mode の影響を考慮していない — ユーザー同意の有無で、流れてくるデータの構造が変わる。集計ロジックがズレる原因になる
- 過去データを移行する手段を考えていない — BigQuery Export は連携した日からのデータしか流れない。過去のデータが必要なら、別途取り込みの仕組みが必要（GA4 API での取得など）
まとめ
- GA4 を BigQuery に入れると、サンプリングなし・長期保存・横串分析・AI 分析エージェント接続が可能になる
- 設定は GA4 管理画面で数クリック。GA4 側は無料、BigQuery は従量課金（月数千円〜）
- 多くの会社は Daily Export だけで運用が回る。Streaming は必要になってから
- BigQuery に入れた後は、dbt で業務粒度に整形してこそ意思決定に乗る
- EC/D2C は Shopify / Klaviyo との結合が定番。横串で見られると LTV やコホート分析の解像度が上がる