標準レポートを超えて、顧客行動と事業成果をつなぐ方法
GA4の標準レポートは、Webサイトやアプリの状況を把握するうえで便利なツールです。ユーザー数、ページビュー、流入チャネル、コンバージョン数などを、画面上で素早く確認できます。
一方で、マーケティング施策やコンテンツ改善を進めるなかでは、次のような疑問を持つことも少なくありません。
- 資料請求したユーザーは、コンバージョン前にどのコンテンツを見ていたのか
- 初回訪問から問い合わせまで、どの程度の期間がかかっているのか
- 問い合わせ数ではなく、商談化・受注につながっている流入施策は何か
- CRMやSFAのデータと組み合わせ、Web施策の事業貢献を評価できないか
- 毎週・毎月のレポート作成を自動化できないか
こうした問いに答えるための基盤となるのが、GA4とBigQueryの連携です。
本記事では、GA4 BigQuery連携でできること、代表的な活用ユースケース、導入時に押さえておきたいポイントを解説します。
GA4標準レポートだけでは難しいこと
GA4の標準レポートや探索レポートは、日常的なサイト状況の確認に適しています。
たとえば、以下のような分析は比較的行いやすいでしょう。
- ユーザー数やセッション数の推移
- ページ別の閲覧数
- 流入チャネル別のコンバージョン数
- デバイス別・地域別の利用状況
- イベント数やコンバージョン数の確認
一方で、分析要件が複雑になると、標準機能だけでは扱いにくいケースがあります。
| 分析したいこと | GA4標準レポートでの扱いやすさ |
|---|---|
| ユーザー数、PV、CV数の確認 | ○ |
| 流入チャネル別の成果確認 | ○ |
| CV前に閲覧されたページの詳細分析 | △ |
| 複数セッションをまたいだ行動分析 | △ |
| 独自ルールによるKPI算出 | △ |
| CRM/SFA・受注データとの統合 | × |
| 定型データ加工・レポートの自動化 | △ |
つまり、GA4の画面は「定型的なレポートを見る」ことには強い一方で、BigQueryを使うと「自社固有の問いに合わせてデータをつくる」ことが可能になります。
GA4×BigQuery連携とは
GA4には、収集したイベントデータをGoogle CloudのデータウェアハウスであるBigQueryへエクスポートする機能があります。
連携すると、GA4で収集したデータをイベント単位でBigQueryに蓄積し、SQLを使って抽出・加工・集計できるようになります。
Webサイト/アプリ
↓
GA4
↓
BigQueryへイベントデータをエクスポート
↓
SQLによる抽出・集計・他データとの統合
↓
Looker Studio/BIツール/社内レポート/データ基盤
それぞれの役割を整理すると、次の通りです。
| コンポーネント | 主な役割 |
|---|---|
| GA4 | Webサイト・アプリ上のユーザー行動を収集する |
| BigQuery | 詳細データを蓄積し、SQLで加工・分析する |
| Looker Studio / BIツール | 集計結果を可視化し、レポートとして提供する |
| CRM / SFA | リード、商談、受注などの営業・事業データを管理する |
BigQuery連携によって、Web解析を単なるアクセス分析で終わらせず、コンテンツ改善、広告評価、営業成果の可視化へと発展させられます。
BigQueryに連携されるGA4データの基本構造
GA4からBigQueryへエクスポートされるデータは、基本的に日別のイベントテーブルとして格納されます。
analytics_XXXXXXXXX
├─ events_20250101
├─ events_20250102
├─ events_20250103
└─ ...
代表的な項目は以下の通りです。
| 項目 | 内容 |
|---|---|
| event_date | イベントが発生した日付 |
| event_timestamp | イベントの発生日時 |
| event_name | page_view、session_start、generate_lead など |
| user_pseudo_id | GA4が付与する匿名のユーザー識別子 |
| event_params | ページURL、セッションID、クリック情報など |
| traffic_source | 流入元、メディア、キャンペーン情報 |
| device | デバイス、OS、ブラウザ情報 |
| geo | 国、地域などの地理情報 |
GA4データを扱う際の特徴は、URLやセッションIDなどの詳細情報が、event_params というネスト構造の中に格納されている点です。
たとえば、page_view イベントから閲覧URLを取り出すSQLは次のようになります。
SELECT
event_date,
event_name,
user_pseudo_id,
(
SELECT value.string_value
FROM UNNEST(event_params)
WHERE key = 'page_location'
) AS page_location
FROM
`project_id.analytics_XXXXXXXXX.events_*`
WHERE
_TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
AND event_name = 'page_view';
UNNEST を使うことで、イベントパラメータの中から必要な情報を抽出できます。
ユースケース1:コンバージョンに貢献したコンテンツを特定する
最初に取り組みやすく、成果にもつながりやすいのが、コンバージョン前に閲覧されたコンテンツの分析です。
たとえばBtoBサイトの場合、以下のような流れが考えられます。
検索/広告/SNSなどから流入
↓
ブログ記事・導入事例・サービスページを閲覧
↓
資料請求・問い合わせ
ここで知りたいのは、単純なPV上位ページではありません。
重要なのは、次の問いです。
資料請求や問い合わせを行ったユーザーは、その前にどのコンテンツを閲覧していたのか?
この分析によって、以下のような示唆を得られます。
- PVは多くないが、CVユーザーによく見られている記事
- 商談につながる可能性が高い導入事例やサービスページ
- CTAの設置や内部リンクを強化すべきコンテンツ
- リライトや広告配信を優先すべきテーマ
簡易的には、コンバージョンしたユーザーを抽出し、そのユーザーが見たページを集計します。
WITH conversion_users AS (
SELECT DISTINCT
user_pseudo_id
FROM
`project_id.analytics_XXXXXXXXX.events_*`
WHERE
_TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
AND event_name = 'generate_lead'
),
page_views AS (
SELECT
user_pseudo_id,
(
SELECT value.string_value
FROM UNNEST(event_params)
WHERE key = 'page_location'
) AS page_location
FROM
`project_id.analytics_XXXXXXXXX.events_*`
WHERE
_TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
AND event_name = 'page_view'
)
SELECT
page_location,
COUNT(DISTINCT user_pseudo_id) AS converted_users
FROM
page_views
WHERE
user_pseudo_id IN (
SELECT user_pseudo_id
FROM conversion_users
)
GROUP BY
page_location
ORDER BY
converted_users DESC;
実運用では、単に「CVユーザーが見たページ」を集計するだけではなく、以下のような条件を加えると分析精度が高まります。
- CV発生前に閲覧したページだけに絞る
- 同一セッション内の行動に限定する
- ブログ、導入事例、サービスページなどのカテゴリ単位で集計する
- 流入チャネルごとに比較する
- 初回訪問ユーザーと再訪ユーザーを分ける
コンテンツ評価をPV中心から、事業成果への貢献度中心へ切り替えられることが、この分析の大きな価値です。
ユースケース2:初回訪問からCVまでの期間を分析する
BtoB商材や高額商材では、初回訪問の直後にコンバージョンするユーザーばかりではありません。
ユーザーは複数回サイトを訪問し、記事や導入事例を読み、サービス比較や社内検討を経てから資料請求や問い合わせに至ることがあります。
初回訪問
↓
記事閲覧・情報収集
↓
再訪・比較検討
↓
導入事例・サービス詳細の確認
↓
資料請求/問い合わせ
ここでの分析テーマは次の通りです。
ユーザーは初回訪問から何日後にコンバージョンするのか?
この結果は、広告施策やナーチャリング施策の設計に活用できます。
| 分析結果 | 活用例 |
|---|---|
| CVまでの平均・中央値日数 | 広告施策の評価期間を設定する |
| 7日以内にCVする割合 | 短期施策の効果を判断する |
| 30日以上かけてCVする割合 | 中長期のコンテンツ・メール施策を検討する |
| 再訪回数とCV率 | リマーケティングや再訪促進施策を検討する |
| チャネル別のCV期間 | チャネルごとの役割を整理する |
たとえば、検索流入は初回訪問から短期間でCVしやすく、SNS流入は接触からCVまで時間がかかる、といった違いが見えてくるかもしれません。
このような違いを理解せず、短期的なCV数だけで施策を評価すると、中長期で有効な施策を過小評価するリスクがあります。
ユースケース3:CRM/SFAと統合して商談・受注まで評価する
GA4だけでも、Webサイト上のコンバージョンまでは計測できます。
しかし、BtoBマーケティングで本当に知りたいのは、「問い合わせがあったか」だけではなく、その問い合わせが商談化し、最終的に受注につながったかどうかではないでしょうか。
そのためには、GA4の行動データと、CRMやSFAに蓄積される営業データを統合することが重要です。
GA4データ CRM/SFAデータ
───────── ─────────
流入チャネル リード情報
閲覧コンテンツ 商談ステータス
コンバージョンイベント 商談金額
セッション・ユーザー行動 受注状況
│ │
└──────┬──────┘
↓
Web施策から商談・受注までを一貫して分析
統合できると、たとえば以下のような分析が可能になります。
- 商談化率・受注率が高い流入チャネルは何か
- 受注顧客が閲覧していたコンテンツは何か
- リード数は多いが、商談や受注につながりにくい施策は何か
- 顧客化しやすいユーザーには、どのような行動傾向があるか
- 広告費を含めて施策別のROIやCACを評価できるか
この状態を実現できれば、マーケティング活動を「リード獲得数」だけで評価するのではなく、売上・受注への貢献度で評価できるようになります。
個人情報の取り扱いには注意
CRMやSFAとのデータ統合では、個人情報保護とデータガバナンスへの配慮が欠かせません。
特に、GA4に以下のような個人を直接特定できる情報を送信してはいけません。
- メールアドレス
- 氏名
- 電話番号
- 住所
- その他、個人を特定可能な情報
データ統合を行う場合は、プライバシーポリシー、ユーザー同意、社内ルール、アクセス権限、ID設計を確認したうえで進める必要があります。
GA4×BigQuery活用を成功させる3つのポイント
BigQuery連携は、設定すれば自動的に価値が出るものではありません。データを「使える状態」にするためには、目的・計測・運用をあわせて設計する必要があります。
1. 連携前に「分析したい問い」を決める
ありがちな失敗は、「とりあえずデータを貯める」ことを目的にしてしまうことです。
| よくある始め方 | 望ましい始め方 |
|---|---|
| まずBigQueryへ連携する | CVに寄与するコンテンツを知りたい |
| データを蓄積してから考える | 商談化しやすい流入チャネルを評価したい |
| 先にダッシュボードを作る | 月次レポート作成を自動化したい |
BigQueryは自由度が高いからこそ、分析目的が曖昧だと「データはあるが活用されない」状態になりがちです。
まずは、以下のように具体的な問いを一つ設定することをおすすめします。
コンバージョンしたユーザーは、その前にどのコンテンツを見ていたのか?
2. イベント・パラメータの設計を整える
BigQueryで分析できる範囲は、GA4で正しく収集できているデータの範囲に依存します。
そのため、GA4のイベント設計やパラメータ設計が重要です。
確認したいポイントは次の通りです。
- CVイベントの定義が明確か
- イベント名が重複・乱立していないか
- パラメータ名や値の表記が統一されているか
- コンテンツカテゴリやコンテンツIDを取得できているか
- CTA、フォーム、資料ダウンロードなどの主要導線を計測できているか
- 計測仕様書が整備され、変更履歴を管理できているか
たとえば、ブログ分析を行うなら、URLだけではなく記事カテゴリ、記事ID、公開日、著者、コンテンツタイプなどを扱えるようにしておくと、より深い分析が可能になります。
3. コストと運用を意識する
BigQueryでは、保存容量やクエリ処理量に応じてコストが発生します。
特にGA4のイベントデータは日々蓄積されるため、何も考えずに全期間・全列を対象としたクエリを繰り返すと、コストや処理時間が増加します。
基本的な対策として、以下を意識するとよいでしょう。
- "_TABLE_SUFFIX" で分析対象期間を絞る
- "SELECT *" を避け、必要な列だけを指定する
- 日次・週次・月次の集計テーブルを作成する
- 定型処理はスケジュール実行する
- BIツールから生データを直接・頻繁に参照しない
- データ品質を定期的に確認する
データ量が増えたあとに見直すのではなく、最初から利用目的と運用方法をセットで設計することが重要です。
まず取り組むなら「CV前に見られたコンテンツ」の可視化から
GA4×BigQuery連携には、行動分析、広告評価、CRM統合、レポート自動化など、多くの可能性があります。
ただし、最初からすべてを実現しようとすると、イベント設計やデータ統合、運用設計が複雑になり、プロジェクトが進みにくくなります。
最初のテーマとしておすすめなのは、次の問いです。
コンバージョンしたユーザーは、その前にどのコンテンツを見ていたのか?
このテーマであれば、Web担当者、マーケティング担当者、コンテンツ担当者のいずれにも活用イメージを持ってもらいやすく、具体的な改善アクションにもつなげやすいためです。
たとえば、分析結果をもとに以下のような施策を実施できます。
- CV貢献度の高い記事をリライトする
- 記事内CTAや内部リンクを改善する
- 導入事例やサービスページへの導線を強化する
- 成果につながるテーマの記事を増やす
- 広告の遷移先として優先的に活用する
まとめ
GA4とBigQueryを連携することで、GA4の標準レポートだけでは扱いにくい詳細なユーザー行動や、複数セッションにまたがるコンバージョン、CRM・SFAとの統合分析が可能になります。
重要なのは、BigQuery連携そのものを目的にしないことです。
「どのコンテンツが商談につながっているのか」
「どの流入施策が受注に貢献しているのか」
「CVまでの検討期間に合わせて、どのような施策を設計すべきか」
こうした事業上の問いに答えるために、イベント設計、データ加工、可視化、運用を整えていくことが、GA4×BigQuery活用の本質です。
まずは一つの具体的な分析テーマから始め、データを意思決定と改善アクションにつなげていきましょう。
Google Cloud、Google Workspace に関するご相談はXIMIXへ!
Google Cloud、Google Workspaceに関する お問い合わせはこちら
執筆者紹介
- カテゴリ:
- Google Cloud