A/B 測試技巧

對照組（Control Group）在 A/B 測試中扮演「基準」的角色，讓你能把實驗變數跟未改動的版本做直接比較。它是衡量新功能影響力、排除外部因素最重要的參考點。
若設定不當，對照組可能導致測試結果失真甚至錯誤決策，所以本文會說明對照組到底是什麼，以及如何正確設置。

對照組到底是什麼？

對照組在 A/B 測試中，就是不接受任何新功能或改版的那一群使用者，通常保留原始頁面、流程或訊息。因為只有「變化」跟「未變化」兩條路徑，你才能算出改動帶來的效益。

為什麼一定要有對照組？

• 衡量真實影響：沒有基準就無法知道效果是正向、負向還是零差異。 * 排除外部因素：像流量高峰、節日促銷等都會同時影響兩組，才不會把變化誤以為是改版造成的。

設定對照組的三大原則

• 隨機分配 只要能保證每位使用者被隨機指派到 A 或 B，就能確保兩組在基礎屬性（年齡、地區、裝置）上的平衡。 * 比例恰當 常見的分配比率是 1:1 或 3:1（A:B）。若想更快看到變數效果，可把較多流量留給實驗組，但一定要記錄下來，避免「控制組太少」導致統計不穩定。 * 不變動對照內容 控制組的頁面、流程或訊息必須保持原狀；即便測試期間有其他系統更新，也要確保對照組不被影響。

// 範例：將 cookie 設為「control」或「variant」
function assignGroup(userId) {
const hash = crypto.createHash('md5').update(userId).digest('hex');
return parseInt(hash.slice(0, 2), 16) % 2 === 0 ? 'control' : 'variant';
}

常見陷阱與解決方案

• 分配比例失衡 若因程式 bug 導致大部分使用者落在變數組，統計檢定就會失效。 Solution: 在部署前跑單元測試，或加上「比例校驗」的日誌。
• 時間序列效應 早晚流量差異可能誤導結果。 Solution: 隨機分配時同時混洗時間段，例如「先 12 小時 A，再 12 小時 B」。
• 外部活動干擾 節慶、促銷等會影響所有使用者。 Solution: 在報告中註明期間，同時在分析階段做「時間分層」或「事件控制」處理。

如何驗證對照組設定正確？

• 基礎統計檢查 確認兩組人數、平均值、標準差大致相同。 * 用 t 檢定或 Chi‑square 檢定看是否有顯著差異。
• 可視化確認
  import seaborn as sns, matplotlib.pyplot as plt
  sns.histplot(df, x='age', hue='group')
  plt.show()
• 持續監控 在測試期間即時查看關鍵指標（CTR、轉換率）是否出現劇烈波動。 若波動過大，立即檢查分配邏輯。

小結

對照組不是「被忽略」的旁觀者，而是 A/B 測試中最重要的參考點。只要遵循隨機、比例平衡、不變動三原則，再加上驗證手段，你就能確保測試結果可信，從而做出更安全、更有效的改版決策。

在進行 A/B 測試時，變體的選擇往往是成敗關鍵。本文將分享實用技巧，幫你確保每一個好點子都能被充分測試，而不會因為忽略或誤判而錯過最佳化機會。
接下來，我們會從變體設計的基本原則、篩選流程，到具體工具與實例，逐步帶領你了解如何有效挑選並驗證每一個有潛力的方案。

變體挑選的基礎概念

• 什麼是變體？ 在 A/B 測試中，變體指的是你要比較的不同版本，例如「按鈕顏色」或「頁面排版」。
• 為何不隨便挑選？ 若一開始就把所有想法都塞進測試，樣本會被過度分散，統計效能下降，結果難以解釋。

先定義目標：要測什麼？

• 核心指標 (KPI)：轉換率、平均訂單價值、停留時間等。
• 假設檢驗：例如「改用深藍色按鈕會提升點擊率 5%」。

篩選流程：從好點子到可測試變體

1. 收集想法：團隊頭腦風暴、使用者回饋或競品分析。
2. 評估影響力：每個想法對 KPI 的潛在提升幅度，先做粗略量化（如預期 3%–10%）。
3. 可行性檢查：技術是否支持、開發成本與時間。
4. 優先排序：採用「ICE」分數法（Impact × Confidence × Effort）或簡單的權重表。

例子：ICE 分數實作

• Impact: 10 (高影響)
• Confidence: 8 (大致相當確信)
• Effort: 3 (小成本)
• ICE = (10×8)/3 ≈ 26.7，排名前列。

样本量計算示範

假設：基準轉換率 p0=0.05，期望提升 d=0.01（即 20% 相對提升）

使用常見的雙邊 z 檢驗公式（95% 信賴度、80% 測試力）

import math
p0 = 0.05
p1 = p0 + 0.01
alpha = 0.05
beta = 0.2
z_alpha = 1.96 # 兩尾 95%
z_beta = 0.84 # 80% 測試力
p_bar = (p0 + p1) / 2
n_per_group = math.ceil((z_alpha2 * p_bar*(1-p_bar) + z_beta2 * (p0*(1-p0)+p1*(1-p1))) / (p1 - p0)**2)
print(f"每組需要約 {n_per_group:,} 次曝光")

篩選工具：簡易表格範例

#	變體描述	Impact	Confidence	Effort	ICE
1	深藍色按鈕	10	8	3	26.7
2	新的 CTA 文案	8	9	4	18
3	數位滑動 banner	6	7	5	8.4

實際操作：從想法到實驗設計

• 步驟一：在 Excel 或 Google Sheet 裡整理以上表格，確定每個變體的 ICE 分數。
• 步驟二：挑選前兩名作為首批測試；若資源允許，再加上第三名。
• 步驟三：設定目標樣本量（如上一段程式碼示範），並在網站中實作對應變體。

監控與迭代

• 持續追蹤 KPI：確保測試期間沒有外部事件干擾。
• 統計顯著性：使用 t 檢驗或 z 檢驗，確認差異是否真實。
• 快速迭代：若某變體達到顯著提升，即可直接上線；若不符預期，再回到篩選流程調整。

小結：別讓好點子被忽略的秘訣

• 先定義 KPI，後挑變體：確保所有變體都與目標直接對應。
• 量化評估、可行性檢查：避免把不可落地或成本過高的點子塞進測試。
• 使用分數法排序：客觀比較多個想法，減少主觀偏誤。
• 設定樣本量與顯著水準：保證測試結果可靠。

透過上述流程，你可以在不浪費資源的前提下，把每一個有潛力的點子都給機會，讓 A/B 測試真正成為提升業務績效的利器。

隨機化方法大解密，確保公平性
在 A/B 測試中，公平的分組是取得可靠結果的關鍵。這篇文章將帶你了解常見的隨機化技巧、避免偏差的方法，以及實際範例與程式碼示範。

隨機化的基本概念

在 A/B 測試中，隨機化是確保兩組受測者相似的重要手段。透過隨機分配，能降低樣本差異、避免外部因素影響結果。

常見的隨機化方法

• 簡單隨機：每位使用者以等概率被指派到 A 或 B。
• 分層隨機：先按關鍵變數（如地區、裝置）做分層，再在各層內進行簡單隨機，確保重要特徵均衡。
• 區塊隨機：將樣本拆成固定大小的區塊，每個區塊裡等量分配 A、B，減少時間序列偏差。
• 集群隨機：整個群組（如同一個網站使用者）一次性指派給 A 或 B，適用於需要避免跨群互動的情況。

如何實作簡單隨機分配

以下以 Python 為例，示範如何把使用者 ID 隨機映射到兩組：

import random

假設有一個使用者清單

user_ids = [101, 102, 103, 104, 105]

建立分配字典

assignment = {}

for uid in user_ids:
assignment[uid] = random.choice(['A', 'B'])

print(assignment)

檢查隨機化結果的公平性

• 統計檢定：使用卡方檢定確認兩組人數是否相等。
• 特徵分佈比對：比較關鍵指標（如裝置、地區）在兩組中的比例，確保無顯著差異。

範例：使用 Pandas 進行分層隨機

import pandas as pd
import numpy as np

建立範例資料

df = pd.DataFrame({
'user_id': range(1, 201),
'region': np.random.choice(['北部', '中部', '南部'], 200)
})

分層隨機分配

df['group'] = df.groupby('region')['user_id'].transform(
lambda x: np.random.permutation(np.repeat(['A', 'B'], len(x)//2 + len(x)%2))[:len(x)]
)

檢查分佈

print(df['group'].value_counts())

小結

隨機化不是單純的「亂數」操作，而是要配合實驗設計、樣本特徵與統計方法，才能真正確保 A/B 測試的公平性。透過以上技巧，你就能在日常測試中快速落地，更安心地依賴結果做決策。

在進行 A/B 測試時，往往會因為測試者的主觀偏好而產生誤差。盲測（Blind Testing）就是一種減少此類偏見的方法。
這篇文章將說明如何把盲測應用到 A/B 測試中，以及在實際操作時需要注意哪些細節。

什麼是盲測？

盲測指的是參與者（或測試者）不清楚自己正在接觸的版本，只有在數據收集完畢後才會知道。這樣就能避免因為先入為主而影響行為或評價。

為什麼要在 A/B 測試中使用盲測？

• 減少偏見：如果測試者知道自己是 A 版還是 B 版，可能會不自覺地給予更多肯定或批評。
• 提高信度：資料更客觀，統計檢定的結果也更可信。
• 提升決策品質：真正反映用戶行為，而非測試者主觀判斷。

如何設計一個盲測流程？

隱藏版本資訊

1. 在前端程式碼中，將 A 與 B 的差異抽離成獨立模組。<br>2. 測試頁面只載入「主體模組」，不暴露版別關鍵字。

隨機分配與記錄

• 使用伺服器端的隨機函式將使用者分到 A 或 B，並寫入 Session ID。<br>- 這個 Session ID 在前端不會顯示或被任何人手動更改。

數據收集

• 所有互動（點擊、停留時間等）都以 Session ID 為標籤記錄。<br>- 測試結束後，才將 Session ID 與對應的版本進行關聯。

例子：使用 JavaScript 隨機分配

// 隨機選取 A 或 B
function assignVariant() {
const variant = Math.random() < 0.5 ? 'A' : 'B';
// 儲存至 cookie，供後續收集使用
document.cookie = variant=${variant}; path=/;;
return variant;
}

// 在頁面載入時執行
const currentVariant = assignVariant();
console.log(目前版本為 ${currentVariant});

數據分析示例（簡化版）

• 表格：展示兩組的主要指標差異。

指標	版本 A	版本 B	差距	p 值
點擊率	4.2%	5.1%	+0.9%	0.03
留存率	12.3%	11.8%	-0.5%	0.45

常見陷阱與解決方案

• 版本標籤洩露：確保前端程式碼不直接顯示 variant。若使用 CSS，請用動態載入而非硬編碼。
• 測試者未盲目操作：在實際測試時，所有人都應遵守「只按流程，不討論版本」的規則。可設置簡短培訓文件提醒大家。
• 數據混亂：若多個團隊同時執行 A/B 測試，務必在 Session ID 或 Cookie 名稱上做唯一標識，避免覆蓋。

小結

盲測不僅能提升 A/B 測試的客觀性，也讓結果更具說服力。只要設計好流程、隱藏關鍵資訊並嚴格執行，就能在日常產品實驗中得到更可靠的洞察。

進一步閱讀

• A/B 測試最佳化指引（官方文檔）
• 數據科學家談盲測的重要性

在 A/B 測試中，功效分析（Power）是評估樣本大小是否足夠捕捉實際差異的關鍵指標。
本文將從概念、重要性以及如何計算 Power 這三個面向，帶你深入了解為什麼它不只是數字遊戲，而是真正影響決策品質的核心工具。

功效分析（Power）說明，為什麼它很重要

功效分析，簡稱 Power，是統計檢定中用來衡量「假設真實差異存在時，我們能正確拒絕虛無假說」的機率。

Power 是什麼？

Power 的定義可以想像成一場大雨裡你要抓住雨滴的機率：如果雨很大（差異明顯）而你的網子足夠寬，抓到雨滴的機率就高；相反地，如果雨小或網子太窄，就容易錯過。

為什麼 Power 重要？

• 避免偽陰性：若 Power 太低，真正有差異的情況可能被誤判為無效，導致錯失機會。
• 資源節省：知道需要多少樣本才能達到目標 Power，可以避免浪費時間與成本在不必要的大規模測試上。
• 決策信心：高 Power 的結果能給管理層更堅實的依據，減少因數據不足而產生的不確定性。

如何計算 Power？

在 A/B 測試中，我們常用的公式大致如下：

power = Φ( (Δ / σ) * √n - z₁-α/2 )

其中：

• Δ 是兩組平均值之差（效應量）。
• σ 為資料標準差，若無歷史資料可使用預估值。
• n 代表單邊樣本數；若有雙邊測試則需乘以 2。
• z₁-α/2 為顯著性水平對應的標準正態分布臨界值（例如 α=0.05 時為 1.96）。

實務上，我們常用統計軟體或線上樣本量計算器直接輸入 α、期望 Power、效應量與變異度，即可得到所需 n。若想自行估算，可使用簡化版公式：

n ≈ ( (z₁-α/2 + z_power) * σ / Δ )²

舉例說，若你想在網站上測試兩種登錄流程的轉換率差異從 4% 提升至 6%，且預估標準差為 0.05，設定 α = 0.05、目標 Power = 90% 時，計算器會顯示每組需約 600 名使用者。

小結

功效分析讓你不再只關注「差異是否顯著」，而是確保你的實驗設計能在合理的樣本量內，以高機率捕捉到真實差異。掌握 Power 的概念與計算，才能避免資源浪費、錯失機會，也讓決策更有底氣。

在A/B測試裡，效應量估計不只是統計顯著性的檢驗，而是衡量兩組之間差異大小的工具。它告訴你「這個改動真的有意義嗎？」而不是單純說 "p值<0.05"。
透過合適的效應量估計，你可以在樣本不足時仍然判斷改變的重要性，亦能避免因為數字太小而被忽略，但實際上卻對業務有顯著影響。

效應量估計的基本概念

• Cohen's d：兩組平均數之差除以合併標準差，常用於連續變項。
• Odds ratio (OR)：適用於二元結果，例如使用者是否點擊。
• Risk difference (RD)：兩組發生率的差值，更直觀說明改動帶來的提升幅度。

為什麼小差異也能顯著

1. 樣本量足夠：即使效應很微小，只要資料量大，統計檢定就有能力偵測。
2. 變數離散度低：當標準差較小時，Cohen's d 會顯得更高，即便平均差不大。

計算範例：A/B 測試中的轉換率提升

• 組 A (控制)：10000 次瀏覽中 200 人轉換，轉換率 2.0%。
• 組 B (實驗)：12000 次瀏覽中 360 人轉換，轉換率 3.0%。

計算風險差：

RD = p_B - p_A
   = 0.030 - 0.020
   = 0.010  # 即 1% 的提升

若要估算 Cohen's d，先將轉換率視為二元變數的比例，可用下列公式近似：

#### 轉換率差距 (Δp)
Delta_p = p_B - p_A
#### 標準誤差 SE = sqrt(p*(1-p) * (2/N))
SE = sqrt((p_avg)*(1-p_avg)*(2/avg_N))
#### Cohen's d ≈ Δp / SE

參考公式與工具

• R: library(pwr) → pwr.t.test() 可直接輸入效應量、α 與功效求樣本量。
• Python: statsmodels.stats.power.tt_ind_solve_power() 或 pingouin.pwr.anova_rm。

小結

效應量估計讓你不只停留在 "p值" 的表面，而是能看見差異背後的實際大小。即使變化微小，只要對業務關鍵指標（如轉換率、平均訂單價）產生正向影響，仍值得投入資源去優化。

在 A/B 測試裡，信賴區間不只是統計術語，它能告訴你結果背後的風險。透過範圍大小，你就能判斷「這個差異是真實存在還是偶然」以及「多大機率會偏離我們預期」。
以下內容將用簡單例子說明如何讀取信賴區間、計算方式及其對決策的影響，讓你在設計測試或評估結果時更有底氣。

信賴區間解讀，從數字看風險

在 A/B 測試中，我們往往只關心 p 值是否小於 0.05，但這個「顯著」其實只是說明差異不太可能是偶然產生。真正想知道的是：若重複測試，觀察到的效果會落在哪個範圍？信賴區間就能給你答案。

簡單來說，信賴區間是一組上下限，代表在多次實驗中，有 95%（或 99%）的機率包含真實效應大小。例如，若某頁面改版後轉換率提升 1.5%，且 95% CI 為 +0.8% 到 +2.2%，就表示你可以相當確定這次改動真的有效，並且預計提升幅度不會小於 0.8%。

以下幾個要點有助於快速閱讀信賴區間：

• 上下限越窄 → 效果估計越精確。
• 若 CI 包含零，表示差異在統計上不顯著；若完全位於正面或負面，則顯著。
• 95% CI 與 99% CI 的比較：前者更寬、保守性較低，後者更寬、風險更小。

原組：200/1000，改版：240/1000

prop.test(c(200,240), c(1000,1000))$conf.int

可信度	上限	下限	意義
95%	+2.2%	+0.8%	常用、風險適中
99%	+2.5%	+0.5%	更保守、風險更低

在進行 A/B 測試時，流失率高往往是成敗關鍵。這篇文章將帶你從樣本大小、分析方法到實際操作三大面向，學會如何降低因流失造成的測試失敗。
我們先快速說明什麼是「流失率」以及它對統計顯著性的影響，再進一步探討幾個可落地的解決方案。

為何流失率會破壞測試結果

當使用者在實驗期間離開或停止互動，系統就無法收集他們的行為資料。若流失比例高於預期，就相當於把「未完成」的觀測值視為缺漏，導致樣本量不足、變異度擴大，最終使得統計檢定力下降。

1️⃣ 減少流失：先從目標設定做起

• 明確分組：在設計實驗時，盡量避免把同一使用者同時加入多個變數。若必須跨變數，可採用「分批」方式，每次只調整單一變數。
• 設定合理的測試期間：太長會讓使用者疲勞；太短則可能未能觀察到真正行為改變。例如，推播功能的 A/B 只需 7 天即可看見點擊率趨勢，而大型功能更新則建議 14~21 天。
• 提供即時回饋：在實驗介面加入「你現在參與的是測試」提示，並允許使用者隨時退出。這樣可以降低因不知情而產生的流失感。

2️⃣ 調整樣本大小以抵禦流失

• 在計算所需樣本量時，先預估流失率（例如 20%）。再將目標樣本量除以 (1 - 流失率) 來調整。

預估流失率	原始樣本數	調整後樣本數
0%	1,000	1,000
20%	1,000	1,250
35%	1,000	1,538

3️⃣ 利用分層抽樣降低流失影響

• 將使用者依重要指標（如月活躍度、付費行為）拆成幾個層級，確保每一層都有足夠代表性。若某層的流失率高，可單獨加大該層樣本量。

4️⃣ 在分析階段做「意圖處理」

• 意圖保留法（Intention‑to‑Treat, ITT）：即使使用者離開，也以原分組方式計算結果，減少選擇性流失帶來的偏差。
• 補全缺漏法：利用多重插補或機器學習預測遺失值，再進行統計檢定。

5️⃣ 實務範例：從數據到決策

假設我們有兩組資料，A 組流失率 18%，B 組流失率 25%

import numpy as np
from statsmodels.stats.power import TTestIndPower

def adjusted_n(n, loss_rate):
return int(np.ceil(n / (1 - loss_rate)))

base_n = 1200 # 原始計算得到的樣本數
n_a = adjusted_n(base_n, 0.18)
n_b = adjusted_n(base_n, 0.25)
print('A 組需 ', n_a, '人')
print('B 組需 ', n_b, '人')

6️⃣ 監控流失率：持續改進的關鍵

• 在測試執行期間，建立實時儀表板顯示每日流失率。若異常波動，即可立刻調整招募或訊息設計。
• 定期回顧歷史數據，找出哪些使用者屬性與高流失相關，進一步優化實驗流程。

MVT（多變項測試）是一次性同時比較多個改版的實驗方法，讓你能更快找出最佳組合。它與傳統 A/B 測試的關係在於：A/B 只比對兩個版本，而 MVT 能同時跑三個以上變數並觀察交互效應。
透過 MVT，你可以一次測試多種設計、內容或功能的變化，縮短實驗週期、提升資料洞見。

什麼是 MVT

多變項測試（MVT）是一種一次跑多個改版的實驗方法。它不僅可以同時檢測多個設計元素，還能找出各組合之間的相互作用。

A/B 測試則是比較兩個版本（A 與 B）的表現；MVT 讓你一次跑 A、B、C 等多種變數。

為何選擇 MVT

• 節省時間：一次就能測試多種改版，避免重複實驗。
• 更完整洞察：可觀察不同設計元素之間的互動效應。
• 提升轉換率：快速定位最佳組合，更精準最佳化。

A/B 與 MVT 的關係

特色	A/B 測試	MVT
變數	一個	多個
組合	2	n^k (可多重)
目標	簡單比較	深度洞察

注意：MVT 的樣本量需求通常比 A/B 大，因為要覆蓋更多組合。

MVT 實務範例

假設你想同時測試「按鈕顏色」、「標題文字」和「圖片位置」三個變數。

• 按鈕顏色：紅、藍、綠 (3 種)
• 標題文字：A、B (2 種)
• 圖片位置：左、右 (2 種)

總共 3 × 2 × 2 = 12 個組合。你只需要一次實驗就能得到所有組合的表現。

for each user visit:
assign random combination of button, title, image
record conversion
end
analyze results per component and interaction

此範例可直接套用於網站首頁、產品頁或行銷電郵。

小結

• MVT 是一次跑多個改版的秘密武器，能更快找出最佳組合。
• 它與 A/B 的關係是：A/B 為單一變數比較，而 MVT 能同時測試多個變數並觀察交互效應。
• 只要掌握樣本量和實驗設計，MVT 就能成為你最佳化流程中的重要工具。

在多變項測試 (MVT) 中，選擇合適的設計模式對於實驗結果與開發效率都有重大影響。本文將說明三種常見模式：全域、區塊和頁面級，並以簡單例子協助你快速判斷哪一種最符合需求。
透過表格比較、實際程式碼示範與開發建議，我們希望能幫你在設計改版時更精準地掌控變數範圍。

常見設計模式：全域、區塊、頁面級

多變項測試常被誤解為「一次跑幾個改版」。其實關鍵在於你決定 哪些元件 會同時被變更。下面以三種分層方式說明，並附上實際範例。

全域級別（Global）

• 定義：整個網站或應用程式的共通樣式、腳本、字串皆成為變數來源。
• 優點
  • 變更一次即可覆蓋所有頁面，維護成本低。
  • 適合品牌色彩、全站訊息通知等大範圍改版。
• 缺點
  • 任何小錯誤都會波及整個系統，風險較高。
  • 難以針對單一使用者族群做精準測試。

<!-- global.css -->
:root {
--primary-color: #0066CC;
}

區塊級別（Block）

• 定義：同一區域、元件（如 banner、CTA）在不同頁面共用，但可以單獨變更。
• 優點
  • 能針對多個頁面同時測試相同設計，提升樣本量。
  • 減少重複碼，維護仍相對容易。
• 缺點
  • 若區塊內還包含頁面特有元素，需要額外處理。

<!-- banner.html -->
<div class='banner' style='background-color: var(--primary-color)'>
<h1>歡迎來到我們的網站！</h1>
</div>

頁面級別（Page）

• 定義：每個頁面獨立設計，互相不共享任何變數。
• 優點
  • 可以針對特定功能或使用者旅程做極致優化。
  • 風險分散，單一頁面失敗不會影響其他頁面。
• 缺點
  • 開發成本與維護成本最高。
  • 样本量較小，統計功效可能不足。

<!-- checkout.html -->
<div class='checkout-form'>
<!-- unique to checkout page -->
</div>

表格對比

模式	適用範圍	維護成本	風險	样本量
全域	整站共通	低	高	大
區塊	同一區域多頁	中	中	中
頁面	單一頁面	高	低	小

實務建議

1. 先從全域或區塊做「快速迭代」：如果你想測試品牌色彩或 CTA 文本，先用全域/區塊即可取得大量數據。
2. 使用 CSS 變數與資料屬性：把可變的值寫成自訂屬性（--color-primary 或 data-variant='A'），讓 JavaScript 能動態切換。
3. 記錄「改版邏輯」：在 Git 分支或專案文件中標註每一次 MVT 的變數範圍，方便回溯與重複實驗。
4. 分層測試流程：先做全域/區塊級別的 A/B 測試；若結果顯示某個頁面表現最佳，再進行該頁面的細節優化。

小結

• 全域模式 適合大範圍改版，維護簡易但風險高。
• 區塊模式 在多頁共用元件時提供平衡方案，可同時提升樣本量與控制成本。
• 頁面模式 針對單一功能深度優化，風險分散，但開發投入大。

選擇合適的設計模式，就是讓 MVT 更高效、更安全的關鍵。祝你在改版實驗中取得成功！

本篇將帶你從 Excel 的簡易分析，到專業平台的進階功能，全面剖析多變項測試（MVT）所需的分析工具。
不論你是初學者還是資深分析師，都能在這裡找到適合自己的工具與實作範例。

為什麼要升級分析工具

在多變項測試中，你常會面對數千筆訪客資料，單靠手動整理不但耗時，更容易發生錯誤。升級到更專業的工具，可以自動化報表、加速洞察，讓你把時間花在決策上，而非維護資料。

以 Excel 開始：基礎功能與常用技巧

雖然 Excel 的功能已相當強大，但要真正發揮 MVT 分析的潛力，你需要掌握幾個關鍵技巧：

• PivotTable：快速做出交叉表，看到不同變數之間的關係。
• 公式組合：如 SUMIFS、COUNTIF 讓你在同一工作表裡完成多重條件計算。
• Power Query：一次性匯入多個檔案，並自動清洗資料，省下大量手動步驟。

=SUMIFS(C2:C100, A2:A100, "改版A", B2:B100, "改版B")
這行公式會計算同時符合兩個改版條件的營收總和，對於 MVT 的效益評估非常實用。

高階公式 & Power Query 範例

=LET(
data, FILTER(A2:D100, A2:A100="改版A"),
result, SUM(data[Revenue])
)
透過 LET 函式，你可以把常用的篩選結果命名，讓公式更易讀且執行速度提升。

專業分析平台概覽

Google Analytics 4（GA4）與 BigQuery

GA4 內建事件追蹤功能，結合 BigQuery 可以直接查詢原始資料，支援複雜的 MVT 報表需求。

SELECT
user_pseudo_id,
event_name,
COUNT(*) AS event_count
FROM
project.dataset.events_*
WHERE
event_name IN ('view_item', 'add_to_cart')
GROUP BY
1,2
這段 SQL 能快速統計不同事件在各改版版本的出現頻率。

Optimizely / VWO

Optimizely 與 VWO 提供即時 A/B/MVT 統計介面，內建分群與轉換追蹤功能，能直接把結果匯出為 CSV 或連結到 BI 工具。舉例來說，你可以在測試頁面設定兩個變數：

• 版型（A、B）
• 按鈕顏色（紅、藍）

然後使用平台內建的分群報表，快速查看哪一組的點擊率最高。

Python + Pandas：自由度最高的分析方式

若你熟悉程式語言，Pandas 可以處理任何尺寸資料，並結合 matplotlib 或 seaborn 做視覺化。以下是一個簡易範例：

import pandas as pd

df = pd.read_csv('mvt_results.csv')

只保留兩個改版變數

filtered = df[['variant_a', 'variant_b', 'conversion']]

計算各組轉換率

summary = filtered.groupby(['variant_a', 'variant_b'])['conversion'].mean().unstack()
print(summary)
這段程式碼會輸出每個變數組合的平均轉換率，方便你直接比較。

SQL 之於 MVT 報表

在資料庫裡做聚合計算，比起 Excel 更具可重複性與擴充性。以下範例使用 MySQL：

SELECT
variant_a,
variant_b,
COUNT() AS sessions,
SUM(conversion) / COUNT() AS conversion_rate
FROM
mvt_sessions
GROUP BY
variant_a, variant_b;
這樣就能一次得到所有組合的會話數與轉換率。

如何選擇適合自己的工具

• 資料量：小規模可用 Excel；大規模則建議 GA4 + BigQuery 或專業平台。
• 技術門檻：不懂程式者偏好 Optimizely/VWO；熟悉 Python 可直接使用 Pandas。
• 報表需求：需要即時儀表板可考慮 BI 工具（如 Power BI、Looker Studio）。

小結與實作建議

從 Excel 開始，先把基礎資料整理好，再逐步引進專業平台。關鍵是保持報表的一致性：確保所有工具都使用相同的變數命名與計算邏輯，才能避免分析結果互不一致。

最後，別忘了定期回顧你的分析流程，找出可以自動化或最佳化（最佳化）的步驟。

在多變項測試（MVT）中，決定部署策略是關鍵一步。你會選擇先行測試一小部分流量，還是直接把改版推到全站？這兩種做法各有利弊，本文將帶你拆解、比較並提供實務建議，幫助你在改版時降低風險、提升效益。
我們會從風險評估、成本考量、數據完整性等角度切入，最後給出一個可落地的部署流程範例。

先行測試：小流量逐步驗證

在此策略下，你只把改版推送到少量使用者（如5%）或特定區域，觀察指標變化後再決定是否擴大。這種方式可以快速捕捉問題，但需要確保測試樣本足夠代表整體流量。

優點

• 風險可控：即使發現嚴重 bug，也只影響少數使用者。
• 及時調整：根據測試結果立刻修正或優化，避免浪費時間。

範例：使用 GitHub Actions 部署 Canary 版本

name: Deploy Canary
on:
push:
branches:
- main
jobs:
deploy-canary:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Build Docker image
run: docker build -t myapp:${{ github.sha }} .
- name: Push to registry
run: echo ${{ secrets.REGISTRY_PASS }} | docker login -u ${{ secrets.REGISTRY_USER }} --password-stdin
run: docker push myapp:${{ github.sha }}
- name: Deploy to staging
uses: azure/webapps-deploy@v2
with:
app-name: 'myapp-staging'
images: 'myapp:${{ github.sha }}'

全站上線：一次性推送

此策略將改版直接推到所有使用者，適用於變更範圍小、風險低或已經通過充分測試的情況。雖然部署速度快，但一旦出錯，恢復成本高。

如何選擇？

1. 風險評估：若改動涉及核心功能或大規模資料流，建議先行測試；若是小幅 UI 優化，可直接全站上線。
2. 時間成本：先行測試需要多輪部署與監控，適合長期專案；全站上線則節省人力資源，適用於短期活動。
3. 數據完整性：若你需要精準的 A/B 結果，必須確保樣本隨機且覆蓋面廣；先行測試可能因流量限制而影響統計效能。

兩種策略結合：Hybrid 部署

許多團隊採用 hybrid 方法：先在 staging 環境做大量自動化測試，接著選擇小流量 Canary，再根據指標決定是否全站上線。這樣既保留了風險控制，又不失推廣速度。

典型流程圖

1️⃣ 定義改版範圍
2️⃣ 建立測試環境（Staging）
3️⃣ 推送到 Canary (5% 流量)
4️⃣ 監控指標 & 收集回饋
5️⃣ 若 OK → 全站上線
6️⃣ 若 NG → 回退或修正

小結

• 先行測試：適合高風險、需要確保品質的改版。
• 全站上線：適合低風險、快速迭代的場景。
• Hybrid：兼顧安全與效率，為最佳實踐之一。
  根據你團隊的規模、產品特性以及客戶期望，挑選最符合需求的部署策略吧！

本篇文章將帶你走進 A/B 測試的指標選擇世界，告訴你為什麼單看表面 KPI 會錯失深層洞見。
我們會用簡易案例與實務建議，教你如何挑選真正能驅動業績成長的關鍵數據。

指標選擇法則：別只看表面 KPI

在 A/B 測試中，我們往往會先抓住最直觀的「點擊率」或「轉換率」等指標，卻忽略了背後的動因。若只依賴這些表面數字，可能會把成功與失敗歸結於偶然，而非真實原因。

以下將以三個常見場景說明：

• 轉換率高，但每次點擊平均停留時間卻極短 → 可能是「流量來源」不合適，或頁面設計過度簡化。
• 點擊率大幅提升，但訂閱數並無變化 → 受眾興趣未對應到實際需求。
• 銷售額上升，但顧客回購比例下降 → 成功是一次性促銷，長期價值不一定增長。

步驟一：界定業務目標

1️⃣ 確認你想要提升的是「收入」還是「品牌曝光」。
2️⃣ 把大目標拆成可量化的小指標，例如

• 每位顧客平均消費額（ARPU）
• 顧客終身價值（CLV）
• 會員續約率

步驟二：篩選「行為」與「情感」雙重維度

表面 KPI 多半屬於行為數據，缺乏對使用者情感的洞察。建議同時追蹤:

• 熱點圖（Heatmap）顯示滑鼠移動位置
• 使用者滿意度調查（NPS）
• 影片觀看完成率

步驟三：建立因果關係模型

不要只看「相關」就說『A 造成 B』。可以透過
1️⃣ 隨機化抽樣（Randomised Controlled Trial）確保組別差異只有變數本身。
2️⃣ 使用「斷層回歸」（Regression Discontinuity）辨識閾值效應。
3️⃣ 進行敏感度分析，測試不同假設下的結果穩定性。

範例：從「加入購物車率」到「淨利潤增幅」

指標	目的	可能誤導點	深層補充指標
加入購物車率	反映使用者興趣	低價優惠會提升數字，但實際支付率不一定	商品平均售價、結帳成功率
結帳成功率	衡量結帳流程效率	高成功率可能因為簡化步驟，卻忽略付款方式多元化	支付方式分佈、退款比例
淨利潤增幅	最終商業價值	只看毛利率會忽略營運成本變動	營業費用比率、客戶獲取成本（CAC）

實務小貼士

• 每次測試都先寫一段「假設與預期」的說明，避免結果被後續解讀偏差。
• 用表格整理 KPI 與深層指標，方便團隊共識。
• 定期回顧已完成測試的數據，找出哪些深層指標最能預測長期績效。

小結

在 A/B 測試裡，真正的勝負往往決定於你是否把「為什麼」和「怎麼做」一起說清楚，而非只看表面的數字。透過設定明確目標、擴展行為與情感維度，以及建立因果模型，你可以將測試結果轉化成可落實的商業洞見，真正讓決策更有力。

在 A/B 測試結束後，我們往往會先看整體平均數，卻忽略了背後多重族群帶來的差異。這篇文章將教你如何進行分層分析，讓每個細部都能說故事。
透過切割資料、檢定統計顯著性與故事化敘述，你就能精準找出哪些族群受到測試變更的影響最大。

分層分析：不同族群差異到底在哪？

在進行 A/B 測試後，我們往往先看整體平均數，卻忽略了背後的多重族群。這份教學將帶你拆解「分層分析」，讓每個細部都能說故事。

1️⃣ 先把資料切成小塊

• 以使用者特徵（年齡、地區、裝置）或行為習慣（瀏覽頻率、購買力）作為分層依據。
• 例如：將「新用戶」與「老用戶」分開，再看各自的轉換率差距。

2️⃣ 確認統計顯著性

• 每個族群都要單獨做 t 檢定或 chi‑square，確保差異不是偶然。
• 若樣本量不足，可採用「合併分層」或「加權平均」方式。

3️⃣ 解讀各族群結果

• 若 A 組在「高價值客戶」中表現突出，但整體沒顯著，說明這部分族群是關鍵。
• 反之，如果「低價值客戶」差異很大但對總收入影響小，也值得注意。

4️⃣ 舉例說明：實際分層分析流程

-- 篩選出年齡在 25-34 歲的使用者
SELECT user_id, conversion FROM event_log WHERE age BETWEEN 25 AND 34;

5️⃣ 把結果寫成故事

• 用簡單圖表（柱狀圖、箱型圖）呈現各族群差距。
• 給出結論：例如「針對 35 歲以上的用戶，A 組提升了 12% 的訂閱率」，並提出後續優化建議。

小結

• 分層分析讓你不再只看整體平均，而是洞察各個族群的真實差異。
• 透過正確切割、統計檢定與故事化敘述，能更精準地決策下一步動作。

在數位行銷的世界裡，歸因模型不只是統計術語，它是幫你了解「哪個觸點真正帶來轉換」的關鍵。今天，我們就以 A/B 測試為例，一起拆解不同歸因模型背後的邏輯，並挑選出最適合你的方法。
從最後一次點擊到第一個曝光，再到時間衰減與位置分配，每一種模型都有其優缺點。別擔心，我會用簡單案例跟你說清楚，讓你在報告中能把數據講成故事，而不只是冷冰冰的表格。

歸因模型簡介，誰是真正的贏家？

在 A/B 測試裡，我們常見到兩個版本——A 與 B。當使用者最終完成目標（例如購買、註冊）時，他們曾經走過許多路徑：點擊廣告、瀏覽網頁、收到電子報……歸因模型就是幫我們決定「這些觸點中哪一個應該獲得最多信用」。

常見的歸因模型

模型	優點	缺點	適用情境
Last Touch (最後一次觸碰)	簡單易懂	忽略前期努力	僅需快速決策時
First Touch (第一次接觸)	強調啟動階段	可能低估後續驅動力	新客戶開發
Linear (線性分配)	平均分配價值	忽略關鍵點	整體流程平衡時
Time Decay (時間衰減)	重視最近觸碰	需要設定 decay 參數	長期使用者旅程
U‑shaped (U 型)	重視首尾兩端	中間忽略	訂閱型服務

為什麼「贏家」不是固定的？

• 產業差異：電子商務、SaaS、遊戲等行業，使用者旅程長短不同，適合模型也會改變。
• 目標差異：如果你想提升新客戶轉化，First Touch 或 U‑shaped 可能更有效；若是加速決策，Last Touch 便是主力。
• 數據可得性：有些公司缺乏完整的使用者行為記錄，這時就只能選擇較簡易的模型。

實際案例：A/B 測試中的歸因計算

假設你測試兩個登錄頁面（Variant A & B）。在一週內，總共有 300 名使用者完成註冊，其中 180 名屬於 Variant A、120 名屬於 Variant B。每位使用者有不同的觸點組合：

• A1: 廣告 → 網站首頁 → 登錄頁面 (Last Touch) = 0.5% CVR
• B1: 電子報 → 社群貼文 → 登錄頁面 (Linear) = 1.2% CVR

以 Last Touch 為例：A Variant 的 CVR = 180 / (180+120) × 100% ≈ 60%；但若改用 Linear，則 A 和 B 的貢獻會平均分配，結果可能顯示 B Variant 更具優勢。這就說明了選模型前，先確認你想要衡量的是哪一面。

如何挑選最適合的歸因模型？

• 定義 KPI：是想提升新客戶數、提高平均訂單值，還是延長使用者留存？
• 檢視行為路徑：觀察大多數轉化前的關鍵觸點，是否集中於首尾或分散？
• 測試並驗證：在小規模 A/B 測試中，同時套用兩種模型，看哪一個更符合實際業務預期。

小結

歸因模型就像是你行銷旅程中的「評分標準」——不同的標準會得到不同的成績。最重要的是，選擇與你的商業目標、數據情況相符的模型，並在報告中清楚說明為何採用此方法。這樣不僅能讓同仁理解，也能幫你做出更精準的行銷決策。

參考資源

• https://marketingplatform.google.com/about/analytics/attribution/（Google Analytics 歸因說明）
• 《數位行銷歸因模型實務》— 張大偉 著，台灣大學出版社

在這篇文章裡，我們將教你如何把 A/B 測試的數據變成決策者能立刻理解的報告。
透過實例、清單與簡易圖表，你會知道哪些資訊最重要，並學會用故事化語氣呈現結果。

報告結構概覽

一份好的 A/B 測試報告，通常包含這五個核心部份：

• 目標說明：測試想要解決什麼問題？
• 關鍵指標總結：顯示統計顯著性、效益大小。
• 視覺化結果：簡單圖表讓數據一眼看懂。
• 故事敘述：把複雜的統計轉成決策者能共鳴的語言。
• 後續建議：具體可執行的行動項目。

1️⃣ 先說明測試目的

決策者最關心的是「這個變更到底要解決什麼？」

例子：

• 問題：登錄頁面跳轉速度慢，導致流失率升高。
• 假設：將表單欄位數量減少 3 個，可提升完成率。

把這些文字放在報告開頭，決策者就能立即知道測試的核心動機。

2️⃣ 關鍵指標一覽表

用簡單表格快速呈現主要數據：

指標	統計顯著性	效益大小	推薦採取？
轉換率	p < 0.01	+3%	建議推廣
跳出率	p = 0.15	-1%	不建議

表格中只列出最重要的三個指標，避免資訊過載。若有多個變數，可以再做子表或附錄。

3️⃣ 視覺化圖表：簡單線條圖或長條圖

決策者常用「看圖即知」的方式，建議使用兩種直觀圖形：

• 堆疊長條圖：顯示 A 與 B 版本在同一時間點的表現差異。
• 趨勢線圖：若測試持續多日，可展示每日轉換率走勢，觀察是否有波動。

範例（用 Markdown 表格模擬）：

日期	版本 A	版本 B	差異
1 日	4.2%	5.0%	+0.8%
2 日	4.3%	5.1%	+0.8%

如果你真的想顯示圖形，可以將圖片存為外部連結，或使用簡單 ASCII 圖。只要確保能一眼看到「B 超過 A」即可。

4️⃣ 故事化敘述：用比喻與案例說明

把統計語句轉成貼近日常的故事，讓決策者更容易接受。示例：

• 原始語句：A/B 測試顯示版本 B 的完成率提升 3% (p < 0.01)。
• 故事化說法：想像一下，一個人走進商店，原本需要排隊等候 5 分鐘，而現在改成自動結帳機，只要 4 分鐘就能結束。雖然時間差不大，但長期累積下來，每天都能為我們節省數百小時。

透過這樣的比喻，決策者可以馬上感受到改變帶來的實際價值。

5️⃣ 行動建議：具體且可落地

結尾處給出三個「立即可執行」的步驟：

• 部署：在正式環境啟用版本 B，並持續監測前兩週。
• 追蹤指標：每日檢查轉換率和跳出率，確保沒有負面影響。
• 擴大應用：若效果穩定，可考慮在其他頁面複製相同改動。

這樣的建議不僅說明了「做什麼」，還包含「何時、如何」的細節，讓決策者能快速落實。