在高頻率數位實驗場景中，成長團隊與產品研發團隊經常在相同的頁面、結帳流程或核心轉換路徑上同時推進多項 A/B 測試。若同一位訪客同時命中兩項或多項實驗，將引發交互效應（Interaction Effects）：團隊無法準確判斷指標提升究竟源自哪一個改版方案，且動態流量異動極易觸發樣本比例失衡（Sample Ratio Mismatch, SRM）。
在 Optimizely 中，解決此問題的核心方案是設定互斥實驗組（Exclusion Groups）。互斥實驗組本質上是一個共享流量容器，將多個重疊測試聚合在一起，並透過統一的確定性分流種子對受眾進行科學劃分。被分配至實驗 A 的使用者，在同一互斥組內絕不會被分流至實驗 B。
何時應當使用互斥實驗組（何時應避免使用）
互斥分流能夠保障統計結果的純淨度，但也伴隨明確的代價：流量稀釋。將有限的受眾切分給多個獨立測試，會導致每個實驗獲得的樣本數成倍減少，進而大幅拉長達成統計顯著性所需的時間。
實驗團隊應依據實際業務情境進行權衡：
| 業務情境 | 建議策略 | 決策考量 |
|---|---|---|
| 直接視覺或介面衝突（例如同一頁面爭搶主橫幅 Banner、彈跳視窗改版） | 強制設定互斥實驗組 | 避免排版錯亂與使用者體驗相互干擾。 |
| 高度相關的核心轉換漏斗（例如購物車改版與結帳運費計算同時測試） | 強制設定互斥實驗組 | 杜絕上游改動對下游轉換指標造成隱性交互污染。 |
| 底層演算法核心調整（例如搜尋排序模型與推薦演算法同步改版） | 強制設定互斥實驗組 | 防止演算法重疊引發回應衝突或延遲指標失真。 |
| 互不干擾的獨立頁面區塊（例如頂端導覽列改版與頁尾合規宣告改版） | 同時並行（不設互斥） | 行為交互效應極低；保留完整流量並維持實驗推進速度。 |
| 旨在評估組合綜效（例如探索文案與主按鈕顏色是否存在加乘效果） | 改採多變量測試（MVT） | 全因子 MVT 能夠直接在統計學上量化交互作用，而非人為屏蔽。 |
Optimizely 互斥分流的底層運作機制
在預設狀態下，Optimizely 對各項實驗獨立進行分流計算。針對每個實驗，Optimizely 會將使用者唯一識別碼（User ID 或 Bucketing ID）與實驗 ID（Experiment ID）結合，透過確定性雜湊演算法（MurmurHash3）映射至 0 到 9,999 共計 10,000 個分桶中。
由於各獨立實驗的雜湊因子不同，同一名使用者很可能同時落入多個平行測試的生效區間。
當實驗被納入**互斥實驗組（Exclusion Group）**時，Optimizely 會調整其分流機制：
- 共享分流網域：雜湊函式首先將使用者識別碼與互斥組 ID 進行雜湊運算。
- 確定性區間劃分：10,000 個分桶會嚴格依照互斥組內設定的流量佔比分配給各個成員實驗。
- 強制隔離機制：若使用者落入實驗 A 的分桶範圍，該使用者僅對實驗 A 具備參試資格，系統在互斥組內會直接跳過對實驗 B 或實驗 C 的評估。
決策評估優先順序（Evaluation Order）
在 Optimizely Feature Experimentation 與 Web Experimentation 中，分流決策遵循嚴格的短路評估流程：
- 規則狀態檢查：驗證 Flag 規則或實驗是否處於啟動狀態。
- 強制變體（Forced Variations）：具備最高優先權（用於內部測試與 QA）。
- 白名單名冊（User Allowlisting）：明確指定使用者 ID 對應。
- 使用者設定檔服務（User Profile Service, UPS）：自資料庫讀取跨工作階段的歷史固定指派。
- 受眾鎖定（Audience Targeting）：檢查使用者屬性是否符合受眾規則。
- 互斥組評估（Exclusion Group Evaluation）：確認該使用者是否已被分配至組內其他實驗；若已分配，則直接排除。
- 流量分配與變體雜湊（Traffic Allocation）：依實驗內部設定比例將使用者分配至特定變體。
設定步驟：Optimizely Web Experimentation 用戶端配置
適用於前端或 Edge 邊緣層推行的 Web 改版實驗團隊：
1. 建立互斥組
- 登入 Optimizely Web Experimentation 控制台，前往 Experiments 頁面。
- 點擊 Exclusion Groups 標籤頁。（附註：若已啟用 Optimizely Personalization，請前往 Optimizations > Exclusion Groups）。
- 點擊 Create New Exclusion Group 按鈕。
- 輸入易於識別的名稱（Name）與選填的描述（Description）（例如
Checkout_Funnel_Q2_Exclusion）。
2. 關聯實驗並指派流量佔比
- 勾選欲納入此互斥組的草稿實驗。
- 設定各實驗在互斥組總流量中的分配比例：
- 例如兩個測試各佔 50%；
- 或保留部分流量作為全域對照（例如實驗 1 佔 40%、實驗 2 佔 40%、保留未分配流量 20%）。
- 點擊 Create Exclusion Group 儲存啟用。
3. 檢查頁面觸發與條件匹配
確認納入同一個互斥組的所有實驗，其觸發網址、啟動條件或受眾群體具備相應的重疊基礎，避免因條件不一致導致分流失衡。
設定步驟：Optimizely Feature Experimentation 伺服器端配置
適用於後端服務、行動應用與全端架構的研發團隊：
1. 於 Flags 控制台中建立互斥組
- 前往 Flags 功能選單，切換至 Exclusion Groups 標籤頁。
- 點擊 Create New Exclusion Group。
- 輸入組名稱與描述。
- 選擇生效的目標環境（Environment）（如
Production或Staging，互斥組與環境嚴格綁定）。 - 點擊 Create Exclusion Group 完成建立。
2. 將功能旗標實驗規則綁定至互斥組
- 返回 Flags 列表，進入包含目標實驗規則的功能旗標（Feature Flag）。
- 選取對應環境，點擊進入具體的 Experiment Rule。
- 於 Configure Rule 設定區塊中，找到下拉選單："Add this experiment to the following exclusion group"。
- 於選單中挑選剛建立的互斥組。
- 指定該實驗在互斥組內部所佔有的流量百分比。
- 點擊 Save Experiment 儲存。
- 對所有需維持互斥的平行實驗規則重複上述設定。
3. 透過 REST API 實現自動化配置
對於採用 CI/CD 自動化實驗發布的團隊，可直接利用 Optimizely REST API 完成編排：
- 建立互斥組：發送
POST /v2/groups，酬載為{"name": "Cart_Redesign_Group", "environment_key": "production"}； - 更新互斥組規則：發送
PATCH /v2/groups/{group_id}，帶入rule_id將實驗規則掛載至組內； - 稽核組配置：發送
GET /v2/groups查詢現行環境下的所有互斥分組。
4. SDK 零程式碼額外負擔
互斥機制完全透過設定檔（Datafile）定義，並由 SDK 內部演算法於記憶體中執行。業務邏輯呼叫 client.decide(user_key, flag_key) 時，SDK 會在本地完成互斥排除與分桶映射，完全無須額外的遠端 API 呼叫。
實驗團隊的四大治理黃金準則
為防止數據失真、統計偏誤與難以解釋的指標異常，實驗團隊必須遵守以下四項準則：
1. 互斥組內實驗必須統一步調同步啟動
切勿今天啟動實驗 1，下週才將實驗 2 加入同一互斥組。若部分訪客在單一實驗執行期間已被寫入組級分桶，後續追加實驗會改變分桶邊界，導致舊使用者發生分流位移，或破壞新進樣本的隨機性。
2. 嚴禁在實驗運行期間動態增刪組成員
互斥組內只要有任何一項實驗處於上線狀態：
- 切勿向組內新增實驗；
- 切勿將正在執行的實驗自組內移除。 運行中異動會重置分桶邊界，觸發樣本比例失衡（SRM）警告並導致統計顯著性完全失效。若某一實驗需提前告一段落，應暫停其規則而非解散互斥組。
3. 維持互斥組成員受眾條件的一致性
若實驗 A 面向所有電腦端用戶，而實驗 B 僅針對行動端用戶，將兩者放入同一互斥組會造成流量浪費。因分桶是在組級完成，被分配給實驗 B 的電腦端用戶將直接無法參試，導致實驗 A 失去寶貴的受眾樣本。
4. 注意使用者設定檔服務（UPS）的優先級穿透
在引入 User Profile Service（UPS）以維護跨工作階段變體一致性的架構中，UPS 查詢的優先順序高於互斥組評估。若使用者在納入互斥組之前已記錄了過往的獨立變體，UPS 會直接返回舊結果，進而穿透互斥防護。在此情境下，應使用 OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE 確保受眾隔離。