「どの経路から来たトライアルユーザーが、実際にどのページを見て、どこで離脱したのか」―― こうした分析を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のみ」で調べた場合と「GA4 + BigQuery」で調べた場合とで、 結果がどう変わるか試してみてください。
| 訪問者 | 行動 | 見たページ |
|---|---|---|
| 訪問者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 |
サーバーにはトライアルコードの発行記録があるだけで、発行前の閲覧行動は含まれていません。
「GA4のみ」を選ぶと、どのトライアルコードを選んでも必ず「わかりません」という結果になります。 これは、GA4のデータの中にそもそもトライアルコードという情報が存在しないためです。 一方「GA4 + BigQuery」に切り替えると、発行者が誰で、発行前にどのページを見ていたかが具体的にわかります。
なお、TR-2093のように、サーバー側には発行ログがあってもGA4側に対応するデータが見つからないケースもあります。 この場合はBigQueryで突き合わせても行動までは追えず、「計測が漏れている可能性がある」という現実的な限界も体験できます。
今回はトライアルコードを例にしましたが、同じ考え方は次のような「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との組み合わせで解決できる可能性があります。