cro-optimization

CRO最適化

コンバージョン率最適化を、監査 → 仮説立案 → テスト → 判断という体系的な取り組みとして実施します。スタックに依存せず、ツールにも依存しません。

このスキルは、既存のページやフローを対象にテストを実施するためのものです。ランディングページのコピーをゼロから作成する場合は、landing-page-copy を使用してください。CROを可能にする分析環境を整える場合は、analytics-strategy を使用してください。

---

使用する場面

• 期待より低い割合でしかトラフィックをコンバージョンできていない
• ファネルの特定のステップで離脱が多い
• 最適化によって大きな効果が見込める、トラフィックの多いページがある
• A/Bテストの基盤がある（または導入できる）
• 統計的有意性やサンプルサイズに関する疑問がある

使用しない場面

• テストに十分なトラフィックがない場合（バリアントあたりの月間コンバージョン数が約5,000未満）
• リリース前（テスト対象となるユーザーがまだいない）
• 先に定性的な調査が必要な、戦略やメッセージングに関する課題
• ブランドの根幹を決める選択（CROでは根本的に誤ったブランドを最適化できません）

---

必要な入力

• 最適化するページまたはフロー
• 現在のコンバージョン率とトラフィック量
• 分析データへのアクセス（イベントトラッキング、ファネルデータ）
• A/Bテストツール（または導入する意思）
• テストにかける時間と予算（通常、1回のテストにつき2～8週間）

---

フレームワーク：4つのフェーズ

1. 監査

施策を実施する前に、問題を診断します。

定量監査：

• ファネルデータ。 ユーザーはどこで離脱していますか？ 最大の離脱箇所が、最大の改善機会です。
• セグメンテーション。 流入元、デバイス、地域、オーディエンスタイプによって、ファネルの成果に違いはありますか？
• パフォーマンスデータ。 ページの読み込みの遅さがコンバージョンを妨げていませんか？
• Search Console／サイト内検索。 ユーザーは、見つけられない何を探していますか？

定性監査：

• セッションリプレイ。 対象のフローにおけるユーザーのセッションを20件以上確認します。摩擦、混乱、ためらいに注目してください。
• ヒートマップ。 ユーザーはどこをクリックしていますか？ どこまでスクロールしていますか？ どこを見ていませんか？
• ユーザーインタビュー／アンケート。 ユーザーがコンバージョンしなかったのはなぜですか？ 開始後に中断した人を対象にアンケートを実施します。
• フォーム分析。 どのフィールドが離脱につながっていますか？ どのフィールドでエラーが発生していますか？
• カスタマーサポートへの問い合わせ。 コンバージョンに関する質問として、どのような問い合わせが寄せられていますか？

ヒューリスティック監査：

• フローにCROのヒューリスティックを適用します。
  • 5秒以内に価値提案が明確に伝わりますか？
  • 各ページに主要なCTAが1つだけありますか？
  • オファーに対してフォームの長さは適切ですか？
  • 信頼性を示す要素やソーシャルプルーフがありますか？
  • ユーザーの懸念に対応していますか？
  • ページはアクセシブルですか？（アクセシビリティの問題は、気づかれないままコンバージョンを損ないます。）

監査では、摩擦が生じていると思われる箇所のリストを作成します。それぞれが仮説候補になります。

2. 仮説立案

テスト可能な内容を記述します。

仮説の構成：

[監査で得られた所見] を踏まえ、[変更] によって [ユーザーセグメント] の [予測される成果] が得られると考えます。その理由は [根拠] です。

例：

セッションリプレイで、ユーザーが配送ステップで離脱していることがわかったため（監査）、商品ページに配送費を表示すれば（変更）、デスクトップユーザー（セグメント）のカート追加率が5％向上すると考えます（成果）。ユーザーは配送費を予想しておらず、そのため離脱しているからです（根拠）。

質の高い仮説の基準：

• 具体的な変更である（「デザインを改善する」ではない）
• 測定可能な成果である（目標を含む）
• エビデンスに基づいている（監査、調査、過去のテスト）
• 既知のメカニズムと結びついている（なぜ効果があるのか？）

仮説の優先順位付け（ICEまたはPIE）：

• Impact（影響度）： 指標にどれほど大きな効果をもたらす可能性がありますか？
• Confidence（確信度）： 仮説が正しい可能性はどれほど高いですか？
• Ease（容易さ）： テストはどれほど簡単ですか？（時間、複雑さ、リスク）

それぞれを1～10点で評価します。合計点が最も高いものからテストします。

3. テストを設計する

結果が明確に判断できるテストにします。

サンプルサイズと期間：

テストを開始する前に、サンプルサイズ計算ツールを使用します（ほとんどの A/B テストツールには計算機能があります）。入力項目：

• ベースラインのコンバージョン率
• 検出したい最小効果（どの程度の改善を重視するか）
• 統計的検出力（通常 80％）
• 有意水準（通常 95％）

これにより、各バリアントに必要なサンプルサイズが算出されます。サンプルサイズに達するまでテストを実施するか、ビジネスサイクル全体を捉えられる最低期間（通常は週末や週間パターンを含めるため、最低 2 週間）実施します。

よくあるテスト設定のミス：

• 有意差が出た瞬間にテストを終了する（途中経過を何度も確認する）
• ビジネスサイクル全体を捉えるには短すぎる期間でテストを実施する
• 同じフローで複数のテストを同時に実施する
• 通常とは異なる時期（Black Friday、祝日、大規模キャンペーン中）にテストする
• トラフィックの 50％以上がモバイルなのに、モバイルを除外する（またはその逆）
• トラフィックのごく一部でテストする（統計的検出力が低い）
• 分析をセグメント別に行わない（全体での改善が、特定のセグメントへの悪影響を隠すことがある）

テスト開始前に定義するパラメーター：

• 主要指標（1 つ）
• ガードレール指標（低下してはいけない指標）
• サンプルサイズ
• 期間（最短と最長）
• 判断基準（公開するタイミング、中止するタイミング、延長するタイミング）
• 全体に加えて分析するセグメント

4. 判断する

テストの終了後に判断します。

判断の枠組み：

結果	判断
バリアントが明確に勝つ（有意水準が 95％を超え、最小効果を上回る）	バリアントを公開します。結果を記録します。テストを継続します。
バリアントが明確に負ける	中止します。得られた教訓を記録します。仮説を見直します。
結論が出ない（どちらも有意ではない）	より大規模なテストを行う、別の切り口を試す、または次に進みます。「引き分け」のバリアントは公開しません。
改善幅は小さいが、ばらつきが大きい	公開する価値はないでしょう。「勝者」であっても、再現できない可能性があります。
全体では勝つが、重要なセグメントでは負ける	そのセグメントを調査します。セグメントに特化した解決策を検討します。

アンチパターン：

• 有意差に達する前に「勝っているようだから公開しよう」と判断する
• チームが望んでいるという理由でバリアントを公開する（HiPPO：最も報酬の高い人物の意見）
• 結果が悪く見えるため、テストを早期に中止する
• 「勝つ」までテストをやり直す（偽陽性のリスク）
• テストが負けたときに、得られた学びを記録しない

---

統計の基礎

有意性と信頼度

有意水準 95％とは、バリアント間に本当に差がない場合、偶然にこれほど極端な結果が出る確率が 5％しかないことを意味します。

これは「バリアントが勝つ確率が 95％」という意味ではありません。

多くの CRO ツールは、ベイズ確率（「最良である確率が 95％」）を報告します。使用しているツールの分析方法を確認してください。

サンプルサイズ

コンバージョンテストには、多くの人が想定する以上のサンプル数が必要です。目安は次のとおりです。

ベースライン率	検出したい最小効果	バリアントあたりのサンプル数
2%	相対的な改善率 10%	~75,000
2%	相対的な改善率 20%	~19,000
5%	相対的な改善率 10%	~30,000
5%	相対的な改善率 20%	~7,500
10%	相対的な改善率 10%	~14,000
10%	相対的な改善率 20%	~3,500

（概算です。計算ツールを使用してください。）

バリアントごとの月間コンバージョン数がこれらの数値に達しない場合、A/B テストでは信頼できる結果が得られません。その場合は、デザインと定性調査を通じて改善を重ねてください。

多重検定

同時にテストするバリアントや指標が増えるほど、偽陽性が増えます。多重比較に合わせて有意水準を調整してください（Bonferroni 法など）。

---

ワークフロー

1. 監査。 定量・定性・ヒューリスティックの各観点から実施します。
2. 仮説を立てる。 監査で得られた知見を基に、仮説の構造を適用します。
3. 優先順位を付ける。 ICE または PIE を使用します。次にテストする上位 3～5 件を選びます。
4. テストを設計する。 サンプルサイズ、期間、主要指標とガードレール指標、判定基準を定めます。
5. 実装する。 バリアントを構築します。慎重に QA を実施します（壊れたバリアントがあるとテストは無効になります）。
6. 実施する。 途中で結果を確認しないでください。早期に終了しないでください。
7. 分析する。 全体とセグメント別に分析します。有意差の有無にかかわらず、興味深いパターンを記録します。
8. 判断する。 リリースする、打ち切る、または延長します。
9. 記録する。 仮説、設計、結果、判断、教訓を記録します。
10. 積み重ねる。 教訓を次の仮説に活用します。

---

失敗パターン

• 監査なしでテストする。 変更も結果も行き当たりばったりになります。
• 曖昧な仮説。 「改善する」は仮説ではありません。
• 途中で結果を確認して早期終了する。 偽陽性に偏る原因になります。
• 検出力が不足したテスト。 確かな結論を得るためのサンプルが足りません。
• HiPPO による覆し。 最高額の報酬を受け取る人の意見がデータより優先されます。
• 通常と異なる時期にテストする。 休日は結果を歪めます。
• 単一指標への過度な執着。 コンバージョンは増えても平均注文額が急落し、純損失になります。
• ガードレール指標がない。 1 つの成果をテストする一方で、ほかの成果への悪影響を見落とします。
• ドキュメントの不備。 成功は記録されても失敗は忘れられ、同じ仮説を 3 回テストすることになります。
• 各テストを個別に扱う。 テストをまたいで学びを積み重ねることが、CRO プログラムで大きな成果を上げる鍵です。

---

出力形式

デフォルトの出力は、テストごとに cro-test-[hypothesis-slug].md に保存する Markdown 形式のテスト計画です。テスト実施後、結果のセクションを追記します。

Structure:

# Test: [Hypothesis short name]

## Hypothesis
Because [observation], we believe that [change] will produce [outcome] for [segment], because [reason].

## Audit evidence
[What evidence supports this hypothesis]

## Test design
- Primary metric:
- Guardrail metrics:
- Sample size required:
- Duration: minimum X, maximum Y
- Variant traffic split:
- Segments to analyze:

## Decision criteria
- Ship if: [conditions]
- Kill if: [conditions]
- Extend if: [conditions]

## Results (filled after test)
- Sample reached:
- Duration actual:
- Primary metric: [variant vs control + significance]
- Guardrail metrics: [results]
- Segment analysis: [findings]

## Decision
[Ship / Kill / Extend / Iterate] - [Why]

## Lesson
[What this teaches us, regardless of outcome]

---

必要なデータを入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、もしくは検証できない場合、認められる出力は、その不足を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載してください。成果物を完成させるために、必要な数値を捏造、推定、または補間することは決して認められません。不足を明記すれば、それで回答として完結します。

---

参考ファイル

• references/hypothesis-library.md - ファネル段階別の、一般的で影響度の高い仮説パターン。