網站 A/B 測試入門：從假設、單一變因到判讀結果的實作指南

行銷會議上常出現這樣的爭論：「首頁主標應該強調價格實惠還是服務專業？」「按鈕用綠色還是橘色？」「表單要不要拿掉電話欄位？」每個人都有理由，最後通常由職位最高的人決定。改了之後，詢問量有變化，但沒人說得清楚是因為改版，還是剛好遇到旺季。

網站 A/B 測試就是用來解決這種爭論的方法：同一段時間，把訪客隨機分成兩組，一組看原本的版本，一組看修改後的版本，比較兩組的行為差異。因為兩組在同一時間、面對同樣的外部環境，差異才比較能歸因到你改的那個地方。

但 A/B 測試做錯的代價不小：一個看起來「贏了」的結果，可能只是運氣或判讀錯誤，照著改反而變差。這篇說明怎麼從假設開始、為什麼一次只改一件事、流量不夠時怎麼辦、什麼時候該停止，以及最常見的誤判。

開始前的前提：追蹤要先正確

A/B 測試比較的是數據，數據錯了，結論就錯了。在設計任何測試之前，先確認三件事：

1. 轉換有被正確記錄：你在意的行為，例如送出詢問表單、點擊電話、完成購買，都有設定成事件並實際測試過會觸發。設定方式可以參考GA4 設定指南。
2. 不會重複計算：同一個人重新整理頁面、按兩次送出，不會被算成兩次轉換。
3. 網站本身沒有明顯問題：頁面載入很慢、手機版跑版、表單常常送不出去，這些應該直接修，不需要測試。速度問題可以先看網站速度與 Core Web Vitals 指南。

A/B 測試適合用在「兩種做法都合理，不確定哪個比較好」的情況，而不是用來證明一個明顯的錯誤是錯誤。

第一步：先寫假設，再決定要改什麼

很多 A/B 測試的問題，是從「我們來測看看綠色按鈕」開始的。沒有假設的測試，即使有結果，也不知道為什麼，更無法延伸到下一次。

一個好的假設包含三個部分：

因為〔觀察到的現象〕，我們認為〔做某個改變〕會讓〔某類訪客〕更容易〔做某個行為〕。我們會看〔哪個指標〕來判斷。

舉例：

因為客服常被問「需不需要先付訂金」，我們認為在報名按鈕旁加上「免訂金、可先諮詢」的說明，會讓第一次來訪的訪客更願意送出諮詢表單。我們會看諮詢表單送出率來判斷。

假設從哪裡來：

• 客服與業務最常被問的問題。
• 網站分析中流失最多的頁面或步驟。
• 使用者訪談或操作觀察中，大家猶豫最久的地方。
• 表單中最常被留空或填錯的欄位。

寫假設的另一個好處是：測試前團隊就同意要看哪個指標。這能避免測完之後，在一堆數字中挑一個對自己有利的來解讀。

第二步：一次只改一件事

如果新版本同時換了標題、圖片、按鈕顏色和表單欄位，結果變好了，你也不知道是哪一個改動造成的；結果變差了，更不知道該退回哪一個。

一次只改一件事的意思：

• 兩個版本之間只有一個「概念」上的差異。例如「強調價格」對「強調專業」，可以同時改標題與副標，只要它們服務同一個概念。
• 不要把無關的調整混在一起，例如順便修改頁尾、換圖片尺寸。
• 測試期間不要修改網站其他會影響該頁面的地方，例如同時開始一檔大型廣告只導向其中一個版本。

常見的測試主題（依通常影響程度排列，僅供參考）：

1. 價值主張：首屏主標與副標在講什麼。
2. 行動呼籲：按鈕的文字與位置，以及旁邊有沒有消除疑慮的說明。
3. 表單：欄位數量、必填與選填、分成幾步。
4. 信任元素：服務流程、常見問題、聯絡方式擺放的位置。
5. 版面細節：顏色、圖片、間距。

越上面的項目，越可能真的影響決策；越下面的項目，通常需要很大的流量才看得出差異。流量有限時，優先測上面的。

第三步：決定樣本量與測試期間，並在開始前寫下來

A/B 測試最容易出錯的地方，就是「看起來差異出現了就停」。為了避免這個問題，開始前先決定：

• 要看的主要指標：只能有一個，其他都是參考。
• 需要多少樣本：可以用測試工具內建的樣本量計算機，輸入目前的轉換率與你希望偵測到的最小差異，得出每組需要的訪客數。你希望偵測的差異越小，需要的樣本越多。
• 測試期間：至少涵蓋完整的週間循環，因為平日與週末的訪客行為常常不同。如果業務有明顯的月初月底差異，期間也要考慮進去。
• 分流方式：訪客隨機分配，而且同一位訪客再次造訪時要看到同一版本。

把這些寫在一份簡單的測試紀錄裡，測試結束時拿出來對照。

流量不足時的替代做法

很多中小企業網站的流量，並不足以在合理時間內得到可靠的 A/B 測試結果。硬做的結果，常是測了很久仍然看不出差異，或被少數幾筆轉換左右結論。這時可以考慮以下做法：

改測離轉換更近、發生更頻繁的行為

如果最終轉換（送出表單）太少，可以改看前一步，例如點擊「立即諮詢」按鈕的比例。要注意前一步變多不保證最終轉換變多，結論要保守。

只測影響大的改動

小幅修改需要大量樣本才看得出來，大幅改動的差異比較容易顯現。例如整個首屏的訴求方向不同，比按鈕顏色更適合小流量網站。

使用者測試與訪談

找幾位符合目標客群的人，請他們在你面前操作網站完成某個任務，觀察他們在哪裡猶豫、說了什麼。人數不用多，往往就能發現明顯的卡點。這不是統計證據，但非常適合找出值得改的地方。

行為紀錄工具

熱點圖與操作錄影可以看到訪客實際點了哪裡、捲到哪裡、在哪裡離開。使用時要留意隱私設定，遮蔽表單輸入內容，並在隱私權政策中說明。

前後比較，但要誠實標註限制

改版前後各取一段相同長度、條件相近的期間比較。這種做法容易受季節、廣告、競爭等外部因素影響，結論只能當作參考，不能宣稱是改版造成的。

何時停止測試：三種結束方式

依計畫結束：達到事先設定的樣本量與期間，再看結果。這是最理想的情況。

提前停止：只有在出現明顯問題時，例如新版本有錯誤導致無法送出表單、或嚴重影響營運，才應該提前停。不要因為某一版「看起來領先」就提前結束，這是最常見的誤判來源。

延長或放棄：期間到了仍然沒有足夠樣本，可以延長一次；若延長後依然不足，代表這個測試不適合目前的流量，改用上一段的替代做法，而不是無限期掛著。

結束後的步驟：

1. 對照測試前寫下的假設與主要指標判讀結果。
2. 檢查兩組的訪客組成是否大致相同，例如裝置、來源比例。
3. 決定採用哪個版本，正式上線並移除測試程式碼。
4. 把假設、結果與判斷寫進測試紀錄，包括沒有差異的結果。

常見誤判：數字看起來對，結論卻是錯的

偷看結果並提前喊停

每天看一次數據，一看到某版領先就結束。測試初期樣本少，結果本來就會大幅擺盪，這時停下來，等於挑了一個剛好對某版有利的時間點。對策是事先決定期間與樣本量，期間內只檢查有沒有技術問題。

同時看很多指標，挑贏的那個

主要指標沒差，但「頁面停留時間」比較好，就宣布新版勝出。看的指標越多，總會有一個剛好看起來有差異。對策是只用事先決定的主要指標下結論，其他指標當作觀察。

樣本中混入異常流量

測試期間剛好有一波機器人流量、內部同仁大量瀏覽，或某個廣告只帶到其中一版。對策是排除內部 IP 與已知的異常來源，並檢查兩組流量來源是否平均。

把短期新鮮感當成效果

改版初期，老訪客可能因為好奇而多點了幾下，過一陣子就恢復原狀。對策是測試期間不要太短，必要時把新舊訪客分開看。

分組結果互相矛盾時只挑一組講

整體沒差異，但手機版新版表現較好、桌機版較差。這時不能只報告手機版。對策是如果事先就預期裝置會有差異，應該在測試設計時分開規劃；事後才發現的分組差異，只能當作下一個測試的假設。

測試工具本身影響了體驗

有些測試工具在頁面載入時才切換內容，訪客會看到原版閃一下再變成新版，這本身就會影響行為。上線測試前，用手機與較慢的網路實際看一次。

一份可以直接用的測試紀錄範本

每次測試都填一份，累積下來就是團隊對網站訪客的理解：

欄位	內容
測試名稱與編號
假設	因為〔現象〕，我們認為〔改變〕會讓〔對象〕更容易〔行為〕
測試頁面與版本差異	原版：／新版：
主要指標	只寫一個
參考指標
預計樣本量與期間	開始日、預計結束日
排除的流量	內部 IP、特定來源
結果	主要指標的比較，以及是否達到事先設定的條件
決定	採用新版／維持原版／延長／放棄
學到什麼	下一個假設是什麼

結語：A/B 測試是用來學習，不是用來證明自己對

A/B 測試真正的價值，不在某一次測出贏家，而在讓團隊養成「先有假設、再用資料檢驗」的習慣。追蹤先做對、一次只改一件事、事先決定要看什麼與看多久、流量不夠就換方法，就能避免被看似漂亮的數字誤導。

NETVANA 可以協助你把網站的轉換追蹤設定正確、從現有資料與訪客行為中整理出值得測試的假設，並在網站程式中實作分流、測試版本與結束後的清理，讓測試不拖慢頁面也不影響搜尋表現。軟體服務一律採詢問報價制，我們會先檢視網站現況與流量條件，再建議適合的測試方式，歡迎與我們聯絡，或先看軟體服務介紹。

延伸閱讀：測試前要先把追蹤設定好，看GA4 設定指南；頁面速度會影響測試結果，看網站速度與 Core Web Vitals 指南；改版上線前的檢查事項，看網站上線前檢查清單；想用最小範圍先驗證產品方向，看MVP 開發指南。