A/B接口測試

介紹

A/B測試是一個受控實驗，在實際用戶上比較接口的兩個版本（或更多），以了解哪個版本導致更好的產品指標。目的是通過可驗證的更改而不是意見來減少決策中的不確定性，並改善UX。

適當時A/B測試

有一個可測量的目標（轉換，動作時間，保留，NPS，任務速度）。
預期的效果是不可見的，或者可能因段而異。
改變的風險足夠高，足以證明實驗是合理的。
流量允許快速收集具有統計意義的樣本。

最好不要進行測試時：在很少使用的屏幕上進行微拷貝，具有強烈的網絡/社交依賴性（溢出效果）的fici，需要用戶長期學習的編輯。

假設的表述

• 如果我們更改［Y段/全部］的［接口中的X］，則［度量Z］將更改為［方向/大小］，因為［行為原因］。

示例：如果將主CTA移到折彎線以上，並將形狀從6個字段縮短到3個字段，則通過減少摩擦，主要動作的CR將增加+3-5％。

指標： 目標和保護

初級（主要）：一個關鍵,例如完成目標腳本/轉換。
次要：滾動深度、CTR、動作前時間、錯誤、頁面速度。
Guardrails（保護）：性能穩定性（TTFB, LCP）、退款/退款、投訴/回扣、遵守通知限制、可用性。

建議提前MDE（檢測效果最小），觀察窗口和成功標準。

實驗設計

隨機化和分析單位

隨機化單位：用戶（user_id),有時是會話或組織（群集））。
分層/鎖定：如果存在很大差異,則通過設備/鏈路。
溢出（interference）-避免單個組的行為影響另一個組（例如共享列表/磁帶）。在這種情況下，是群集測試。

樣本大小和MDE（簡化）

接近：基本轉換越低，效果越小，樣本越多。
對於CR ~ 10％和MDE ~+5％的相對效應，每個變體通常需要數萬次觀測。

持續時間

專註於整個為期一周的行為周期+庫存（通常為2-4周）或達到計劃容量之前。不要過早停止測試。

坡道（漸進式推理）

1-5％的流量（金絲雀）→ 10-25％ → 50％ → 100％，並監視guardrails。

數據質量和有效性

SRM (Sample Ratio Mismatch)

檢查實際流量分配（A/B）是否符合計劃（例如,50/50）。有意義的偏差=包容/旗幟/機器人問題。

身份和跨字節

使用穩定的user_id；在漏鬥中考慮交叉設備，cookie decay，稍後授權。

機器人與異常

過濾非自然模式（超高速點擊、缺少用戶代理、非有效轉診）。

季節性和事件

除非是測試目的，否則不要對嚴重的「異常」時期（假期/售罄）進行測試。

統計分析

頻率方法（經典）

固定alpha（通常為0.05）和功率（通常為80%）。
不要在沒有調整的情況下每小時「偷看」-假陽性的風險。
對於多個度量/變體，應用調整（Bonferroni/Holm/Hochberg）或度量層次結構。

貝葉斯方法

評估效果概率分布和變體優勢概率。
方便實時監控和決策「足夠好」。

CUPED/協變量

通過測試前協方差（例如上周的活動）減少方差，→更快地獲得功率。

串行/組停止