Looker StudioのGA4コネクタとBigQueryコネクタの違いと使い分け

はじめに

Looker StudioでGA4のデータを可視化するとき、「GA4コネクタ」と「BigQueryコネクタ」のどちらを使うべきか迷ったことはないでしょうか。

どちらもGA4のデータを扱えますが、取得できるデータの粒度、速度、カスタマイズ性が大きく異なります。この記事では、両者の違いを具体的に比較し、ユースケースごとの使い分け方を解説します。

GA4コネクタの特徴

GA4コネクタは、Looker StudioからGA4 APIを通じてデータを取得する方式です。

メリット

設定が簡単: GA4プロパティを選択するだけで接続完了
追加費用なし: BigQueryの課金が発生しない
標準ディメンション・指標をそのまま使える: セッション、ユーザー、コンバージョンなど
リアルタイム性が高い: GA4の処理が完了次第反映される（通常24〜48時間以内）

デメリット

サンプリングが発生する: 大量のデータや複雑な組み合わせでサンプリングが適用される
カスタムディメンションの制限: イベントパラメータの展開に制約がある
APIクォータの制限: 同時接続数やリクエスト数に上限がある
SQLが使えない: データの加工や結合に柔軟性がない

サンプリングの影響

GA4コネクタでサンプリングが発生すると、データの正確性が低下します。Looker Studio上で「このレポートはサンプリングされたデータに基づいています」という警告が表示される場合があります。

サンプリングが発生しやすい条件は以下の通りです。

日付範囲が長い（90日以上）
ディメンションの組み合わせが多い
カスタムディメンションを含むクエリ
アクティブユーザー数が多いプロパティ

BigQueryコネクタの特徴

BigQueryコネクタは、GA4からBigQueryにエクスポートされたデータをSQLで取得する方式です。

メリット

サンプリングなし: 全データを正確に集計できる
SQLで自由に加工: UNNEST、ウィンドウ関数、サブクエリなど何でも使える
イベントパラメータを完全に展開: event_params をUNNESTして任意のカスタムパラメータにアクセス可能
他のデータソースとJOINできる: CRM、広告データ、マスタテーブルなどとの結合
パフォーマンスの制御: マテリアライズドビューやBI Engineで最適化可能

デメリット

BigQueryの課金が発生: クエリのスキャン量に応じた料金（1TB約$6.25）
SQL知識が必要: GA4のテーブル構造を理解してSQLを書く必要がある
初期設定に手間がかかる: GA4→BigQueryのエクスポート設定が前提
データの反映に遅延: エクスポートは通常1日1回（ストリーミングエクスポートは有料）

具体的な比較

比較表

項目	GA4コネクタ	BigQueryコネクタ
設定の手軽さ	簡単	やや複雑
サンプリング	あり（条件次第）	なし
データ粒度	セッション・イベント単位	イベント単位（raw）
カスタムパラメータ	制限あり	自由にアクセス
SQL	不可	可
費用	無料	BigQuery課金あり
リアルタイム性	高い	1日遅延（標準）
他データとの結合	ブレンディングのみ	SQL JOINで自在

ユースケース別の推奨

GA4コネクタが向いているケース:

月次のセッション数やPV数を見るだけの簡易レポート
社内の非エンジニアが自分でダッシュボードを触る場合
BigQueryの利用が社内で承認されていない場合
データ量が少なく、サンプリングが発生しないプロパティ

BigQueryコネクタが向いているケース:

ECサイトの売上分析（購入イベントの詳細な内訳）
ファネル分析やコホート分析などの高度な集計
広告データやCRMデータと結合した統合ダッシュボード
正確な数値が求められるKPIレポート

BigQueryコネクタでの接続方法

前提条件

GA4のBigQueryエクスポートが有効になっていることが前提です。

GA4管理画面 →「管理」→「BigQueryのリンク」
BigQueryプロジェクトを選択
エクスポートの頻度（毎日 or ストリーミング）を選択
連携を有効化

Looker Studioでの接続手順

方法A: テーブルを直接指定する

Looker Studioで「データソースを追加」→「BigQuery」を選択
プロジェクト → データセット → テーブルを選択
GA4のイベントテーブル（events_*）を選択

方法B: カスタムクエリを使う（推奨）

「カスタムクエリ」を選択
SQLを入力する

SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  device.category AS device,
  traffic_source.source AS source,
  traffic_source.medium AS medium,
  COUNT(DISTINCT CONCAT(
    user_pseudo_id,
    CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING)
  )) AS sessions,
  COUNT(DISTINCT user_pseudo_id) AS users,
  COUNTIF(event_name = 'purchase') AS purchases,
  SUM(ecommerce.purchase_revenue) AS revenue
FROM
  `project.analytics_XXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY))
GROUP BY
  date, device, source, medium

💡 補足

カスタムクエリを使う場合、「日付パラメータを有効にする」にチェックを入れると、Looker Studioの日付フィルタがSQLのWHERE句に自動的に反映されます。BigQueryのスキャン量の削減にもつながります。

段階的な移行戦略

いきなりBigQueryに全面移行するのではなく、段階的に進めるのが現実的です。

フェーズ1: GA4コネクタで基本ダッシュボードを作る

まずはGA4コネクタで、セッション数・PV数・コンバージョン数といった基本KPIのダッシュボードを作成します。このフェーズでは費用がかからず、すぐに運用を始められます。

フェーズ2: BigQueryエクスポートを有効化する

GA4コネクタのサンプリングや柔軟性に限界を感じたら、BigQueryエクスポートを有効化します。データの蓄積は早めに始めておくのがポイントです。過去に遡ってエクスポートはできません。

フェーズ3: 重要なグラフからBigQueryコネクタに切り替える

すべてのグラフを一度に切り替える必要はありません。正確性が求められるKPIや、カスタムパラメータが必要な分析から順に、BigQueryコネクタに切り替えていきます。

フェーズ4: マテリアライズドビューでコスト最適化

BigQueryの利用量が増えてきたら、マテリアライズドビューやBI Engineを導入してコストを最適化します。

まとめ

GA4コネクタとBigQueryコネクタは、それぞれ異なる強みがあります。

手軽さ・低コスト重視: GA4コネクタ
正確性・柔軟性重視: BigQueryコネクタ

実際の運用では、両方を併用するのも有効な選択肢です。基本的なトラフィックレポートはGA4コネクタで、EC売上やROAS分析はBigQueryコネクタで、というように使い分けることで、コストと利便性のバランスが取れます。