上次，我們跟大家分享了《A/B 測試中 12 個常見的誤區（上）》，今天繼續來跟大家分享后半部分的內容。

第一次失敗就放棄

你設置了一個測試，但它并沒有提高轉化效率，于是，你就準備在另一個頁面上運行測試嗎？

沒那么快！大多數首次測試都面臨著失敗的可能性。實事求是地講，迭代測試不可避免。通過一項測試，從中學習，并改善你的用戶體驗和你提出來的假設，之后再進行測試，并循環往復，以此類推。

我們曾經研究過一個案例，在同一頁面上做了 6 次測試來實現我們的轉換目的，這就是現實生活中的測試。所以，你必須讓批準測試預算的老板和你的客戶知道這一點。

如果期望一次測試會得到想要的結果，那么資金將被浪費，人員也可能將被解雇。所以，運行迭代測試，才是較為可行的方法。

虛報的顯著性

要知道，統計顯著性并不是唯一要注意的結果。我們還需要了解那些錯誤的測試結果。不耐煩的測試人員希望跳過 A / B 測試并繼續進行 A / B / C / D / E / F / G / H 測試。而這，就是一種誤區。

不可否認的是，測試的版本越多，誤報的可能性就越高。有時候，即使在 95％ 的置信水平下，誤報的幾率仍能達到 88％。

利用重復的流量

你已經找到了一種通過同時運行多個測試來“偷工減料”的方法：一個測試在產品頁面上，一個測試在購物車頁面上，一個測試在主頁上（同時測量相同的目標）。它很節省時間，對嗎？

但如果你在測試的時候不小心，就很可能會扭曲結果。除非你懷疑測試之間存在強烈的交互，且測試之間的流量有很大的重疊。

如果測試之間存在交互和流量重疊，事情會變得棘手。

如果你想同時在同一個流程中測試多個布局的新版本，例如結帳的三個步驟，你最好還是使用多頁面實驗或多變量測試來正確測量交互和屬性結果。

如果你決定使用重疊流量運行 A / B 測試，請記住流量應始終均勻分配。如果測試產品頁面 A 與 B，和結帳頁面 C 與 D，請確保來自 B 的流量在 C 和 D 之間的分配是對半的，而不是 2：3 或其他。

忽略細微的成果

你的新版本比對照組高出了 4%，但總有人會說“這個比例太小了！我甚至都不愿意實施它?！?/p>

但問題是，如果你的網站做的非常好，那么你將無法獲得那樣大規模的轉化提升，而事實上，大規模的轉化提升也非常罕見。除非你的網站很垃圾，測試之后很容易獲得 50％ 以上的轉化提升，但即使這樣，這種場景也不會持續不斷地出現。

大多數測試帶來的都是小幅增長，比如 1％、5％、8％等。有時，1％ 的提升可能意味著數百萬的收入，但重點是：你需要從 12 個月的時間跨度來看待它。

一項測試就只是一項測試，你必須要做很多很多測試。比如你每月將轉化率提高 5％，那么 12 個月內的轉化率將提高 80％，這是復利，是數學的工作原理。而 80% 將是一個極其壯觀的數字。

所以，要學會積累這些小勝利，最后將他們都疊加起來。

拒絕垃圾測試

沒有測試的每一天都是一種浪費。測試是為了更好的學習，更好的了解你的受眾，了解哪些有效，以及有效的原因。

不進行多次測試的話，你就不知道什么是有效的。

雖然要不停地進行測試，但絕不代表你要進行垃圾測試。你需要做適當的研究，準備一個很好的假設，并且不斷優化。

意識不到存在的威脅

僅僅因為你有一個不錯的樣本量，置信度和測試持續時間并不意味著你的測試結果是有效的。因為你的測試往往還具備著以下幾個威脅。

工具誤差

這是最常見的問題。當測試工具（或儀器）在測試中出現有缺陷的數據時，會對結果產生致命的影響，而這通常是因為網站上的錯誤代碼，所以你需要注意這一點。

設置測試時，請觀察并記錄的每個目標和對應的數據指標。一旦出現問題，請停止測試，找到并修復問題，然后重新設置數據，重新開始。

歷史效應

也可能是外部世界發生了一些事情，導致測試中存在缺陷數據的情況發生。比如你的公司高管爆發了丑聞，或者正巧碰上消費的假日季節等等，外部正在發生的事情都會引起你的變化。

選擇偏差

當我們錯誤的假設流量的某些部分代表流量總體時，就會發生這種情況。

例如，你將促銷流量從電子郵件列表發送到你正在運行測試的頁面，那么訂閱你的列表的人就會比普通訪問者更多。但如果認為他們代表總流量，那么就會有選擇偏差的情況出現。

錯誤的代碼效應

你測試出了一套提高轉化率的方法并將其推向現實，但是，它沒有贏得該有的效果。這可能是因為你的這套方法在某些瀏覽器或設備上顯示效果不佳。

每當你提出新方案時，請確保進行質量保證測試，以確保它們在所有瀏覽器和設備中都可以正確顯示。

尾 聲：希望你能從這 12 個誤區中獲得一些思考，在以后的 A/B 測試中，避開這些“坑”。

原文來源：https://conversionxl.com

原文作者：Peep Laja

翻譯：研如玉，神策數據·用戶行為洞察研究院 公眾號（ID：SDResearch）

本文由 @研如玉 翻譯發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議