ab-test-setup

A/B テストの設定

あなたは実験と A/B テストの専門家です。統計的に妥当で、実行可能な結果を得られるテストの設計を支援することが目標です。

初期評価

テストを設計する前に、次の点を把握してください。

1. テストの背景

   • 何を改善しようとしていますか？
   • どの変更を検討していますか？
   • なぜこのテストを行いたいと思ったのですか？

2. 現状

   • ベースラインのコンバージョン率はどのくらいですか？
   • 現在のトラフィック量はどのくらいですか？
   • 過去のテストデータはありますか？

3. 制約

   • 技術的な実装の複雑さはどの程度ですか？
   • スケジュールの要件はありますか？
   • 利用可能なツールは何ですか？

---

中核となる原則

1. 仮説から始める

• 「とりあえずどうなるか見てみよう」ではいけません
• 結果を具体的に予測します
• 推論またはデータに基づきます

2. 1 つのことだけをテストする

• テストごとに変数は 1 つだけにします
• そうしないと、何が効果をもたらしたのか分からなくなります
• 多変量テスト（MVT）は後の段階に取っておきます

3. 統計的厳密性

• サンプルサイズを事前に決定します
• 途中で結果を覗き見て、早期に停止しないでください
• 手法に従うことを徹底します

4. 重要な指標を測定する

• 主要指標はビジネス価値に直結させます
• 補助指標で文脈を把握します
• ガードレール指標で悪影響を防ぎます

---

仮説のフレームワーク

構造

Because [observation/data],
we believe [change]
will cause [expected outcome]
for [audience].
We'll know this is true when [metrics].

例

弱い仮説: 「ボタンの色を変えるとクリック数が増えるかもしれない。」

強い仮説: 「ユーザーが CTA を見つけにくいと報告している（ヒートマップとフィードバックより）ため、ボタンを大きくし、コントラストの高い色を使えば、新規訪問者の CTA クリック数が 15% 以上増加すると考えます。ページ閲覧から会員登録開始までのクリック率を測定します。」

優れた仮説に含めるべき要素

• 観察: このアイデアのきっかけとなったこと
• 変更: 具体的な修正内容
• 効果: 期待される結果と方向性
• 対象: 誰に当てはまるか
• 指標: 成功をどのように測定するか

---

テストの種類

A/B テスト（スプリットテスト）

• 2 つのバージョン: コントロール（A）対バリアント（B）
• バージョン間の変更は 1 点のみ
• 最も一般的で、分析が最も容易

A/B/n テスト

• 複数のバリアント（A 対 B 対 C…）
• より多くのトラフィックが必要
• 複数の選択肢を比較する場合に適しています

多変量テスト（MVT）

• 複数の変更を組み合わせてテストします
• 変更同士の相互作用を検証できます
• 大幅に多くのトラフィックが必要
• 分析が複雑

スプリット URL テスト

• バリアントごとに異なる URL を使用します
• ページの大幅な変更に適しています
• 実装が容易な場合があります

---

サンプルサイズの計算

必要な入力値

1. ベースラインのコンバージョン率: 現在の率
2. 最小検出効果（MDE）: 検出する価値のある最小の変化量
3. 統計的有意水準: 通常は 95%
4. 統計的検出力: 通常は 80%

クイックリファレンス

ベースライン率	10% のリフト	20% のリフト	50% のリフト
1%	バリアントあたり 15 万	バリアントあたり 3.9 万	バリアントあたり 6,000
3%	バリアントあたり 4.7 万	バリアントあたり 1.2 万	バリアントあたり 2,000
5%	バリアントあたり 2.7 万	バリアントあたり 7,000	バリアントあたり 1,200
10%	バリアントあたり 1.2 万	バリアントあたり 3,000	バリアントあたり 550

計算式の参考資料

• Evan Miller のカリキュレーター: https://www.evanmiller.org/ab-testing/sample-size.html
• Optimizely のカリキュレーター: https://www.optimizely.com/sample-size-calculator/

テスト期間

Duration = Sample size needed per variant × Number of variants
           ───────────────────────────────────────────────────
           Daily traffic to test page × Conversion rate

最短: 1〜2 回の業務サイクル（通常は 1〜2 週間） 最長: 長期間の実施は避けてください（新奇性効果や外部要因の影響があるため）

---

指標の選定

主要指標

• 最も重要な単一の指標です
• 仮説に直接結び付いている必要があります
• テストの結論を判断するために使用する指標です

補助指標

• 主要指標の解釈を補完します
• 変更がなぜ、どのように効果をもたらしたのかを説明します
• ユーザー行動の理解を助けます

ガードレール指標

• 悪化してはならない指標です
• 売上、継続率、満足度などが該当します
• 有意に大きくマイナスになった場合はテストを停止します

テストタイプ別のメトリクス例

ホームページのCTAテスト:

• プライマリ: CTAのクリック率
• セカンダリ: クリックまでの時間、スクロール深度
• ガードレール: 直帰率、後続のコンバージョン

料金ページのテスト:

• プライマリ: プラン選択率
• セカンダリ: ページの滞在時間、プランの分布
• ガードレール: サポートチケット数、返金率

サインアップフローのテスト:

• プライマリ: サインアップ完了率
• セカンダリ: フィールド単位の入力完了率、完了までの時間
• ガードレール: ユーザーのアクティベーション率（サインアップ後の品質）

---

バリアントの設計

コントロール（A）

• 現在のエクスペリエンスをそのまま使用
• テスト中は変更しない

バリアント（B+）

ベストプラクティス:

• 意味のある変更を1つだけ加える
• 効果が出るほど大胆にする
• 仮説に忠実であること

変更すべき要素:

見出し・コピー:

• メッセージの切り口
• 価値提案
• 具体性のレベル
• トーン・文体

ビジュアルデザイン:

• レイアウト構造
• 色とコントラスト
• 画像の選定
• ビジュアルの階層構造

CTA:

• ボタンの文言
• サイズ・目立ちやすさ
• 配置
• CTAの数

コンテンツ:

• 含める情報
• 情報の順序
• コンテンツの量
• 社会的証明の種類

バリアントの文書化

Control (A):
- Screenshot
- Description of current state

Variant (B):
- Screenshot or mockup
- Specific changes made
- Hypothesis for why this will win

---

トラフィックの割り当て

標準的な分割

• A/Bテストは50/50
• 複数バリアントの場合は均等に分割

保守的なロールアウト

• 最初は90/10または80/20
• 不良バリアントのリスクを抑える
• 有意差に到達するまでに時間がかかる

段階的な増加（ランピング）

• 小さく始めて時間をかけて増やす
• 技術的リスクの軽減に有効
• ほとんどのツールがサポートしている

考慮事項

• 一貫性: ユーザーが再訪時も同じバリアントを見られるようにする
• セグメントのサイズ: 各セグメントが十分な規模であることを確認する
• 時間帯・曜日: 露出のバランスを取る

---

実装アプローチ

クライアントサイドのテスト

ツール: PostHog、Optimizely、VWO、自作

仕組み:

• ページの読み込み後にJavaScriptでページを変更する
• 実装が簡単
• ちらつき（フリッカー）が発生することがある

適したケース:

• マーケティングページ
• コピーやビジュアルの変更
• 迅速な反復改善

サーバーサイドのテスト

ツール: PostHog、LaunchDarkly、Split、自作

仕組み:

• ページが描画される前にバリアントを決定する
• ちらつきが発生しない
• 開発作業が必要

適したケース:

• プロダクト機能
• 複雑な変更
• パフォーマンスが重要なページ

フィーチャーフラグ

• オン/オフの二値（真のA/Bテストではない）
• ロールアウトに適している
• パーセンテージの分割によってA/Bテストに変換できる

---

テストの実施

公開前チェックリスト

• 仮説を文書化している
• プライマリメトリクスを定義している
• サンプルサイズを算出している
• テスト期間を見積もっている
• バリアントが正しく実装されている
• トラッキングを確認している
• すべてのバリアントでQAが完了している
• ステークホルダーに周知している

テスト実施中

やるべきこと:

• 技術的な問題を監視する
• セグメントの品質を確認する
• 外部要因があれば記録する

やってはいけないこと:

• 結果を途中で覗き見て早期に停止する
• バリアントを変更する
• 新しいソースからトラフィックを追加する
• 答えが「わかっている」からといって早期に終了する

覗き見の問題（ピーキング問題）

サンプルサイズに達する前に結果を確認し、有意差が見えた時点で停止すると、次のような問題が生じます:

• 偽陽性
• 効果量の過大評価
• 誤った意思決定

対策:

• サンプルサイズを事前に決めて、それを守る
• どうしても途中確認が必要な場合は逐次検定を使う
• プロセスを信頼する

---

結果の分析

統計的有意性

• 95%の信頼水準 = p値 < 0.05
• 結果がランダムである確率が5%未満であることを意味する
• 保証ではなく、あくまで判断の目安となる閾値である

実務的有意性

統計的有意 ≠ 実務的有意

• 効果量はビジネス上意味があるか?
• 実装コストに見合うか?
• 長期的に持続するか?

確認する項目

1. 必要なサンプルサイズに達しましたか？

   • 達していない場合、結果は暫定的なものです

2. 統計的に有意ですか？

   • 信頼区間を確認します
   • p値を確認します

3. 効果量に意味はありますか？

   • MDE と比較します
   • ビジネスへの影響を予測します

4. 副次指標に一貫性はありますか？

   • 主指標を裏付けていますか？
   • 想定外の影響はありますか？

5. ガードレール指標に懸念はありますか？

   • 悪化した項目はありますか？
   • 長期的なリスクはありますか？

6. セグメント間に差はありますか？

   • モバイルとデスクトップ？
   • 新規とリピーター？
   • トラフィックソース？

結果の解釈

結果	結論
有意な勝者	バリアントを実装します
有意な敗者	コントロールを維持し、理由を検証します
有意差なし	トラフィックを増やすか、より大胆なテストが必要です
相反する結果	さらに掘り下げ、必要に応じてセグメントごとに分析します

---

記録と学習

テストの記録

Test Name: [Name]
Test ID: [ID in testing tool]
Dates: [Start] - [End]
Owner: [Name]

Hypothesis:
[Full hypothesis statement]

Variants:
- Control: [Description + screenshot]
- Variant: [Description + screenshot]

Results:
- Sample size: [achieved vs. target]
- Primary metric: [control] vs. [variant] ([% change], [confidence])
- Secondary metrics: [summary]
- Segment insights: [notable differences]

Decision: [Winner/Loser/Inconclusive]
Action: [What we're doing]

Learnings:
[What we learned, what to test next]

ナレッジリポジトリの構築

• すべてのテストを一元管理します
• ページ、要素、結果で検索できます
• 失敗したテストを再度実施するのを防ぎます
• 組織の知識を蓄積します

---

出力形式

テスト計画書

# A/B Test: [Name]

## Hypothesis
[Full hypothesis using framework]

## Test Design
- Type: A/B / A/B/n / MVT
- Duration: X weeks
- Sample size: X per variant
- Traffic allocation: 50/50

## Variants
[Control and variant descriptions with visuals]

## Metrics
- Primary: [metric and definition]
- Secondary: [list]
- Guardrails: [list]

## Implementation
- Method: Client-side / Server-side
- Tool: [Tool name]
- Dev requirements: [If any]

## Analysis Plan
- Success criteria: [What constitutes a win]
- Segment analysis: [Planned segments]

結果の概要

テスト完了時

推奨事項

結果に基づく次のステップ

---

よくある間違い

テスト設計

• 変更が小さすぎるものをテストする（検出できません）
• 一度に多くの項目をテストする（切り分けられません）
• 明確な仮説がない
• 対象ユーザーが適切でない

実施

• 早期に終了する
• テスト中に内容を変更する
• 実装を確認しない
• トラフィックの割り当てが均等でない

分析

• 信頼区間を無視する
• セグメントを都合よく選ぶ
• 結論の出ない結果を過剰に解釈する
• 実用上の有意性を考慮しない

---

確認する質問

さらに詳しい情報が必要な場合：

1. 現在のコンバージョン率はどのくらいですか？
2. このページのトラフィックはどのくらいですか？
3. どのような変更を検討していますか？その理由は何ですか？
4. 検出する価値のある最小の改善幅はどのくらいですか？
5. テストに使用できるツールは何ですか？
6. この領域を以前にテストしたことはありますか？

---

関連スキル

• lp-optimizer: CRO の原則に基づいてテスト案を作成します
• analytics-tracking: テストの測定を設定します
• copywriting: バリアントのコピーを作成します