Landing Page A/B Test 指南：假設、樣本、GA4 與 15 項驗收

直接答案：Landing Page A/B Test 是把訪客隨機分到控制版本 A 與一個主要變化版本 B，在同一時段用預先定義的轉化指標比較。正確流程不是「改完看轉化率高低」，而是先寫假設、鎖定一個主要變數、確認追蹤與樣本、同時分流、監察風險，再按統計與商業價值決定採用、重測或放棄。流量很少的香港中小企未必適合立即做正式 A/B Test；先修正明顯錯誤、做訪談與可用性測試，通常更快得到可靠方向。

Landing Page A/B Test 是甚麼？

Google Analytics 把 A/B Test 定義為同一網頁兩個或以上版本的隨機實驗：A 是原版，B 至 n 至少有一項差異，各版本同時展示給隨機樣本，目的是判斷哪個版本較能達成指定目標。GA4 可分析實驗結果，但目前要配合第三方實驗工具或自建分流，不能把 GA4 報告本身當作分流工具。

A/B Test 與「今個月改標題、下個月比較」不同。前後比較容易受渠道、預算、節日、競爭、裝置、價格、庫存及銷售跟進改變影響；隨機而同期的實驗，才較有機會把差異歸因到指定變數。

甚麼情況應做、甚麼情況不應做？

第一步：把意見改寫成可驗證假設

一個完整假設包括「對哪類訪客、改甚麼、因為甚麼障礙、預期改善哪個行為、甚麼結果會令團隊採用」。例如：

對由高意圖搜尋廣告進入服務頁的香港企業訪客，把首屏 CTA 由「了解更多」改為「預約 20 分鐘需求評估」，並在旁列出適合對象及不保證成效，預期會提高合資格預約率；若只增加誤按或低質查詢便不採用。

「紅色按鈕會更好」只有變化，沒有用戶問題及商業判準。假設來源可包括搜尋字詞、客服紀錄、CRM 拒絕原因、表單退出、裝置問題、銷售訪談及用戶測試。可先用Landing Page 服務與轉化框架建立頁面角色，再以數據決定優先。

一次可以測多少項？

中小企大部分情況每次只測一個主要概念，例如 Offer、首屏訊息、證據次序、表單摩擦或 CTA。版本 B 可以為了完整呈現同一概念而同步調整相關文案，但必須記錄這是一個「訊息組合」測試，不能事後聲稱某個字或顏色單獨造成結果。

多變量測試同時組合多個元素，需要更多流量及更複雜分析。若樣本不足，結果只會被分散到大量組合。與其測十個微小變化，不如先選一個會改變用戶理解或決策的高影響假設。

應選哪個主要指標？

主要指標最好只設一個；護欄指標用來防止局部提升傷害整體。GA4 的 event 可量度載入、click、表單提交或購買等互動，但「前端顯示成功」不一定等於後端收到、CRM 建檔或訂單付款成功。重要轉化應用 transaction ID、lead ID 或可核對紀錄去重及對數。

測試前如何驗證 GA4 與轉化追蹤？

1. 為 experiment、variant、page type、traffic source 及主要 event 定義名稱。
2. 用 Tag Manager Preview／測試環境逐步觸發 A、B 版本，核對 event 只發一次。
3. 確認同意狀態、跨網域、付款／預約第三方頁、redirect 及手機瀏覽器。
4. 核對 GA4 DebugView／即時資料、後端提交、CRM 及付款紀錄。
5. 先跑 A/A Test 或短期 instrumentation QA，檢查兩組在沒有實質差異時會否異常分開。
6. 記錄資料延遲、排除規則、內部流量、bot、退款及重複提交處理。

UTM、渠道及活動命名應先用UTM 與 GA4 命名指南統一；不要在實驗期間臨時改 attribution 或 key event 定義。

如何估算樣本量及測試時間？

開始前最少要有基準轉化率、希望偵測的最小實際改善（minimum detectable effect）、顯著水平、檢定力、版本數及每週合資格流量。基準越低、希望偵測的差異越小，所需樣本通常越大。不能以「跑七日」或「每版 100 人」作所有網站的通用規則。

例如基準是 4%，團隊只會在提升至 4.2% 時採用，所需樣本遠高於只要求偵測 4% 至 6%。先問 0.2 個百分點是否足以抵銷工具、開發、風險及營運成本；若不是，應把最小實際改善設得更符合商業決策。

估算後再檢查正常流量需要多少完整週期。測試應覆蓋平日／週末及主要營運週期，但不應因結果未如預期而無限延長。低流量頁可以測更大的訊息變化、合併相近頁型（前提是用戶與轉化邏輯相同），或改用定性研究。

為何不能見到 95% 或暫時領先就停？

每日反覆查看再在喜歡的時點停止，會增加假陽性風險；早段大幅領先亦可能只是少量轉化波動。應在開始前決定固定樣本／時間或使用支援 sequential testing 的方法，並遵守工具設計。不要一時用頻率學派 p-value、一時用 Bayesian probability，再挑較好看的結論。

「統計顯著」亦不等於值得推出。團隊還要看效果區間、絕對提升、合資格 Lead、收入、毛利、裝置／渠道一致性、實作成本與風險。一個由 1.00% 到 1.05% 的結果即使可檢出，也可能沒有商業價值。

實驗分流要如何設計？

• 隨機：合資格訪客應有已知機會進入 A 或 B，不能由銷售人員揀選。
• 一致：同一人回訪時盡量保持原版本，避免跨版本污染。
• 同期：A、B 同時運行，並使用相同渠道與資格規則。
• 互斥：避免同一訪客同時進入多個會互相影響的頁面實驗。
• 可追蹤：保存 experiment ID、variant、assignment time、release 及錯誤。
• 可回復：出現付款、表單、速度或合規問題時可立即停止及還原。

以 cookie、local storage 或帳戶 ID 保持版本時，要考慮拒絕 cookie、跨裝置、刪除資料及登入前後變化。不能把不完整的 visitor count 當精確獨立人數。

A/B Test 對 SEO 有甚麼影響？

Google Search Central 建議不要向 Googlebot 與人類顯示刻意不同內容，否則可能構成 cloaking。若每個版本有獨立 URL，替代版本應指向原始偏好 URL 的 rel="canonical"；分流 redirect 應用暫時性的 302 而非 301。實驗完結後應盡快移除替代 URL、redirect、script 及標記。

小型按鈕或 CTA 變化通常不會明顯改變搜尋摘要，但大幅改標題、主內容、內鏈或結構時要額外監察 crawl、canonical、indexing、Core Web Vitals 及搜尋表現。不能只對 Googlebot 固定顯示「SEO 版本」。

速度與版面跳動會否扭曲結果？

會。第三方測試 script、延遲替換內容及閃爍（flicker）可令 B 版較慢，或讓訪客先看 A 再跳到 B。這既影響體驗，也把「訊息效果」與「技術成本」混在一起。

1. 發布前比較 A／B 的 mobile LCP、INP、CLS、JS error 及資源大小。
2. 在慢速網絡、低階手機、Safari／Chrome 及 in-app browser 測試。
3. 不要長時間隱藏整頁等待實驗 script。
4. 把 variant assignment 儘量提早而穩定地完成。
5. 結果報告同時列出轉化與體驗差異。

速度檢查可配合網站速度優化指南及Landing Page 速度指南（廣告漏斗、CWV 與 15 項驗收），分開核對整站效能、單一實驗版本的 LCP／INP／CLS，以及真實用戶 field data 與單次 lab 測試。

私隱與資料治理要注意甚麼？

實驗可能使用 cookie、裝置識別、行為事件、表單及 CRM 資料。香港個人資料私隱專員公署的網上追蹤指引要求機構了解所用追蹤工具、提高透明度、提供合適選擇、實施 privacy by design、管理第三方及保護資料。實際要求應按資料、地區、供應商及法律意見核對。

• 列出實驗工具、tag、cookie、用途、保存期、第三方及資料地區；
• 只收集判斷實驗所需欄位，避免把敏感表單內容放入 event 參數或 URL；
• 尊重同意／拒絕機制，記錄拒絕追蹤對樣本的限制；
• 限制 dashboard、raw export、CRM join 及供應商帳戶權限；
• 實驗結束後按政策刪除不再需要的 user-level assignment 資料。

結果應如何分成「贏、輸、無結論」？

香港中小企可先測哪 8 類假設？

1. 價值主張：由服務名稱改為具體問題、對象與結果範圍。
2. 資格訊息：清楚列適合／不適合對象、地區、預算或時間要求。
3. Offer：報價改為評估、示範、診斷或可交付的下一步。
4. 證據：把案例方法、客戶類型、流程或限制移近決策位置。
5. CTA：由模糊「提交」改為說明會發生甚麼及需時。
6. 表單：減少非必要欄位，或加入真正有助資格判斷的問題。
7. 風險消除：清楚列回覆時間、資料用途、費用邊界及不保證事項。
8. 承接一致：讓廣告／搜尋意圖、首屏、表單及銷售回覆使用相同承諾。

表單實作要同時考慮完成率與 Lead 質素，可參考網站表單設計指南；CTA 則不應用假倒數、隱藏費用或誤導按鈕製造短期提升。

14 日準備與執行流程

1. 第 1–2 日：定義頁面任務、主要轉化、基準、商業價值與護欄。
2. 第 3 日：整合搜尋、廣告、行為、CRM、客服及用戶研究，列出障礙。
3. 第 4 日：按 impact、evidence、effort、risk 排假設，只選一個。
4. 第 5 日：預先寫實驗名稱、版本、受眾、主要指標、MDE、停止與排除規則。
5. 第 6–7 日：設計 B 版及 rollback，完成內容、無障礙、私隱與品牌審閱。
6. 第 8–9 日：配置分流、GA4 event、variant 欄位、後端／CRM 對數。
7. 第 10 日：跨裝置 QA、A/A 或 instrumentation check、速度及錯誤測試。
8. 第 11 日：小比例啟動，只檢查資料與風險，不判勝負。
9. 第 12–13 日：擴至預定分流，監察 sample ratio、錯誤及護欄。
10. 第 14 日起：按預設樣本／週期運行；結束後記錄結果、限制、決策與 rollout。

15 項 Landing Page A/B Test 驗收清單

1. 有一個清楚用戶問題、證據來源及可被否證的假設。
2. A 是現有控制組；B 的主要概念及所有連帶改動已記錄。
3. 主要指標只有一個，並連到合資格 Lead、預約、收入或真正頁面任務。
4. 護欄包括錯誤、速度、Lead 質素、退款或其他重要副作用。
5. 基準、MDE、顯著水平／方法、檢定力、樣本及時間在開始前寫定。
6. 訪客隨機、同期、盡量固定版本，並有實驗互斥規則。
7. experiment ID、variant、assignment 及主要 event 能在 GA4／資料層核對。
8. 前端成功、後端接收、CRM／付款紀錄及去重已測試。
9. A／B 的渠道、裝置、地區、價格、庫存及銷售跟進沒有未記錄差異。
10. 手機、瀏覽器、in-app browser、表單、付款、redirect 及錯誤路徑已 QA。
11. LCP、INP、CLS、flicker、JS error 及第三方 script 影響已比較。
12. 多 URL 測試有 canonical 與 302；沒有向 Googlebot 顯示特製版本。
13. 追蹤用途、cookie、同意、敏感資料、權限、供應商及保存期已審閱。
14. 有停止、暫停、rollback、事故 owner 及版本回復方法。
15. 報告同時列絕對數、率、效果區間、護欄、限制、決策及 rollout 驗收。

常見問題

測試一定要 50/50 分流嗎？

不一定。50/50 通常較快累積兩組資料；高風險改動可先小比例做安全檢查，但正式分析要按實際分配及工具方法。不能因 B 暫時落後便臨時改流量再照原方法判讀。

可以同時測標題、圖片和 CTA 嗎？

可以把它們視為一個完整訊息概念，但結果只能支持「整個組合」較好或較差。若要知道每個元素的獨立影響，需要足夠樣本與相應實驗設計。

沒有統計顯著是否代表兩版一樣？

不是。可能是差異很小，也可能只是樣本不足、波動大或追蹤有問題。應看效果區間是否已排除團隊關心的最小實際差異。

GA4 可否直接建立 A/B Test？

GA4 可用來分析 event 與結果，但 Google 官方現時說明要整合第三方 A/B testing 工具來運行及管理實驗。

測試贏了是否可立即永久推出？

先完整部署、移除實驗邏輯，再監察一個正常營運週期。實驗環境與 rollout 後的渠道、速度、銷售流程或季節可能不同，勝出不等於永久保證。

官方／第一方參考：Google Analytics：A/B Test 定義與第三方工具整合、GA4 events、Google Search Central：網站測試與 SEO、web.dev：Core Web Vitals及香港私隱專員公署：網上追蹤活動指引。

編輯與審閱：ITOB Group 編輯團隊；由ITOB Group 數碼營銷顧問團隊審閱。最後實質內容更新：2026 年 7 月 21 日；Google 文件與內部連結最後核對：2026 年 10 月 5 日。

本文按 Google、web.dev、香港個人資料私隱專員公署官方資料及 ITOB Group 的 Landing Page、分析、CRM 與驗收方法整理，不構成統計、法律、私隱或特定工具意見，亦不保證轉化、查詢、成交、收入、排名或 AI 引用。實驗結果受樣本、渠道、季節、裝置、網站、工具、同意、銷售跟進及市場影響；執行前應保存基準、假設、版本、權限、資料用途、停止規則及回復方法。詳見編輯政策與資料更正原則。