ab-testing
熱門當使用者想要規劃、設計或執行 A/B 測試或實驗，或建立成長實驗計畫時使用。也適用於使用者提及「A/B 測試」、「分割測試」、「實驗」、「測試這個變更」、「變體文案」、「多變量測試」、「假設」、「我該測試這個嗎」、「哪個版本比較好」、「測試兩個版本」、「統計顯著性」、「這個測試該跑多久」、「成長實驗」、「實驗速度」、「實驗待辦清單」、「ICE 分數」、「實驗計畫」或「實驗手冊」。只要有人在比較兩種做法並想衡量哪個表現較好，或想建立系統化的實驗流程，就使用此技能。若要追蹤實作，請參閱 analytics。若要進行頁面層級的轉換優化，請參閱 cro。
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics. For page-level conversion optimization, see cro.
A/B 測試設定
您是實驗與 A/B 測試的專家。目標是協助設計能產出統計上有效、可執行的結果的測試。
初步評估
先檢查產品行銷脈絡：
如果 .agents/product-marketing.md 存在（或 .claude/product-marketing.md，或舊版中的 product-marketing-context.md 檔案），請先閱讀再提問。利用該脈絡，僅針對未涵蓋或特定於此任務的資訊提問。
在設計測試前，請了解：
- 測試脈絡 - 您想改善什麼？您考慮什麼變更？
- 現狀 - 基準轉換率？目前流量？
- 限制條件 - 技術複雜度？時程？可用工具？
核心原則
1. 從假設開始
- 不只是「看看會怎樣」
- 具體的結果預測
- 基於推理或數據
2. 一次只測一件事
- 每次測試單一變數
- 否則無法知道什麼有效
3. 統計嚴謹性
- 預先決定樣本數
- 不要偷看結果並提前停止
- 遵守方法論
4. 衡量重要的事
- 主要指標與商業價值直接相關
- 次要指標提供脈絡
- 護欄指標防止傷害
假設框架
結構
因為 [觀察/數據]，
我們相信 [變更]
會導致 [預期結果]
對 [目標受眾]。
當 [指標] 發生時，我們就知道這是真的。
範例
弱：「改變按鈕顏色可能會增加點擊。」
強：「因為使用者回報難以找到 CTA（根據熱圖和回饋），我們相信將按鈕放大並使用對比色，能讓新訪客的 CTA 點擊率提升 15% 以上。我們將衡量從頁面瀏覽到開始註冊的點擊率。」
測試類型
| 類型 | 描述 | 所需流量 |
|---|---|---|
| A/B | 兩個版本，單一變更 | 中等 |
| A/B/n | 多個變體 | 較高 |
| MVT | 多種變更組合 | 非常高 |
| 分割 URL | 不同 URL 對應不同變體 | 中等 |
樣本數
快速參考
| 基準轉換率 | 提升 10% | 提升 20% | 提升 50% |
|---|---|---|---|
| 1% | 150k/變體 | 39k/變體 | 6k/變體 |
| 3% | 47k/變體 | 12k/變體 | 2k/變體 |
| 5% | 27k/變體 | 7k/變體 | 1.2k/變體 |
| 10% | 12k/變體 | 3k/變體 | 550/變體 |
計算工具：
詳細樣本數表格與持續時間計算：請參閱 references/sample-size-guide.md
指標選擇
主要指標
- 最重要的單一指標
- 直接與假設相關
- 用來判定測試結果
次要指標
- 支援主要指標的解讀
- 解釋變更為何/如何有效
護欄指標
- 不該變差的事項
- 若顯著負面則停止測試
範例：定價頁面測試
- 主要：方案選擇率
- 次要：頁面停留時間、方案分布
- 護欄：客服單量、退款率
設計變體
可變更的項目
| 類別 | 範例 |
|---|---|
| 標題/文案 | 訊息角度、價值主張、具體程度、語氣 |
| 視覺設計 | 版面、顏色、圖片、層級 |
| CTA | 按鈕文案、大小、位置、數量 |
| 內容 | 包含的資訊、順序、數量、社會證明 |
最佳做法
- 單一、有意義的變更
- 大膽到足以產生差異
- 忠於假設
流量分配
| 方式 | 分配 | 使用時機 |
|---|---|---|
| 標準 | 50/50 | A/B 測試預設 |
| 保守 | 90/10, 80/20 | 限制不良變體的風險 |
| 漸進 | 從小開始，逐漸增加 | 技術風險緩解 |
考量事項：
- 一致性：使用者回訪時看到相同變體
- 平衡一天/一週中各時段的曝光
實作
客戶端
- JavaScript 在頁面載入後修改
- 實作快速，可能造成閃爍
- 工具：PostHog, Optimizely, VWO
伺服器端
- 在渲染前決定變體
- 無閃爍，需要開發工作
- 工具：PostHog, LaunchDarkly, Split
執行測試
啟動前檢查清單
- [ ] 假設已記錄
- [ ] 主要指標已定義
- [ ] 樣本數已計算
- [ ] 變體已正確實作
- [ ] 追蹤已驗證
- [ ] 所有變體的 QA 已完成
測試期間
應做：
- 監控技術問題
- 檢查區段品質
- 記錄外部因素
避免：
- 偷看結果並提前停止
- 對變體進行修改
- 從新來源增加流量
偷看問題
在達到樣本數前查看結果並提前停止，會導致假陽性和錯誤決策。預先承諾樣本數並信任流程。
分析結果
統計顯著性
- 95% 信心水準 = p 值 < 0.05
- 表示結果隨機的機率 <5%
- 並非保證，只是一個門檻
分析檢查清單
- 達到樣本數？ 若否，結果僅為初步
- 統計顯著？ 檢查信賴區間
- 效應量有意義？ 與 MDE、專案影響比較
- 次要指標一致？ 支援主要指標？
- 護欄問題？ 是否有任何項目變差？
- 區段差異？ 行動 vs. 桌面？新訪客 vs. 回訪？
解讀結果
| 結果 | 結論 |
|---|---|
| 顯著勝出 | 實作變體 |
| 顯著落敗 | 保留對照組，了解原因 |
| 無顯著差異 | 需要更多流量或更大膽的測試 |
| 混合訊號 | 深入挖掘，或許分區段 |
文件記錄
每個測試都應記錄：
- 假設
- 變體（附截圖）
- 結果（樣本數、指標、顯著性）
- 決策與學習
範本：請參閱 references/test-templates.md
成長實驗計畫
個別測試有價值。持續的實驗計畫是複利資產。本節說明如何將實驗作為持續的成長引擎，而非一次性測試。
實驗循環
1. 產生假設（來自數據、研究、競爭者、客戶回饋）
2. 使用 ICE 評分進行優先排序
3. 設計並執行測試
4. 以統計嚴謹性分析結果
5. 將勝出的做法納入手冊
6. 從學習中產生新假設
→ 重複
假設產生
從多個來源餵養實驗待辦清單：
| 來源 | 尋找什麼 |
|---|---|
| 分析工具 | 流失點、低轉換頁面、表現不佳的區段 |
| 客戶研究 | 痛點、困惑、未滿足的期望 |
| 競爭者分析 | 他們使用但你沒有的功能、訊息或 UX 模式 |
| 客服單 | 關於轉換流程的重複問題或抱怨 |
| 熱圖/錄影 | 使用者猶豫、憤怒點擊或放棄的地方 |
| 過去實驗 | 「顯著落敗」的測試常揭示可嘗試的新方向 |
ICE 優先排序
每個假設在三個維度上評分 1-10：
| 維度 | 問題 |
|---|---|
| 影響力 | 如果有效，對主要指標的影響有多大？ |
| 信心度 | 我們有多確定這會有效？（基於數據，而非直覺。） |
| 容易度 | 我們能多快、多便宜地推出並衡量？ |
ICE 分數 = (影響力 + 信心度 + 容易度) / 3
優先執行分數最高的實驗。每月根據脈絡變化重新評分。
實驗速度
將實驗速率視為成長的領先指標：
| 指標 | 目標 |
|---|---|
| 每月啟動的實驗數 | 多數團隊 4-8 個 |
| 勝率 | 成熟計畫通常 20-30%（持續更高可能表示假設過於保守） |
| 平均測試持續時間 | 2-4 週 |
| 待辦清單深度 | 20+ 個待辦假設 |
| 累積提升 | 所有勝出做法的複合增益 |
實驗手冊
當測試勝出時，不僅要實作，還要記錄模式：
## [實驗名稱]
**日期**：[日期]
**假設**：[假設]
**樣本數**：[每變體 n]
**結果**：[勝出/落敗/無結論] — [主要指標] 變化了 [X%]（95% CI：[範圍], p=[值]）
**護欄**：[任何護欄指標及其結果]
**區段差異**：[按裝置、區段或群體的顯著差異]
**成功/失敗原因**：[分析]
**模式**：[可重複使用的洞察 — 例如「定價 CTA 附近的社會證明增加方案選擇」]
**適用於**：[此模式可能適用的其他頁面/流程]
**狀態**：[已實作 / 暫緩 / 需後續測試]
隨著時間推移，您的手冊將成為專屬於您的產品和受眾的經過驗證的成長模式庫。
實驗節奏
每週（30 分鐘）：檢視進行中的實驗，檢查技術問題和護欄指標。不要提前判定勝出者 — 但如果護欄指標顯著負面，則停止測試。
雙週：結束完成的實驗。分析結果，更新手冊，從待辦清單啟動下一個實驗。
每月（1 小時）：檢視實驗速度、勝率、累積提升。補充假設待辦清單。使用 ICE 重新排序。
每季：稽核手冊。哪些模式已廣泛應用？哪些勝出模式尚未規模化？漏斗的哪些區域測試不足？
常見錯誤
測試設計
- 測試的變更太小（無法偵測）
- 測試太多東西（無法隔離）
- 沒有明確假設
執行
- 提前停止
- 中途修改
- 未檢查實作
分析
- 忽略信賴區間
- 選擇性挑選區段
- 過度解讀無結論的結果
任務特定問題
- 您目前的轉換率是多少？
- 這個頁面的流量有多少？
- 您考慮什麼變更？為什麼？
- 值得偵測的最小改善是多少？
- 您有哪些測試工具？
- 您之前測試過這個區域嗎？
相關技能
- cro：用於根據 CRO 原則產生測試想法
- analytics：用於設定測試衡量
- copywriting：用於建立變體文案
