CROの進め方｜何から検証するべきか（チェックリストと判断軸）

CROは、ボタンを変えて申込率を上げる作業だけではありません。どの読者に、どの条件で、何をしてもらえたら役立ったと言えるかを決め、確かめながら改善する取り組みです。

率だけを追うと、質の低い申込が増えたり、必要な説明を削って誤解を招いたりすることがあります。前提、計測、仮説、比較、判断の順に整理して、次に検証する一つの変更を選びます。

30秒で要点

• 成果の定義と分母を先に決める。同じ「CVR」でも、ユーザー、セッション、クリックでは値の意味が違う。
• ファネルの低い率は調査の入口。原因、対象件数、回復余地、利用者の不利益、実装負担を見て優先する。
• A/Bテストは割付・計測・終了条件を決めて始める。効果量、不確かさ、副作用を一緒に見て、都合のよい時点だけを採らない。

成果と「数える単位」を一文にする

コンバージョンは、申込、購入、資料の閲覧など、サイトで定義した目標行動です。CROはその達成を改善する活動ですが、どんな行動でも件数が増えればよいわけではありません。

例えば「対象サービスの条件を満たす新規の問い合わせ」を成果にすると、重複、営業メール、対象外の問い合わせをどう扱うかまで決める必要があります。判定できるまで時間がかかるなら、その観測期間も揃えます。

表が収まらない場合は、横にスクロールできます

この表は設計例です。すべてのサイトに同じ対象や観測窓を勧めるものではありません。ユーザー識別にも端末、同意、ログインなどの制約があり、観測できたユーザーが全利用者を完全に代表するとは限りません。

5分の整理で、測る前の不足を見つける

次の問いは検討の入口で、心理検査や統計的に検証された診断ではありません。

1. 何を良くしたいか一文で言えるか。 言えなければ、率の分子・分母、利用者にとっての意味、許容しない不利益を先に書きます。
2. 計測が同じ意味で動いているか。 ボタン表示、クリック、入力開始、完了を混ぜていないか、再送や戻る操作をどう数えるかを確認します。
3. 困っている理由を説明できるか。 離脱の多い画面が見つかっても、理由はまだ仮説です。料金の不明瞭さ、入力エラー、対象外の流入などを分けます。
4. 比較を終えた後の判断を決めているか。 展開、修正、保留、撤回の条件がなければ、好きな結果だけを成功と呼びやすくなります。

まだアクセスが少ない場合も、計測の点検、問い合わせの分類、操作時の理解やエラーの確認はできます。ただし、少人数の観察を母集団での改善率へ換算しません。

ファネルは、同じ対象がどこまで進んだかを読む

典型的な経路を文字で表すと、次のようになります。

流入 → LP閲覧 → CTAクリック → フォーム開始 → 送信完了

これは工程を説明する教材であり、実行プログラムではありません。実際には、途中の工程を飛ばす、後日戻る、別の経路から入る場合があります。Google Analyticsのファネル資料でも、途中参加を認めるか、順序や時間をどう定義するかによって対象が変わります。

次の表は、同じ対象者が順に進み、途中参加せず、各人を各段階で一度だけ数える架空例です。流入数とLP閲覧数は分けず、対象LP閲覧の1000人を起点にします。実際のGA4測定値ではありません。

表が収まらない場合は、横にスクロールできます

この条件なら、20% × 50% × 80% = 8%です。起点から完了に至らなかった人は920人ですが、800人はCTA前、100人はクリック後から入力開始まで、20人は入力開始後です。全員が同じ理由で困っていたとは言えません。

途中参加あり、別経路あり、各段階の分母が別集団という集計では、この掛け算をそのまま当てはめられません。数字を見る前に、経路と対象の定義を確認してください。

一番低い率が、必ずしも最優先ではない

上の例では20%が最も低い率ですが、残り80%の全員が申込を希望していたわけではありません。情報を読んで対象外だと分かった人もいます。逆に、人数が少ない工程でも重大な入力障害なら、先に直す価値があります。

次の順で候補を比較します。点数の合計を科学的な効果予測とみなさず、根拠を話し合うための材料にします。

表が収まらない場合は、横にスクロールできます

「項目が多いから一つ減らす」という仮説なら、その項目の用途と未記入時の後工程を確認します。送信率が上がっても、不足情報の聞き直しが増えれば、利用者と担当者の負担が移っただけかもしれません。

心理学の名前を施策の根拠にしすぎない

損失回避や社会的証明の名前を付けても、現在の読者に効くとは限りません。まず「比較条件が見つからない」「価格が最後まで分からない」「入力エラーの直し方が分からない」など、観察できる困り事を言葉にします。

一度に一つの変更仮説を検証するのは、解釈を簡単にする編集・実務上の目安です。一画面に一つの心理原理を置けば成功する、という法則ではありません。架空の残数、根拠のない人気表示、拒否しにくい導線で率を上げることは、理解しやすい選択を支える改善と区別します。

行動経済学とWeb改善も、用語を当てはめるためではなく、仮説と不利益を点検する入口として読みます。

A/Bテストは、開始前の設計で比較の意味を守る

A/Bテストは二つの版を置くだけではありません。比較したい対象を適切な単位で無作為に割り付け、同じ条件で結果を測る設計が必要です。同じ人が両版を見る、チーム内で情報が伝わる、片方だけ計測が欠ける、といった事情も結果に関わります。

Microsoftの事前設計ガイドを参考に、少なくとも次を一枚に書きます。

• 仮説と対象: 誰の、どんな困り事を、何の変更で減らすのか。
• 割付: ユーザーや組織など、比較に合う単位は何か。同じ対象への割付をどう維持するか。
• 成果指標: 分子、分母、重複、観測窓、適格性をどう定義するか。
• 安全と品質: エラー、取消、誤送信、対応負担などをどの条件で止めるか。
• 必要な観測: 意味のある最小効果、必要数、期間、統計手法、除外条件をどう定めるか。
• 判断: 終了時に何を根拠に展開・修正・保留・撤回するか。

全サイトに共通の「何日・何人なら十分」はありません。基準となる率、検出したい差、ばらつき、割付と観測の単位によって必要な設計が変わります。

途中の監視と、途中の成功宣言を分ける

利用者の不利益や計測異常は、実験中も監視します。事前の停止基準に当たる重大な問題があれば止めます。「終了まで何も見てはいけない」という意味ではありません。

一方、毎日p値を見て、初めて小さくなった日に成功として終えると、予定した検定の性質を保てないことがあります。実験中の運用ガイドも、データ品質の監視と終了判断を区別しています。途中で有効性を判断するなら、その判断を扱える統計設計を先に選びます。

p値は、帰無仮説を含む検定の前提のもとで、観測された統計量と同じか、それ以上に極端な値が出る確率です。施策が正しい確率、偶然が原因である確率、改善幅そのものではありません。NISTの検定の説明と合わせ、何の仮説をどの前提で調べているかを確認します。

結果は効果の大きさと副作用を並べて判断する

申込率が上がったように見えても、不確かさが大きい、適格申込は増えていない、対応費用が増えた、という場合があります。率の差はパーセントポイント、元の率を分母にした変化は相対変化として区別します。

表が収まらない場合は、横にスクロールできます

前後比較しかできない場合は、季節や流入構成、他施策の影響が残ります。「変更後に増えた」という観測を「変更が増やした」という因果の結論へ自動的に進めません。

最小の検証は、一本の経路を同じ定義で追うこと

最初の一歩では、重要な経路を一つ選び、開始・途中・完了がどんな条件で記録されるかを整理します。その上で、困り事を支える情報を一つ集め、仮説、成果、副作用、終了条件を書きます。計測定義を揃えるだけで仮説を修正する必要が見つかる場合もあります。

算術を確認した表があることと、実験が成立したことは別です。統計の判断ガイド、A/Bテストの必要サンプル、判断の偏りの整理を使い、率を上げる前に比較の意味を揃えてください。