LPのコンバージョンを計測する前に考えるべきこと

KGIから始める#

KGIとは「このLPが存在する事業上の理由」を数字にしたものだ。「月間契約数を増やす」「MRRを上げる」「有料転換率を改善する」。具体的な数字でなくてもいい。方向だけでいい。

ここで最も重要なのは、KGIはLPの中で完結しないことが多いという事実を受け入れることだ。

あるプロジェクトのKGIは「月間の有料契約数を増やす」だった。しかし契約はLP上では完了しない。ユーザーはLPから外部の申込サイトに遷移し、そこで契約する。申込サイトのデータは別のチームが管理する別のGA4プロパティにある。

つまり自分たちのKGIを自分たちで計測できない。

ここで人は2つの間違いのどちらかを犯す。

1つ目は、計測できないKGIを無視して、計測できるものだけでKPIを作ること。「トライアル登録数」や「チャット開始数」をKPIにするのは合理的に見えるが、チャットが100回開始されても契約が0件なら事業は動いていない。KGIとの接続が切れたKPIは、最適化すればするほど間違った方向に進む。

2つ目は、計測できないKGIをそのままNorth Star Metricに置くこと。最初のバージョンでは「月間契約完了数」をNSMにした。結果、毎週の進捗会議で「契約データはまだ外部から来ていないのでNSMの進捗は不明です」と言い続けることになる。NSMの存在意義——全チームが1つの数字に整列すること——が崩壊する。

正解は「暫定NSM」を置くことだ。

KGI:    月間契約数の増加（最終ゴール）
最終NSM: 月間契約完了数（外部データ。計測系が整い次第）
暫定NSM: アウトバウンド遷移率（自サイト内で計測可能）
昇格条件: 暫定NSMと契約完了数の相関 r > 0.7

暫定NSMとは、KGIの代理指標であり、かつ自分たちの手元で計測できるもの。KGIとの相関が確認できた時点で「最終NSM」に昇格させる。

これは妥協ではない。MetaがMAUをNorth Starにしたのは、MAUが収益と強い相関を持っていたからだ。収益を直接追わず、MAUを追い、MAUが収益を牽引するという因果関係を信頼した。この構造を小さなLPにも適用するだけだ。

暫定NSMを選ぶ基準は3つだけ。自分で計測できる。KGIとの因果を説明できる。チームの仕事で動かせる。

仮説を先に書く#

KGIと暫定NSMが決まったら、次はファネルを設計する……のではない。仮説を書く。

「なぜ今のLPは目標を達成できていないのか？」「何を変えれば数字が動くのか？」

これをデータを見る前に書く。データを先に見ると、データが仮説を作ってしまう。人間は「見たもの」から仮説を逆算するのが得意すぎる。それは仮説ではなく、事後的な説明だ。

因果チェーンで書く。

[介入] → [行動変化] → [KPI変化] → [KGI変化]

あるプロジェクトの因果チェーンはこうだった。

AIチャットウィジェットを設置する → ユーザーが自分に関連する情報を見つけやすくなる → サービスページへの到達率が上がる → 外部の申込サイトへの遷移率が上がる → 契約数が増える

この因果チェーンの各矢印が「検証すべき仮説」であり、各段階の数字が「KPI」になる。因果チェーンが先、KPIが後。この順番を逆にしてはいけない。KPIから先に作ると、測りやすいものを測ることになる。測りやすいものと、事業を動かすものは、ほとんどの場合一致しない。

直帰率をKPIにしてはいけないとき#

GA4を開いてデータを見た。

広告LPの直帰率64.3%、トップページ76.6%。この数字を見て、最初のバージョンでは「直帰率改善」をPrimary KPIに置いた。改善幅が大きく、計測も容易で、ストーリーとして説得力がある。

これが最初の、そして最も危険な間違いだった。

このプロジェクトでは、B群（テスト群）にAIチャットウィジェットを追加する。バブルが表示され、ユーザーがクリックし、会話が始まる。この一連のインタラクションはGA4のキーイベントとして記録される。

ここが罠だ。GA4における「直帰」とは「engaged sessionでないセッション」であり、キーイベントが1回でも発火するとengaged sessionになる。B群にウィジェットを追加した時点で、バブル表示やクリックのイベントが発火する。ユーザーの行動が一切変わらなくても、計測の仕組みだけで直帰率は「改善」する。

直帰率をPrimary KPIにした瞬間、テストの結果を事前に決めているに等しい。B群にどんなウィジェットを載せても「成功」になる。それはA/Bテストではなく出来レースだ。

5回の改訂で直帰率はPrimary → Secondary → Diagnosticへと降格させた。最終版では「判定には使わないが、B群の直帰率がA群より5ポイント以上悪化したらテスト即時中止」という中止基準に使っている。

直帰率は体温計であって、治療目標ではない。38度を超えたら異常を疑うが、「体温を36度にすること」を治療目標にはしない。

数字から逆算する: 直帰率76.6%の裏側#

トップページの直帰率76.6%と滞在3.9秒。この数字だけ見ると「ひどいページだ」と思う。

しかし同じサイトの記事ページは直帰率16〜24%で、滞在70〜141秒だった。記事に辿り着いたユーザーは平均90秒以上読んでいる。「コンテンツの質」は高い。問題は「コンテンツへの導線」にある。

もし直帰率をKPIにしていたら、トップページのデザイン変更やコンテンツ追加に工数を投下していただろう。しかし本当のボトルネックは「良いコンテンツへの道案内」であり、チャットはまさにその道案内の手段として設計した。

直帰率76.6%は「問題」ではなく「症状」だ。問題はナビゲーション設計にある。直帰率をKPIにすると症状の改善を目標にしてしまい、根本原因の解決ではなく数字のハックに走る誘惑が生まれる。

判定指標はユーザーの意思表示で選ぶ#

直帰率を外した後、代わりに何を置くか。

「チャット開始率」は候補に見えるが、B群でしか計測できない。A群にはチャットがないのだから開始率は定義上0%だ。「A群0% vs B群15%」を比較しても「チャットを入れたらチャットが使われた」という自明な事実を確認しているだけで、事業にとって何の情報もない。

「セッション滞在時間」も同じ問題。チャットの会話時間が加算されるため、ユーザーの情報取得行動が変わらなくても延びる。

最終的に選んだのは「アウトバウンド遷移率」だった。

この指標の美点は、A群とB群で同じ基準で測れること。申込サイトへのリンクは両群に存在する。そしてKGI（契約数増加）と因果的に接続している。遷移した人の一定割合が契約する。遷移率が上がれば契約も増える。

判定指標は1つにする。 最初のバージョンではPrimary KPIを4つ定義していた。4つもある時点で「Primary」の意味をなしていない。指標が複数あると、テスト後に都合の良い1つだけで「成功」と言える。それは統計の悪用だ。最終版ではPrimaryを1つだけにし、残りはSecondaryとDiagnosticに分離した。

1イベント=1行動#

最初のバージョンでは user_engage という1つのイベントで「バブルクリック」「iframeフォーカス」「選択肢クリック」を全て計測していた。

「チャット開始率 = user_engage / バブル表示」と定義したとき、分子にはバブルを触っただけのユーザーも、会話を深めたユーザーも入る。指標が上がったとき、「チャットを始める人が増えた」のか「既存ユーザーが多くクリックしている」のか区別できない。

最終版では1イベントを5つに分割した。

各イベントがファネルの1段階だけに対応する。バブルは12%がクリックするのに会話成立が50%しかないなら、クリック後のUIに問題がある。会話は成立するが選択肢操作が20%しかないなら、チャットの応答品質に問題がある。どこで詰まっているかが一目でわかる。

分母と分子を厳密に定義する#

「コンバージョン率」とだけ書いてあるKPIは、定義されていないのと同じだ。

コンバージョン率 = [何を] / [何で割るか] / [どの単位で] / [どの期間で]

「イベント数 / セッション数」と「イベントが1回以上あったセッション数 / セッション数」は異なる。前者は1セッションで3回クリックすれば3/1=300%になる。後者は1/1=100%。

もう1つ。A/Bテストの振り分けがユーザー単位（Cookie）なのに、解析がセッション単位だと問題がある。同一ユーザーの複数セッションは独立ではない——同じ人間が同じ興味で来ている。サンプルサイズの計算が崩れる。

このプロジェクトではユーザーあたり平均PVが 1.13 だったので、大半が1回きりの訪問だった。クラスタリング効果は小さかったはずだ。しかし「小さいから無視する」のと「構造的に排除する」のは全く違う。

最終版では「ユーザーあたり最初のeligible sessionのみを主解析、全sessionsを補助解析」と定義した。これでランダム化単位と解析単位が揃い、サンプルサイズ計算の前提が正確になる。

10万人は「十分」か#

90日間で103,817人。日次約1,200人の新規流入。LP内のコンバージョン最適化を正当化する母数として十分だろうか。

Alex Schultzのマーケティングファネルに「Pool Size Analysis」がある。ファネルの各層の母数を測定し、最大ドロップオフを見つけ、そこに投資する。ただし最重要の判断は「ファネルの入口が十分に大きいか」だ。

このサービスの潜在市場は数百万〜数千万人規模だ。10万人はその数%にも満たない。Awareness問題が圧倒的に大きい。CVRを2%から3%に改善しても月間の追加コンバージョンは数十件だが、流入を10倍にすればCVR据え置きでも効果は10倍になる。

それでもLP最適化を選んだ。理由はドキュメントに明記した。

LP改修にはサイトオーナー側の制作承認が必要で時間がかかる。チャットはGTM経由で追加でき、承認プロセスが軽い。チャットは全ページ横断で機能し、単一LP改修より影響範囲が広い。成功すれば他サービスへの横展開パッケージになる。

「なぜこの施策か」は「なぜこのKPIか」よりも先に答えるべき問いだ。書かなければ「広告費を増やしたほうがいいのでは？」と問われたとき答えられない。

テストの前に「やめる基準」を決める#

最初の2バージョンにはテスト中止基準がなかった。「p < 0.05で成功」としか書いていなかった。

最終版で定義した基準:

ここで直帰率が再登場する。判定指標としては使わないが、体験の急激な悪化のアラートとしては有用だ。5ポイント以上悪化していれば何かが壊滅的に壊れている。原因を調べる前に止めるべきだ。

テスト後の意思決定を事前に書く#

「成功したら全ユーザーに展開」では不十分だ。4つのパターンを事前に定義する。

有意 + 効果大（絶対差 >= 0.5pt）
→ ロールアウト。次のテスト（シナリオ最適化）へ
 
有意 + 効果小（絶対差 < 0.5pt）
→ 施策改善して再テスト
 
有意差なし
→ 施策見送り。LP自体のCTA最適化に方針転換
 
B群が悪化
→ 即時停止。UXの根本見直し

これがないと、遷移率が2.0%から2.1%に上がりp=0.048だったとき「有意だから成功」と言い張る誘惑に負ける。月間の追加遷移は数件、追加契約はさらに少ない。チャットウィジェットの月額費用を下回る可能性が高い。

Alex Schultzの言葉を借りれば、データサイエンティストと顕微鏡が必要な改善は、事業を動かしていない。

ドキュメントは読者で構造を決める#

KPI定義書の最も多い間違いは「自分が分析した順番」で書くことだ。GA4を開いて→データを引いて→仮説を立てて→KPIを定義して→イベントを設計して→テスト仕様を書く。これは分析者の思考プロセスであって、読者が知りたい順番ではない。

最初のバージョンは「目的とスコープ」から始まり、GA4プロパティIDとGTMコンテナのバージョン番号が冒頭にあった。サイトオーナー側の部長が受け取ったとき、最初に目に入るのが GTM-XXXXXXX v10.2.0。その時点でドキュメントは閉じられる。

KPI定義書の読者は2種類しかいない。意思決定者と実装者。この2人が知りたいことは根本的に異なる。

意思決定者が知りたいのは: 何をやるのか。なぜやるのか。成功したらいくら儲かるのか。自分は何をすればいいのか。GA4のイベント名もpostMessageの仕様も読まない。

実装者が知りたいのは: 何を計測するのか。どのイベントをどのトリガーで発火させるのか。分母と分子の定義は何か。因果チェーンの仮説もビジネスインパクトの試算も毎回読む必要がない。

前半: 意思決定パート
  1. エグゼクティブサマリー（1ページ）
  2. なぜやるのか（仮説ロジック）
  3. 何で判断するのか（テスト設計・判定基準）
  4. 何を依頼するのか
 
--- 意思決定者はここで読み終わる ---
 
後半: 実装パート
  5. KPI定義詳細
  6. ファネルと目標値
  7. イベント設計
  8. 実装タスクと優先度

エグゼクティブサマリーが最重要なのは、意思決定者はここしか読まないからだ。「月間○○万円のインパクトが見込める」と書いてあるか、ないかで、ドキュメント全体の運命が決まる。

5バージョンを通じて、ビジネスインパクトの試算が一度も書かれなかった。これが最大の構造的欠陥だった。

ビジネスインパクトを円で語る#

計測設計がどんなに美しくても「だからいくら」が書いていなければ承認は下りない。

以下のインタラクティブ試算で、仮定値を動かしながらインパクトの感度を確認できる。

まとめ#

5回の改訂で学んだことを一般化する。

1. KGIから始める。 このLPは何のために存在するのか。KGIが計測できないなら暫定NSMを置き、昇格条件を定義する。

2. 仮説を先に書く。 因果チェーンで。データを見る前に。

3. 機械的に改善する指標を判定に使わない。 直帰率は体温計であって治療目標ではない。判定指標はユーザーの意思表示に最も近いものを選ぶ。

4. 1イベント=1行動。 複数の行動を混ぜると分析が曖昧になる。

5. 分母と分子を厳密に定義する。 ランダム化単位と解析単位を合わせる。

6. 施策の選択理由を書く。 「なぜこのKPIか」の前に「なぜこの施策か」。

7. テスト前に中止基準と意思決定マトリクスを書く。 テスト後では遅い。

8. ドキュメントは読者で構造化する。 意思決定者が前半、実装者が後半。エグゼクティブサマリーがないドキュメントは読まれない。

9. ビジネスインパクトを円で書く。 これがないと承認は下りない。

この手順の中で、GA4のイベント設計は後半にしか出てこない。最初に出てくるべきではない。計測は手段であって目的ではない。目的は事業を動かすことだ。