プレイブック / 計測設計
LPを作って計測するなら、まずこの型で作る
LP、GA4、GTM、BigQuery、ダッシュボードを最初からつなげて検証するための、一般的な計測設計の型です。
- 種別
- プレイブック
- 使う場面
- 新規LPの検証設計前
- 含むもの
- LP / GA4 / GTM / BQ
Interactive sample
LP操作からBQ蓄積までを触って見る
サンプルLPを操作すると、GTM/GA4イベントとBigQuery exportの行が順番に増えるシミュレータです。
シミュレータを開くStandard funnel
LP計測の基本フロー
着地
lp_view
広告・検索・SNSからLPに到達した状態を記録する
CTA
lp_cta_click
主要CTAがクリックされ、次の行動に進んだことを記録する
フォーム
lead_form_view
入力フォームや予約開始画面に到達したことを記録する
入力
lead_form_input
氏名・連絡先・希望条件など、CV前に必要な情報を入力する
確認
lead_form_confirm
入力内容の確認画面、または送信直前の確認状態を記録する
送信
lead_form_submit
フォーム送信ボタンが押され、送信処理に入ったことを記録する
送信
lead_form_submit
フォーム送信や予約リクエストの実行を記録する
完了
lead_complete
問い合わせ・予約・購入などのCV完了を記録する
Tracking stack
GTM + GA4 前提の計測フロー
LP
DOM/URL状態
ページURL、クリック要素、フォーム表示状態など、GTMが判定できる状態を持つ
GTM
トリガー/タグ管理
ページ表示、クリック、フォーム表示トリガーからGA4イベントタグを発火する
GA4
計測基盤
セッション、流入、イベント、CVを同じプロパティで計測する
BigQuery
分析用ログ
GA4 export を正規化し、ファネルと日次集計を作る
Dashboard
意思決定
媒体、variant、ファネル段階別に勝ち負けを見る
GA4 to BigQuery
GA4からBQへの転送タイプ
GA4 から BigQuery へは、Daily を正本にしつつ、当日確認が必要なら Streaming を併用します。 Streaming を有効にすると当日用の intraday テーブルが作られます。
Daily
events_YYYYMMDD
- タイミング
- 1日1回、前日分の確定寄りデータ
- 役割
- 正式な日次集計、ダッシュボード、レポートの正本
- 注意
- 公開直後の当日検証には遅い。集計ジョブは到着遅延を見込んで動かす。
Streaming
events_intraday_YYYYMMDD
- タイミング
- 当日中に継続投入されるベストエフォートデータ
- 役割
- タグ疎通、LP公開直後の確認、速報、異常検知
- 注意
- 完全性を前提にしない。Daily の events_YYYYMMDD 完成後に削除される。
Table tree
BQ上のテーブル構成サンプル
Daily と Streaming を併用すると、GA4 export 側には日別テーブルと当日用 intraday が並びます。 そのまま使い続けるのではなく、分析用 dataset に正規化・集計して流します。
analytics_123456789
GA4 BigQuery export の生ログdataset
events_20260616
Daily export。前日分の正式集計に使う
event_params
lp_id、variant、funnel_step などがネストで入る
traffic_source / session_traffic_source_*
流入元・媒体・キャンペーン分析に使う
events_20260617
Daily export。翌日に完成する当日分の正本
events_intraday_20260617
Streaming export。当日中の速報・疎通確認用。Daily完成後に削除される
mart_lp_measurement
GA4生ログから作る分析用dataset
normalized_events
event_params を列化したイベント明細
session_funnels
1 session x 1 LP x 1 variant でファネル到達を横持ちにする
daily_lp_summary
ダッシュボードが読む日次・媒体・variant別の薄い集計
Flexible LP formats
LP形式が変わっても同じ設計で受ける
LPの見た目や導線は変わっても、イベント名と最終テーブルの列を固定しておけば比較できます。 CTAをなくして最初からフォームを出す場合は、CTA列を空または0として扱います。
CTAありLP
ファーストビューや訴求を読ませてから、CTAでフォームへ送る通常型
着地
lp_view
→ lp_view_at
CTAクリック
lp_cta_click
→ cta_click_at
フォーム表示
lead_form_view
→ form_view_at
完了
lead_complete
→ complete_at
CTA率とフォーム到達率を分けて見られる
フォーム直出しLP
CTAを置かず、LPの初期表示からフォームを見せる短縮型
着地
lp_view
→ lp_view_at
フォーム表示
lead_form_view
→ form_view_at
フォーム送信
lead_form_submit
→ form_submit_at
完了
lead_complete
→ complete_at
cta_click_at は空、cta_clicks は 0 として同じ表で扱える
GTM setup sample
タグマネのイベント定義サンプル
GTMでは、変数で共通パラメータを持ち、トリガーでユーザー行動を検知し、 GA4イベントタグでイベント名とパラメータを送ります。
変数
| name | type | value | note |
|---|---|---|---|
| 変数_LP_ID | 定数 / URL参照 | lp_measurement_playbook | LPを識別する固定値。複数LPならURLパスから参照する |
| 変数_variant | URL変数 | variant クエリパラメータ | ABテストのvariant。URL、Cookie、配信側値のいずれかから取る |
| 変数_CTA_ID | クリック変数 | クリックID / クリッククラス | どのCTAかを識別する。CTAなしLPでは空でよい |
| 変数_ファネル段階 | イベント設定 | landing / cta / form_view / submit / complete | タグごとに固定値として送る |
| 変数_ページURL | 組み込み変数 | ページURL | GA4にも入るが、LP判定やデバッグ用に使う |
| 変数_フォームステップ番号 | DOM要素 / URL参照 | data-step-index または step クエリパラメータ | ステップ分割フォームで、現在の入力段階を数値で取る |
| 変数_フォームステップ名 | DOM要素 / 参照表 | 基本情報 / 希望条件 / 確認 | ダッシュボードやdebugで人が読めるステップ名として使う |
トリガー
| name | type | condition | fires |
|---|---|---|---|
| トリガー_LP表示 | ページビュー | ページパスが /lp/ に一致 | LP表示時に1回 |
| トリガー_CTAクリック | クリック | クリックIDまたはクリッククラスが主要CTAに一致 | 主要CTAクリック時 |
| トリガー_フォーム表示 | 要素の表示 / ページビュー | フォーム要素が表示された、またはフォームページが読み込まれた | フォームが表示された時に1回 |
| トリガー_フォーム送信 | フォーム送信 / クリック | フォーム送信ボタン、またはsubmitイベント | フォーム送信時 |
| トリガー_フォームステップ表示 | 要素の表示 / 履歴変更 | フォームステップの表示要素、またはURL/履歴のstep変更 | 各ステップが表示された時に1回 |
| トリガー_フォームステップ次へ | クリック | 次へボタン、またはステップ遷移ボタン | ステップを進める操作をした時 |
タグ
| name | type | event_name | trigger | parameters |
|---|---|---|---|---|
| GA4イベント_LP表示 | GA4イベント | lp_view | トリガー_LP表示 | lp_id, variant, funnel_step, page_location |
| GA4イベント_CTAクリック | GA4イベント | lp_cta_click | トリガー_CTAクリック | lp_id, variant, cta_id, funnel_step |
| GA4イベント_フォーム表示 | GA4イベント | lead_form_view | トリガー_フォーム表示 | lp_id, variant, funnel_step |
| GA4イベント_フォーム送信 | GA4イベント | lead_form_submit | トリガー_フォーム送信 | lp_id, variant, funnel_step |
| GA4イベント_フォームステップ表示 | GA4イベント | lead_form_step_view | トリガー_フォームステップ表示 | lp_id, variant, form_step_index, form_step_name |
| GA4イベント_フォームステップ次へ | GA4イベント | lead_form_step_next | トリガー_フォームステップ次へ | lp_id, variant, form_step_index, form_step_name |
| GA4イベント_完了 | GA4イベント | lead_complete | サンクスページ表示、またはCV完了コールバック | lp_id, variant, funnel_step |
Final tables
最終的に見るテーブル
ダッシュボードや日次確認では、GA4 export を直接読まずに、 セッション単位のファネル表と日次集計表を見る形にします。
GA4 raw events
analytics_123456789.events_*
GA4 export の生ログ。毎回直接読む対象ではなく、変換元として扱う。
Normalize
mart_lp_measurement.normalized_events
event_params を列化し、lp_id、variant、funnel_step を通常カラムにする。
Session funnel
mart_lp_measurement.session_funnels
1 session x 1 LP x 1 variant にまとめ、各ファネル到達時刻を横持ちにする。
Dashboard summary
mart_lp_measurement.daily_lp_summary
日次・媒体・variant別に集計し、ダッシュボードはこの薄いテーブルを見る。
session_funnels
1 session x 1 LP x 1 variant のファネル到達テーブル
| event_date | lp_id | variant | source_medium | ga_session_id | lp_view_at | cta_click_at | form_view_at | form_submit_at | complete_at |
|---|---|---|---|---|---|---|---|---|---|
| 2026-06-17 | lp_measurement_playbook | a | google / cpc | 1749367201 | 10:00:01 | 10:00:18 | 10:00:34 | 10:01:02 | 10:01:08 |
| 2026-06-17 | lp_measurement_playbook | b | meta / paid_social | 1749368120 | 10:15:20 | 10:15:51 | 10:16:08 | ||
| 2026-06-17 | lp_measurement_playbook | form_first | google / cpc | 1749369000 | 10:28:02 | 10:28:03 | 10:29:12 | 10:29:16 |
daily_lp_summary
ダッシュボードが読む日次・媒体・variant別の集計テーブル
| event_date | lp_id | variant | source_medium | sessions | cta_clicks | form_views | form_submits | conversions | cvr |
|---|---|---|---|---|---|---|---|---|---|
| 2026-06-17 | lp_measurement_playbook | a | google / cpc | 120 | 42 | 31 | 18 | 14 | 11.7% |
| 2026-06-17 | lp_measurement_playbook | b | meta / paid_social | 96 | 38 | 20 | 9 | 6 | 6.3% |
| 2026-06-17 | lp_measurement_playbook | form_first | google / cpc | 80 | 0 | 56 | 22 | 17 | 21.3% |
BigQuery sample
GA4 export テーブルのサンプル
GA4 から BigQuery に蓄積される生ログは、1イベント1行で見ます。 event_params の中に LP ID、variant、ファネル段階を残しておくと、 後段でセッション別ファネルや日次集計に変換できます。
| event_date | event_timestamp | event_name | user_pseudo_id | ga_session_id | traffic_source | page_location | event_params |
|---|---|---|---|---|---|---|---|
| 20260617 | 2026-06-17 10:00:01 | lp_view | u_8f3a | 1749367201 | google / cpc | /lp/measurement?variant=a | {"lp_id":"lp_measurement_playbook","variant":"a","funnel_step":"landing"} |
| 20260617 | 2026-06-17 10:00:18 | lp_cta_click | u_8f3a | 1749367201 | google / cpc | /lp/measurement?variant=a | {"lp_id":"lp_measurement_playbook","variant":"a","funnel_step":"cta","cta_id":"hero_primary"} |
| 20260617 | 2026-06-17 10:01:02 | lead_form_submit | u_8f3a | 1749367201 | google / cpc | /lp/measurement/form | {"lp_id":"lp_measurement_playbook","variant":"a","funnel_step":"submit"} |
Query cost control
BQクエリ消費量を抑える型
GA4 の生ログは便利ですが、毎回そのまま掘るとクエリ量が膨らみます。 現在の基本形は、生ログを保存元として扱い、上流で正規化・集計してから読むことです。
生ログを毎回直掘りしない
GA4 export は保存先であり、ダッシュボードの参照元にしない
events_YYYYMMDD を毎回ワイルドカードで読むと、期間が伸びるほどスキャン量が増えます。まず正規化イベント、セッション別ファネル、日次集計の中間テーブルを作り、通常の分析はそこを見る形にします。
日付範囲を必ず絞る
_TABLE_SUFFIX や日付パーティションで読む範囲を固定する
GA4 export の日次テーブルを読むときは _TABLE_SUFFIX BETWEEN '20260601' AND '20260630' のように対象日を限定します。パーティションテーブルに変換した後は event_date や event_timestamp のパーティション条件を必須にします。
上流で列に起こす
event_params を毎回 UNNEST せず、必要なキーを列化する
lp_id、variant、funnel_step、cta_id、ga_session_id など、毎回使う値は正規化テーブルで列にします。クエリごとに event_params を掘る状態をやめると、SQLが短くなり、読み間違いも減ります。
集計テーブルを薄く保つ
ダッシュボードは日次・variant別・媒体別の集計を見る
Looker Studio などのダッシュボードから生ログを読ませると、閲覧のたびに重いクエリが走ります。日次集計、ファネル集計、広告費join済みの薄いテーブルを用意し、画面はそこだけを参照します。
パーティションとクラスタを使う
日付でパーティション、よく絞る列でクラスタリングする
正規化テーブルや集計テーブルは日付でパーティションし、lp_id、variant、traffic_source、event_name など頻繁に絞る列でクラスタリングします。まずパーティションで読む日数を減らし、次にクラスタで同じ日付内のスキャンを抑えます。