「どの経路から来たトライアルユーザーが、実際にどのページを見て、どこで離脱したのか」―― こうした分析をGA4とGoogleタグマネージャー(GTM)だけで完結させようとすると、ある壁にぶつかります。 それは、アプリサーバーが発行するトライアルコードのような個人・契約に紐づく情報を、そのままGA4に送ってはいけないという壁です。
この記事では、GA4・GTMだけでは追いきれない領域を、BigQueryを使ってどう補うかを、 「無料トライアルユーザーの行動分析」を例に、実際に手を動かして仕組みを確認できる体験デモを交えながら解説します。
GA4もGTMも、あくまで「ブラウザ上で起きたイベント」を計測する仕組みが前提です。 ページの閲覧、クリック、フォーム送信といったイベントをタグとして発火させ、GA4に送信します。
一方、トライアルコードはアプリサーバー側で発行され、契約情報や個人情報と紐づいて管理されているケースがほとんどです。 こうした情報をそのままGA4のイベントパラメータとして送信してしまうと、Google広告・アナリティクス利用規約が禁止している 「個人を特定できる情報(PII)の送信」に抵触するおそれがあります。GTMのタグ設定をどれだけ工夫しても、 この制約自体は回避できません。
結果として、「このトライアルコードを使った人が、サイト上で何をしていたか」という、事業上もっとも知りたい問いに、 GA4の管理画面だけでは答えられないという状態になります。
GA4・Search Console・GTM・Google広告のAPIを使った自動化の全体像は APIでアクセス解析を自動化する仕組み で解説しています。今回のBigQueryによる分析も、この自動化の延長線上にある応用パターンのひとつです。
ここで重要なのは、「トライアルコードをGA4に送る」のではなく、「GA4が持つ匿名の識別子(client_id)をアプリサーバー側に渡す」という発想の転換です。
GA4は、ブラウザごとにclient_id(BigQueryエクスポート上ではuser_pseudo_id)という匿名の識別子を自動的に発行しています。
この値自体には個人情報は含まれていません。ユーザーがトライアルコードを発行する画面まで進んだタイミングで、
このclient_idをJavaScriptで取得し、アプリサーバーへのリクエストに一緒に送信してサーバー側のログに記録しておきます。
こうしておくと、GA4側には通常どおりのイベントデータが、アプリサーバー側には「どのclient_idがいつどのトライアルコードを発行したか」というログが、 それぞれ独立して溜まっていきます。この2つを後から突き合わせるために使うのがBigQueryです。
GA4には、計測データをそのままBigQueryにエクスポートする無料の機能(BigQueryエクスポート)が用意されています。 これを有効にすると、GA4の管理画面には表示されない「1イベントごとの生データ」をSQLで直接扱えるようになります。
さらに、アプリサーバー側のログ(トライアルコード発行履歴など)も同じBigQuery上のデータセットに取り込んでおけば、 GA4のイベントデータと、自社サーバーのログを、共通のキー(client_id)でJOINして分析することができます。 これは、GA4の管理画面や、Looker Studioのような可視化ツールだけでは実現できない領域です。
たとえば、SaaSサービスで無料トライアルを提供している場合、次のようなデータをBigQuery上で突き合わせることで分析が可能になります。
これにより、「どの流入経路から来たユーザーがトライアルコードの発行に至ったか」「発行後、どのページを見て、どこで離脱したか」 「トライアルコード発行から一定期間内にどれだけサイトに再訪しているか」といった、 GA4の管理画面だけでは見えない粒度の分析が可能になります。タグマネージャーの設定を工夫しても、 個人・契約情報を直接GA4に送らない限りこの分析はできないため、BigQuery側でのJOINが実質的に唯一の手段になります。
文章だけではイメージが掴みにくいため、実際に手を動かして試せるデモを用意しました。 これは「GA4(タグマネージャーで計測したデータ)だけを見た場合」と「GA4とアプリサーバーのログをBigQueryで統合した場合」の違いを比較する体験です。 下のボタンを押すと、バラバラだった2つの記録が統合され、 「どのトライアルコードを発行した人が、その前にどのページを見ていたか」という、 トライアルコードを起点にした行動分析が初めて可能になる様子を確認できます。
左は「GA4(タグマネージャーで計測)だけ」が持っている記録、右は「アプリサーバーだけ」が持っている記録です。 どちらも単独では、トライアルコードを起点にしたユーザー行動は分析できません。 ボタンを押してBigQueryでJOIN(統合)すると、何が分かるようになるかを確認してみてください。
| 訪問者 | 行動 | 見たページ |
|---|---|---|
| 訪問者A (1001.abc) |
ページ閲覧 | ブログ記事 |
| 訪問者B (1002.abc) |
トライアル申込ページ閲覧 | 申込ページ |
| 訪問者C (1003.abc) |
ページ閲覧 | 料金ページ |
| 訪問者D (1004.abc) |
トライアル申込ページ閲覧 | 申込ページ |
| 訪問者E (1005.abc) |
ページ閲覧 | ブログ記事 |
❌ GA4だけでは「誰が実際にトライアルコードを発行したか」は分かりません。
| 訪問者 | トライアルコード | 発行日時 |
|---|---|---|
| 訪問者B (1002.abc) |
TR-2091 | 08/20 10:12 |
| 訪問者D (1004.abc) |
TR-2092 | 08/21 15:03 |
| 訪問者F (1099.abc) |
TR-2093 | 08/22 09:44 |
❌ サーバー側だけでは「発行前にどのページを見ていたか」は分かりません。 (訪問者Fは何らかの理由でGA4に記録が残っていない例です)
上のボタンを押すと、2つの記録を統合した結果がここに表示されます。
「トライアル発行者だけ見る」を選ぶと、実際にトライアルコードを発行した訪問者の行動だけに絞り込めます。 「全訪問者を見る」に切り替えると、トライアルコードを発行していない訪問者も一覧に残り、 「未発行」として区別されます。目的に応じてどちらの見方も選べるのが、BigQuery上でSQLを書く強みです。
なお、訪問者Fのようにサーバー側にはトライアルコードの発行ログがあるのにGA4側に対応するデータがない場合、 GA4起点のJOINでは結果に出てきません。何らかの理由で計測が漏れているケースがある、という点も実務上覚えておく必要があります。
今回はトライアルコードを例にしましたが、同じ考え方は次のような「GA4に直接送れない・送るべきではない情報」を分析したい場面全般に応用できます。
いずれの場合も、「機微な情報そのものをGA4に送る」のではなく、「GA4のclient_idを自社システム側に渡し、BigQuery上で突き合わせる」という設計が基本になります。
| 手順 | 内容 |
|---|---|
| 1. GA4のBigQueryエクスポートを有効化する | GA4の管理画面からBigQueryプロジェクトをリンクし、日次(または必要に応じてストリーミング)エクスポートを設定する |
| 2. client_idをアプリサーバーに渡す仕組みを作る | トライアルコード発行などの重要なアクションが起きたタイミングで、GA4のclient_idを取得しサーバーへ送信・記録する |
| 3. アプリ側のログをBigQueryに取り込む | 発行ログなどの社内データを、GA4と同じBigQueryプロジェクト内のデータセットに定期的にロードする |
| 4. SQLでJOINして分析・可視化する | client_idをキーにGA4データと社内ログをJOINし、必要であればLooker Studioなどのダッシュボードに接続する |
GA4・Search Console・GTM・Google広告のAPI連携の基礎ができていれば、BigQueryへのデータ集約はその延長線上にある取り組みです。 すでにAPI連携の仕組みがある場合は、比較的少ない追加工数でこの分析基盤を構築できます。
GA4・GTMは、個人や契約に紐づく情報をそのまま送信できないという制約があるため、 「トライアルコードを使ったユーザーが何をしたか」のような分析は管理画面の中だけでは完結しません。
「GA4やタグマネージャーの設定をどう工夫しても知りたいことが分析できない」と感じている場合、 その多くはGA4単体の限界であり、BigQueryとの組み合わせで解決できる可能性があります。