BtoB SaaS のマーケを 1〜数人で回していると、GA4 の標準レポートでは追いきれない場面に何度か遭遇します。イベント単位で深掘りしたい、サンプリングがかかって数字が揺れる、保持期間を超えた長期の突合ができない、といった壁です。BigQuery を入れるべきか、入れるとして何から始めるのか、迷う入口があります。
結論から書きます。GA4 と BigQuery の連携は、つなぐ手順そのものより「つなぐ前にどう設計するか」で成否が分かれます。実装手順は検索すれば多くの記事に出てくるので、本記事は当事者の設計判断、内製で立ち上げる費用と工数、規模別にいつ入れるべきかの判断軸、の3点に紙幅を寄せます。
この記事は、事業会社で BtoB SaaS のマーケを担当し、GA4 / BigQuery / Looker Studio / AB testing で実務を回してきた立場から書きます。計測設計を業務委託で内製化してきた文脈も踏まえた整理です（BtoB SaaS マーケ業務委託の経験）。
私自身、ある BtoB SaaS 企業で GA4 と BigQuery を内製で立ち上げた経験があります。最初に詰まったのはイベント設計でもパーティションでもなく、何を測りたいかの合意でした。設計を先に固めずに実装に入ると、Looker Studio に接続した時点で「この数字、何の意思決定に使うのか」が抜けていて、結局やり直したと感じています。
※本記事には、A8.net を通じたアフィリエイトリンクが含まれます。読者の支払額は変わりません。
GA4とBigQueryは「つなぐ前」の設計で決まる
GA4 と BigQuery の連携と聞くと、管理画面から数クリックで終わる接続作業を想起しがちです。実務感覚としては、接続そのものは難所ではありません。手戻りの大半は、どのイベントを、どんなテーブル構造で、何の意思決定のために BQ に流すかを、つなぐ前に決め切れていないことから生まれます。
本記事は実装手順より、設計・費用・規模別の判断軸に紙幅を寄せます。LP 公開後の計測から計測の話に入った方は、その続きとしての基盤づくりが本記事のスコープです（LP公開後30日の計測設定）。
GA4単体で足りるか、BigQueryを入れる規模別の判断フレーム
BQ を入れるべきかは、機能比較ではなく事業フェーズの話だと整理しています。GA4 単体で足りる規模で BQ を入れると運用工数だけが先行し、逆に GA4 で取りきれない壁に当たってから動き出すと過去データが取れない、という両側の手戻りがあります。
GA4単体で足りる規模・足りなくなる兆候
GA4 単体で粘れる規模は、月間イベント数が比較的少なく、標準レポートの粒度で意思決定がまわっている段階です。足りなくなる兆候は、探索レポートでサンプリング表示が頻発する、保持期間を超えた長期突合をしたい、イベントパラメータ単位で深掘りしたい、の3つに集約されると感じています。事業会社マーケが現場で痛みを感じ始めるのは、おおむねこの3兆候のいずれかです。
月間イベント数・サンプリング上限を判断トリガにする
判断トリガとして扱いやすいのは、探索レポートのサンプリングです。経験上の目安として、サンプリングが頻繁にかかるようになると分析の信頼性が体感で落ち、事業フェーズより先に数字側の兆候が出ます。
規模別「入れる / まだ不要」の早見表
| 事業フェーズ | 月間イベント目安 | GA4単体で足りるか | BQ導入の判断 | 主な理由 |
|---|---|---|---|---|
| 初期 | 少なめ | 足りる | まだ不要 | 標準レポートの粒度で意思決定が回る |
| 成長期 | 中程度 | 場合による | 兆候を見て判断 | サンプリング・保持期間の壁が見え始める |
| 拡大期 | 多め | 足りない場面が増える | 導入を検討 | イベント深掘り・長期突合の必要性が出る |
| 定着期 | 常時多い | 足りない | 導入 | サンプリング常態化、データ基盤として必要 |
私自身、規模判断で一度迷った場面があります。事業フェーズ的にはまだ早いと判断して BQ 導入を見送ったところ、半年後にサンプリングの壁に当たって結局入れた、という順序になりました。現場感覚として、兆候が出てから動くと過去データの欠損が痛むため、兆候の一歩手前で準備を始めるのが結果的に手戻りが少なかった、と感じています。発注前の計測設計から踏み込む読者の方は、発注前の計測設計 も併せて参照してください。
GA4 → BigQuery エクスポートの実装手順と、つまずきやすい点
実装手順そのものは公式ドキュメントが整っているので、本節では事業会社マーケがつまずきやすい点に絞って整理します。手順を網羅するより、つまずきの一言メモの方が実務では効くと考えているためです。
GA4 管理画面から BigQuery リンクを設定する流れ
大まかな流れは、GCP プロジェクトを用意し、BigQuery API を有効化し、GA4 の管理画面から BigQuery リンクを設定する順です。マーケが運用主体になる場合は、専用プロジェクトに切る方が後の権限整理が楽になると感じています。
連携で最初につまずきやすい点
つまずきやすい点は3つです。GCP プロジェクトの権限（編集権限がないとリンク自体が完了しない）、リンク先リージョン（後から変更不可）、Streaming と Daily の選択（当日中の参照が必要な場合のみ Streaming）です。
エクスポート前に決めるデータ範囲・保持・課金の初期設定
連携設定の前に決めておくべき初期設定は、エクスポート対象イベント範囲、データ保持期間、Streaming と Daily の課金差の3点です。後から戻すのが面倒なものほど初期で固定されます。
エクスポートするイベント範囲と除外設定
立ち上げ初期は全イベントを流し、運用が落ち着いた段階で除外候補を判断する順序の方が、後から欲しいイベントが取れなかった事態を防げると感じています。
Daily export と Streaming export の課金差を最初に押さえる
Daily と Streaming は課金体系が異なります。Streaming は当日中にデータが入る代わりに従量課金が発生するため、リアルタイム性が要件にないなら Daily で十分です。当日中の判断が必要な分析は GA4 側で行い、BQ は翌日以降の深掘りに使う、という役割分担で組むと初期コストが抑えやすくなります。
KGIから逆算するGA4イベント設計（BtoB SaaSの当事者視点）
ここから当事者目線の設計に入ります。BtoB SaaS のマーケで GA4 イベントを設計する時、最初に置くべきはイベント名の網羅ではなく、KGI からの逆算です。受注なのか商談なのか、KGI を一つに絞らないと event_name の優先順位がつかず、結果として「とりあえず計測」のイベントが増えて運用が崩れます。
KGI（受注・商談）から逆算した event_name 命名
BtoB SaaS の典型的な KGI は商談化と受注で、サイト計測では商談化の手前までを GA4 で追うのが基本です。event_name は中間ゴール（資料DL、無料トライアル申込、問い合わせ）まで命名規則を揃え、後段の userProperty と整合させます。命名は途中で変えると過去データが分断されるため、最初に時間をかけるべき設計工程です。
BtoB SaaS で測るべきイベントの優先順位
優先順位の付け方は、KGI に近いものから順です。商談化（問い合わせ・デモ依頼）が最優先、その次に資料DL・無料トライアル、最後に汎用イベント（ボタンクリック、スクロール）の順で詰めると、後段の分析で迷いが出ません。優先度の低いイベントを先に整備すると、肝心の KGI 周辺の精度が後回しになりがちです。
イベント設計の詳細は別記事で扱う予定です（BtoB SaaSのGA4イベント設計、公開準備中）。本記事では HUB として優先順位の付け方までを整理します。
マーケ実務目線でのコメント：event_name の命名規則は社内ドキュメントに落として、誰が見ても同じ命名になる状態を作る方が、長期で見て分析側の信頼性が上がる、と現場感覚として感じています。命名が個人技だと、担当者が変わったタイミングで一度断絶します。
userPropertyとカスタムディメンションの設計判断
イベント設計と並行で詰めるのが userProperty とカスタムディメンションです。何を持たせ、何を持たせないか、スコープを event にするか user にするかの判断で、後段の分析の自由度が決まります。
userProperty に何を持たせ、何を持たせないか
userProperty は、ユーザー単位で長期的に紐づけたい属性に絞るのが基本です。BtoB SaaS では、プラン区分、業種、ライフサイクルステージ（リード、商談、顧客）のあたりが現実的な候補です。逆に、訪問単位で変わる属性や、PII（個人を識別する情報）に近いものは userProperty に持たせない方が安全だと感じています。
カスタムディメンションのスコープ選定でハマる点
カスタムディメンションのスコープは event か user の二択です。event スコープは「その訪問・その操作の文脈」、user スコープは「そのユーザー全体に共通する属性」と切り分けると判断が安定します。一度設定したスコープを後から変えると、過去データの読み替えが必要になります。
BigQuery exportのテーブル設計とパーティション選定
GA4 から BQ にエクスポートされるテーブルは、events_YYYYMMDD と events_intraday_YYYYMMDD の2系統です。日次の確定データが events_、当日リアルタイムが events_intraday_ で、分析の用途が異なります。日次バッチ集計は events_、当日中のモニタリングは events_intraday_、と最初に役割を切っておくと運用が楽になります。
events_ / events_intraday_ の構造と日次パーティション
events_ テーブルは日次でパーティションが切られた状態で生成されます。クエリの際は WHERE 句で対象日を絞らないと全期間スキャンが走り課金が跳ねるため、実装直後の段階で日付絞り込みを運用ルールに置いておく方が後から焦るより安全だと感じています。
クエリ課金を抑えるパーティション・クラスタリングの選定
BQ のクエリ課金はスキャンしたデータ量で決まるため、パーティションとクラスタリングの設計が直接効きます。GA4 export のテーブルは日付パーティションが既定で入っているので、追加で意識すべきは派生テーブルを作る時の設計です。中間テーブルでよく使う絞り込み列にクラスタリングを設定すると、後段のクエリコストが下がります。
設計を運用に乗せる — 命名規則と更新の分担
設計を「作って終わり」にしないために必要なのが、命名規則ドキュメントと変更管理、そして1〜数人体制での運用分担です。事業会社マーケが内製で持つ場合、設計者と運用者が同一人物になりやすく、属人化が起きやすい構造があります。
命名規則ドキュメントと変更管理
命名規則は社内のドキュメントツールに置き、追加・変更の履歴を残すのが基本です。GA4 のイベントを増やす場面は運用上で毎回発生するので、その都度ドキュメントに反映する運用フローを最初に決めておく方が、後から命名が分裂するリスクを下げられます。変更管理を仕組みにしておくと、担当が変わっても引き継ぎが軽くなります。
1〜数人マーケ体制での運用分担
1〜数人体制では、設計と実装と分析を同じ人が担うのが現実です。業務委託や外部支援を入れる場合も、最終的な計測仕様の意思決定は事業会社マーケが握る方が、後段の分析で迷いが出にくいと感じています（Naoto の業務委託先）。
私自身、ある事業会社マーケの業務委託で GA4 イベント設計と BQ export 設計を担当した時、最初に時間をかけたのは命名規則と意思決定の置き場所でした。KGI を一つに絞った合意を会議2回で取り、event_name の規則を社内ドキュメントに落とし、userProperty の項目を3つに絞ってリリースする、という順序で進めました。設計を共通言語にしておくと、運用フェーズで「これは何の数字か」を毎回確認する必要がなくなり、結果として運用工数が下がる、と感じています。
マーケ実務目線でのコメント：設計の意思決定権を誰が持つかは、計測の品質を長期で守る要だと考えています。意思決定権が曖昧だと、運用フェーズで「これは誰に確認すべきか」が止まり、計測の鮮度が落ちやすいと感じています。
内製で立ち上げる費用感 — GCP課金と無料枠の実際
内製で立ち上げる場合の費用は、GCP の課金が主で、Looker Studio は基本無料の構成です。ここで知りたいのは料金体系の説明ではなく、自分の規模だといくらかかるかの目安だと考えています。本節は留保付きのレンジで整理します。
BigQuery の無料枠（ストレージ / クエリ）でどこまで回るか
BigQuery には月単位の無料枠があり、業界相場として、中堅規模の BtoB SaaS であれば無料枠の中で立ち上げ初期は十分に回せる、というのが運用感覚です。立ち上げ直後は格納データ量も少なく、クエリも検証用途が中心になるため、課金がいきなり跳ねることは稀だと感じています。
月間イベント規模別の GCP 月額の目安
運用に乗ってからの GCP 月額は、データ量とクエリ頻度で決まります。経験上の目安として、月数千円から数万円のレンジに収まる規模感が多いと感じています。これは中堅 BtoB SaaS のデータ量を前提とした肌感で、扱うイベント数・派生テーブルの作り方・クエリの最適化次第で大きく上下します。料金は GCP の公式ページで都度確認するのが安全です。
内製の工数 — Looker Studio接続までにかかる実時間
費用と並んで見立てたいのが工数です。内製でゼロから組む場合、設計、エクスポート、Looker Studio 接続まで通すのに、どれくらいの時間がかかるか。本節も経験上の目安として、レンジで整理します。
設計 → エクスポート → Looker Studio 接続までの工程と工数目安
工程は大きく、KGI 合意と命名規則の設計、GA4 と BQ のリンク設定、エクスポート確認、Looker Studio 接続、ダッシュボード初期作成の5段階に分けられます。経験上の目安として、設計に1〜3週間、実装と確認に数日、Looker Studio の初期接続とダッシュボード作成に数日、合計で1〜2か月のレンジに収まる感覚です。設計に時間がかかるのが特徴で、実装そのものは長くありません。
内製でつまずいて時間を溶かしやすい工程
時間を溶かしやすいのは、KGI 合意と Looker Studio の初期ダッシュボード設計の2か所だと感じています。KGI 合意は社内の意思決定速度に依存するため技術以外の理由で詰まり、ダッシュボードは最初に何を見たいかが固まらないとグラフ選定で迷いが続きます。
マーケ実務目線でのコメント：工数の見立ては「設計に時間がかかる」前提で社内合意を取っておくと、後で焦らずに済むと感じています。実装期間を短く見積もって設計を省くと、後段の分析で取り返しがつかなくなる場面が現実的に起こります。
内製を選ぶ判断軸 — 外注ではなく自分で組む理由
外注と内製、どちらが優れているかではなく、自分の状況に内製が合うかどうかの判断軸として整理します。比較ではなく、内製を選ぶ判断軸として書く方が、現実の意思決定に効くと考えています。
内製が合うケース / 外部に任せた方がよいケース
内製が合うのは、計測の意思決定権を事業会社側で持ちたい場合、運用後の変更を素早く回したい場合、計測スキルを社内資産として積みたい場合です。逆に立ち上げ期間を短く取りたい、社内に SQL / BQ 経験者がいない場合は、外部に立ち上げを任せて運用から内製化する分割もあり得ます。
スキル資産として計測を内製化する価値
計測の内製化は、その時点の費用比較を超えて、組織として計測の意思決定権を持つことの価値が大きいと感じています。私自身、内製で立ち上げた時の費用感は、業界相場として月数千円から数万円の GCP 課金と、設計〜立ち上げの工数として1〜2か月のレンジに収まりました。2026年6月時点の肌感であり、規模により大きく変動しますが、数値の見立ては社内合意を進める材料として実務で機能します。
GA4 + BigQuery + Clarityの計測スタックをどう組むか
GA4 と BigQuery で定量の計測基盤を作った後に視野に入ってくるのが、定性のデータです。代表的な選択肢が Microsoft Clarity で、GA4 と Clarity を併用するとユーザー行動の解像度が一段上がる構成になります。
定量（GA4/BQ）と定性（Clarity）の補完関係
GA4 と BQ で「何が起きたか」を数字で把握し、Clarity のヒートマップとセッション録画で「なぜそうなったか」を補う、という役割分担です。両者は競合ではなく補完で、どちらか一方では拾えない論点があります。Clarity 単体での実装手順や BtoB SaaS での使い方は、別記事で詳しく整理しています（Microsoft Clarity の使い方）。
BigQueryに入れたデータの使い道 — SQLと可視化の入口
BQ に貯めるだけでは意思決定は前に進みません。SQL でクエリを書き、Looker Studio で可視化する流れまで含めて連携が完成します。本節は最初の SQL と可視化の入口に絞ります。
最初に書く1本目の SQL
最初の SQL は、イベント数の日次推移を出すクエリが現実的です。SELECT 句で event_date と event_name を集計し、特定の event_name に絞って日次の発火数を時系列で出す、という単純な形から始めると、テーブル構造の把握とクエリ書き方の練習が同時にできます。ここで日付パーティションの絞り込みを毎回 WHERE 句に入れる癖をつけると、後段の課金事故を予防できます。
ある BtoB SaaS の運用で BQ のデータを使い始めた時、GA4 の標準レポートでは見えなかった「特定イベントの曜日別偏り」が見えたことがありました。標準レポートではならされていた数字が、日次で並べると傾向が立ち上がる、という形です。発火タイミングを変える検討の材料にしやすくなった、と感じています。
可視化（Looker Studio）への接続の入口
BQ から Looker Studio への接続は無料で、データソースとして BigQuery を選ぶだけで使い始められます。最初のダッシュボードは、イベント数の時系列、KGI 周辺指標の推移、流入元別の内訳の3枚に絞ると初期に必要な視点が揃います。詳細は別記事で扱う予定です（Looker Studio で BtoB マーケが見るダッシュボード、公開準備中）。
まとめ — BtoB SaaSマーケがGA4+BQで最初に踏む順序
本記事の論点を、最初に踏む順序として束ねます。GA4 と BigQuery の連携は、つなぐ手順より「つなぐ前にどう設計するか」で成否が分かれる、という主張に戻ります。
- 規模判断：GA4 単体で粘れるか、BQ を入れるべきかを兆候ベースで判断する
- 設計：KGI から逆算した event_name の命名規則、userProperty の項目選定、BQ の運用ルールを先に固める
- 実装：GCP プロジェクト権限・リージョン・Streaming/Daily の選択を最初に決める
- 費用と工数：業界相場として GCP は月数千円から数万円のレンジ、工数は1〜2か月のレンジで見立てる（2026年6月時点の経験上の目安）
- 運用：命名規則ドキュメントと意思決定権の置き場所を最初に決め、属人化を避ける
- 計測スタック：定性データの補完として Microsoft Clarity を併用する選択肢を持つ
私自身、GA4 と BigQuery をゼロから内製で組んだ全体を振り返ると、最初に戻るなら最も時間をかけるのは KGI 合意と命名規則の2つだと感じています。実装は手順通りに進められますが、設計を後回しにした分はほぼ確実に運用フェーズで返ってきます。設計を先に固めるという順序が、結果的に手戻りを最小にする現実解だと、立ち上げを通じて受け止めています。
