> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# A/B 測試

> A/B 測試是一種比較網頁或應用程式兩個版本以確定哪個表現更好的方法。學習如何執行統計有效的 A/B 測試。

<Info>
  **類別**: 方法<br />
  **類型**: 實驗框架<br />
  **起源**: 隨機對照試驗，18 世紀醫學 / 網路優化，1990 年代至 2000 年代<br />
  **別名**: 分流測試、分桶測試、對照實驗
</Info>

<Note>
  **快速回答** — A/B
  測試是一種比較產品兩個版本的方法——通常是網頁、應用程式畫面或功能——以確定哪個在特定目標上表現更好。透過隨機向不同使用者展示每個版本並測量結果，團隊可以做出關於哪些變更實際改善了使用者體驗和業務指標的資料驅動決策。關鍵洞見是直覺是不可靠的；只有受控實驗才能可靠地區分產品決策中的因果關係。
</Note>

## 什麼是 A/B 測試？

A/B 測試是一種受控實驗，其中比較產品元素的兩個版本，以確定哪個版本在特定指標上取得更好的結果。一個版本（A，對照組）與修改版本（B，實驗組）進行比較，使用者被隨機分配到每組。透過測量組間結果的差異，團隊可以將行為的變化歸因於所做的特定修改。

此實踐源自幾個世紀前的醫學研究，但其網路和產品開發中的應用始於 1990 年代末和 2000 年代初，當時亞馬遜、Google 和 Netflix 等公司開始嘗試資料驅動的產品決策。如今，A/B 測試是數位產品開發的基本實踐，幾乎每家大型科技公司都使用它來優化從按鈕顏色到整個使用者體驗的一切。

> 「受控實驗是任何想要做出資料驅動決策的人工具箱中最強大的工具。」— 羅恩·科哈維，前 Netflix 高管和 A/B 測試先驅

A/B 測試的力量在於其隔離特定變更效果的能力。沒有受控實驗，就不可能知道觀察到的改善是由於變更、外部因素還是隨機機會。正確設計的 A/B 測試提供了統計置信度，證明觀察到的差異是真實的。

### A/B 測試的三層理解

* **入門**: 從定義你想要改進的單一主要指標開始（如點擊率或轉化率）。建立一個簡單的變更來測試，確保你的樣本量足夠大，並在分析結果之前執行固定持續時間的測試。

* **從業者**: 使用多變數測試同時測試多個變數。實施適當的統計顯著性閾值（通常為 95%）。細分結果以了解不同使用者群體的效果，同時避免過度詮釋小樣本區段。

* **進階**: 應用順序測試方法，允許在結果明確時提前停止。使用保留組測試長期效果與新穎效果。實施貝葉斯分析以更快進行不確定性量化的決策。

## 起源

A/B 測試的起源可追溯到隨機對照試驗（RCT）的概念，該概念在 20 世紀初統計學家如羅納德·費雪的工作後成為醫學研究的標準。基本原則——隨機分配受試者到實驗組和對照組以隔離干預的效果——直接轉化為產品測試。

受控實驗適應網路優化始於 1990 年代末。2000 年，Google 執行了最早的 A/B 測試之一，測試每頁顯示的搜尋結果數量。亞馬遜、Netflix 和其他網路公司迅速採用此做法，認識到當應用於數百萬使用者時，使用者介面的微小變化可能產生巨大的財務影響。

羅恩·科哈維（曾在亞馬遜和後來的 Netflix 負責實驗）被廣泛認為是將現代 A/B 測試實踐數位產品化的先驅。他的工作確立了許多至今仍在使用的統計和營運最佳實踐，包括實驗專案中信任、速度和迭代的重要性。

## 核心要點

<Steps>
  <Step title="定義清晰的假設">
    在測試之前，闡述你期望發生什麼以及為什麼。好的假設指定了變更、預期結果和將衡量成功的指標。
  </Step>

  <Step title="選擇和優先排序指標">
    選擇直接衡量你的目標的主要指標（轉化率、每位使用者收入）。包括次要指標以觀察意外後果。避免優化虛榮指標。
  </Step>

  <Step title="確保統計有效性">
    在開始前計算所需樣本量。執行足夠長時間的測試以達到統計顯著性。理解統計顯著性與實際重要性之間的區別。
  </Step>

  <Step title="正確隨機化">
    隨機分配使用者到測試組以確保可比性。在會話間保持一致的分配（同一使用者看到相同版本）。考慮使用者級與會話級隨機化。
  </Step>

  <Step title="分析並根據結果採取行動">
    在得出結論之前等待足夠的樣本量。仔細考慮細分分析——查看太多區段會增加誤報風險。實施勝利者並迭代失敗者。
  </Step>
</Steps>

## 應用場景

<CardGroup cols={2}>
  <Card title="網站轉化優化">
    電子商務網站測試結帳流程、定價頁面、產品描述和行動呼籲。單個勝利測試可以將收入增加
    10-30%。
  </Card>

  <Card title="行動應用程式優化">
    應用程式開發者測試入門流程、功能配置、付費牆和通知時機。行動測試通常關注參與度和留存指標。
  </Card>

  <Card title="電子郵件行銷">
    行銷人員測試主題行、發送時間、內容佈局和行動呼籲。電子郵件 A/B
    測試通常關注開啟率和點擊率。
  </Card>

  <Card title="廣告創意">
    廣告團隊測試不同的廣告文案、圖片、標題和登陸頁面。廣告級 A/B
    測試優化客戶獲取成本。
  </Card>
</CardGroup>

## 經典案例

Microsoft 的 Bing 搜尋引擎提供了大規模 A/B 測試的典範例子。2009 年至 2015 年間，Bing 團隊在任何時候都執行 200 多個並發 A/B 測試，測試從結果頁面佈局到演算法調整的一切。一個特別值得注意的測試涉及更改預設搜尋設定以包含更多樣化的結果。測試顯示，雖然使用者滿意度提高了，但這最初並沒有轉化為收入增加。然而，團隊發現此變更有助於訓練他們的演算法，帶來長期改善，最終將年收入提高超過 12%——這表明即使初始結果看起來是負面的，執行實驗也有價值。

## 邊界與失效場景

A/B 測試有重要的局限性，從業者必須理解。首先，A/B 測試只能比較小的、漸進的變更；測試激進的設計重新思考很困難，因為使用者經常對新介面反應消極，即使新設計客觀上更好。其次，測試需要大量流量——測試微妙的變更或小改進通常需要數百萬使用者才能達到統計顯著性。

另一個關鍵的失敗模式是「窺視」——在測試達到適當樣本量之前反覆檢查結果，並在結果看起來有希望時提前停止。這顯著增加了誤報率。此外，短期結果通常無法捕捉長期效果，如品牌建立或客戶終身價值。最後，A/B 測試無法解決基本的產品市場匹配問題；再多的按鈕顏色優化也無法挽救沒有人想要的產品。

## 常見迷思

<AccordionGroup>
  <Accordion title="統計顯著性保證勝利結果">
    統計顯著性只告訴你差異可能是真實的，而不是它在實踐中是否重要。統計顯著性的
    0.1% 改善可能不足以證明實施成本是合理的。
  </Accordion>

  <Accordion title="更多測試總是更好">
    執行太多並發測試會造成干擾效應，一個測試中的使用者會受到另一個測試的影響。品質和學習比數量更重要。
  </Accordion>

  <Accordion title="A/B 測試消除了產品直覺的需要">
    A/B
    測試告訴你什麼有效，但不是為什麼。需要良好的產品判斷來生成值得測試的假設並正確解釋結果。
  </Accordion>
</AccordionGroup>

## 相關概念

<CardGroup cols={3}>
  <Card title="假設驅動思考">
    將假設結構化為可測試的預測。A/B 測試是測試產品假設的執行方法。
  </Card>

  <Card title="科學方法">
    測試假設的系統方法。A/B 測試將科學方法應用於產品決策。
  </Card>

  <Card title="PDCA 循環">
    計畫-執行-檢查-行動為迭代測試和學習提供了框架。A/B 測試體現了「檢查」階段。
  </Card>

  <Card title="精益方法論">
    建立增量測試以最小化浪費。A/B
    測試透過在全面實施之前驗證假設來支援精益產品開發。
  </Card>

  <Card title="OKR">
    目標和關鍵結果通常包括可以透過 A/B 實驗測試的指標。OKR 提供目標；A/B
    測試提供衡量。
  </Card>

  <Card title="KPI">
    關鍵績效指標是 A/B 測試衡量的指標。好的 KPI 對於有意義的測試至關重要。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  相信資料而不是直覺——A/B
  測試為哪些變更實際上改善了使用者結果和業務指標提供了統計有效的證據。
</Tip>