為什麼國內網站很少做 A/B 測試？
為什麼這件很靠譜的事，在國內沒有大範圍的應用，往往被當做談資呢？
是說網站的a/b測試，不是apache那個哈...
http://baike.baidu.com/view/4357479.htm
謝邀 
事實上據我所知，還是有不少公司在做 A/B test 的（當然，可能每個人對「多、少」的心理定位不一樣）。但是不得不承認，依然有非常多的公司不做，或者做了沒效果，或者曾經做過但之後取消了，或者正在邊做邊疑惑著……謹此將我的所見所聞略做梳理。
A/B test 之所以沒鋪開，從面兒上來講有這幾個原因：
a、很可能不知道怎麼做
b、做了卻無法正確評估
c、評了又未必能好好利用
d、用了不一定能收到效果
然後再往裡翻翻， 我們會發現這些常見迷局：
一、產品（或流程、模塊、功能等）設計思想壁壘
二、（數據）分析壁壘
三、技術壁壘
四、「落地」的層層障礙
p.s. 由於題主原題是「為什麼國內網站很少做a/b測試」，所以這裡只分析此現象的成因，不討論 A/B test 到底應該怎麼做。於是，以下內容皆為口水，嫌羅嗦的話，請直接略過便好:)
==== ==== ==== ==== 為大口水割一下吧 ==== ==== ==== ====
詳述：
一、測試設計（產品、流程、模塊或功能等）思路壁壘
1.1、A/B test 是個神馬玩意兒？
A/B test 一般是由產品、運營部門發起或主導的，但恕我直言，至少在我接觸到的案例中，有相當比例的相關人員，並不十分清楚這兩個問題：「為什麼要做 A/B test？」「A/B test 能帶來什麼，在什麼情況下需要做？」而基於眾所周知的邏輯關係，如果動手前連自己將要做的這是件啥樣的事兒都不知道，能成功、能做好的概率又能有多大呢？
1.2、OK，我知道這是啥了。誰能告訴我怎麼做，A 跟 B 之間到底差多少？
我這兒有個真實案例，某童鞋做了很久的 A/B test，一直沒得出有意義的東西來，然後我們順頭一捊，居然發現這孩子設置的 A、B 版頁面分別是……你們猜？是網站首頁跟某頻道分類頁。
再恕我直言，有相當多的執行者心裡沒有這張譜：A/B test 的兩個頁面，到底應該差多少？我是拿新、舊版頁面直接當 A、B，還是在原有的 A 頁面基礎上修改某一個小模塊來成為 B？什麼是多變數測試？
1.3、會不會對我的XXX（SEO、流程、用戶體驗……）造成影響，影響有多大？
對業務或相關用戶的影響，一般來說或多或少是會有的，尤其當採用了不適當的跳轉方式（技術相關的話題下面再議）時，極有可能對搜索引擎（或用戶）帶來負面影響。
而到底影響有多大這個問題，我想偷換概念聊一下ROI。A/B test 的最終目的是什麼？以某些看似公開公平公正的測試來評估或確定將被執行的方案。成本主要有：開發成本、測試周期（時間成本）、對用戶可能存在的傷害；收益主要有：方案/決策的確立、減免反覆試錯成本、降低內耗成本（可能）、對轉化或收益預期的非拍腦袋參考。A/B test 絕非神物，個人認為其最常見的作用是避免團隊陷入集體選擇性障礙。做不做？可以參考以上 ROI。
二、（數據）分析壁壘
2.1、兩個（或更多）版本的數據怎麼收集/整理？
單單區分不同版本頁面本身的數據非常簡單，但如何對最終達成的轉化根據不同入口及流經頁面進行歸因，進而分析相關參測版本頁面（或元素）的表現，這就是一件擾人的事兒。而不同的歸因方式甚至可能牽扯到幾個部門的利益：投放渠道評價、入口資源的爭奪，甚至跟某些KPI遙相呼應。那這個標準誰定，怎麼定，本身就是一場戰爭。
2.2、數字（或比例）越大，就一定說明表現越好嗎？
看 A/B test 反饋數據的人，並不全是專職的數據分析師，甚至包括一小部分經驗略淺的數據分析師，都非常容易想當然地跳進這個誤區。上面我說過，A/B test 絕非神物，但更可怕的是它被誤讀、被曲解，再被神化。非常遺憾的是，基於各種需要、背景或局限，這樣的例子多如恆河沙數。
2.3、訪問（者）為什麼沒有均分，那數據是不是不準（不能用）了？
樣本量、分配規則、數據監測或萃取方式（條件）……很多時候，由於各種各樣的原因，我們會發現真實數據並不如預期般在各版本中均攤。「幾個版本數據差距好大啊，怎麼辦，能信嗎？」 如何校準，是否需要排錯，有沒有相應的調整策略，數據的信效度衡量……這些也並不是所有拿到報表的人都能 Hold 住的。
三、技術壁壘
3.1、開什麼玩笑，我們也不是小公司，會存在技術問題？
抱歉，我並沒有任何玩笑或者不敬的意思，事實上不論公司的規模或真實技術實力如何，會中這一槍的並非只有菜鳥。任何公司的資源都是有限的，任何一份投入都會耗費相應的成本，雖然架構 A/B test 所需的技術事實上相當簡單，但真正能撲上去用心做好的公司，都可謂英雄。流量分配規則、跳轉/切換方式（各種跳轉 URL 的方式，或同一 URL 下動態切換模塊）、是否記錄（如 Cookie）單個用戶首次顯示狀態……這些都會影響到測試效果及最終得到的結果。
在這裡我想舉個栗子，Google Analytics 從很早之前就提供了現成的 A/B test 工具，只需在原始版頁面頂部嵌入一段現成提供的代碼，並在這個工具中設定 A、B 版頁面路徑，即可完成設置開始測試。但如此便利的東西，無法正確操作的公司依然比比皆是。實施的人不懂技術，技術嫌麻煩或擔心對伺服器有影響或對安全有隱患或不屑於吃別人嚼過的饃，事情又已經攤下來了，等排期要一個月，怎麼辦？要不硬著頭皮先自己搗鼓個？對了錯了天知道，反正先交差吧！
3.2、數據收集技術
忽然發現我這個答案真是得罪一批又一批啊……哇咧個喵哈哈哈。這不，又說到這個一梭子掃倒一大片的了。現成的第三方工具不好用或者不會用或者總感覺數據被別人掌握了心裡橫豎就是不爽，自己開發又費時費力還不得要領。現在某些公司（尤其是某些背靠或依附國字頭、壟斷者的）出於數據機密性，而不得不自己開發數據分析平台，但……好吧為了略微少得罪幾個人，我還是閹了吧。
其實就整個數據分析鏈條來說，「數據收集」相對應該算是最基本、最先鋒的環節。（線上）常見的數據來源主要就這麼幾種：Page Tagging / Server Log / Third Party，每種來源，或者說每種收集方法，均有其利弊，以目前人類的技術來說都達不到真正的「精準」。如何部署，如何取長補短采陽補陰，如何跨平台甚至跨線上線下，不同監測平台如何統一介面削校數據……
3.3、數據清洗（細分、過濾、歸因、演算法……）技術
到數據清洗這兒，已經沒什麼可深聊的了。舉個栗子吧：了解WA工具的朋友可以自行比對一下國內、外較成名的幾款工具，在數據細分系統上的懸殊差距便知。
四、「落地」的層層障礙
任何數據、任何策劃只有落到執行上，才可能有意義。
4.1、信
a、相信——to "B" or not to "B", it"s a single answer
b、威信——合作 內耗
c、迷信——有時我們需要信仰，而信仰往往需要一件迷信的外衣。扒與不扒，您看著辦
4.2、省
a、自省——擠痘痘會痛，有時還會很痛，敢於直面疤痕的痘主兒都是英雄
b、省悟——讀書百遍，其義自現；有則改之，無則加勉
4.3、行
a、action
b、持續永動——是的，這不是物理題，但你確實需要搗鼓一台永動機
a、抉擇——割肉是痛的，尤其是割掉一塊看起來如此之好的肉
b、實施——攻城獅們最了解
c、秋處——胡蘿蔔與棒子
其實有很多公司或者網站都默默地在做，只是用戶很少發現而已，而且A/B測試的一般原則是對同一個用戶（一般控制cookie）展現同一版本，所以一般情況下不易發現，尤其是細節的測試，如果產品開發快速迭代的話，可能一個測試很快就完成下線了。
用A/B Test驅動產品開發就和敏捷開發當中的TDD(測試驅動開發)一樣，看著是很好的，但門檻是很高的，要求整個團隊從管理，協作，設計，開發和運營各個流程全部緊密協作，磨合良好，如果團隊的素質達不到很高的水平，就根本執行不下去。
慣例先安利：http://www.appadhoc.com
做A/B測試最難的其實是工具與效率問題，我們正為此而努力。
這個講的已經很好了，全文引用，侵刪
本文轉載自：微信公眾號：前端早讀課
在互聯網行業裡面工作，能給我帶來的一個樂趣就是「快」。天下武功，唯快不破。我們可以輕易地做到一天三次以上的產品更新速度，這是和許多傳統行業的區別之一。如何利用好這個優勢，在我眼裡成為了產品發展的關鍵所在。
什麼是A/B測試？
在快速上線的過程中，A/B測試是一個幫助我們快速試錯的一種實驗的方法。在統計學上，其實是Hypothesis Testing（假設測試）的一種形式。它能夠幫我們了解我們對產品的改動，例如一個新的功能，是否能夠吸引更多用戶、讓用戶更加喜歡、產生更大的效益等。
A/B測試方法的基本概括就是，將用戶分為兩組，一組使用舊產品（或舊功能），一組使用新的。然後對比兩個用戶組，通過數據來分析，新的功能究竟是好是壞。沒錯，就跟小學的時候做的那些有控制組、實驗組的自然科學實驗一樣一樣的。
A/B測試的具體實施方式有很多種。桌面應用、網站、手機應用都有一些不同的A/B測試方法。本文中以網站的A/B測試為例來介紹。
我們以天貓的購物車為例，現在的天貓購物車中，結算按鈕是在最下方的。這裡我瀏覽器窗口的高度弄得比較小，所以看起來結算按鈕和物品之間距離很近，但是實際上他們之間是有很大的距離的。
現在我就可以提出一個想法，讓我們試著把結算按鈕移動到購物車的最上方，或許可以增加這個結算按鈕的點擊穿透率（CTR，ClickThrough Rate），從而可能提高轉化率（CR，Conversion Rate）。
小知識題外話：CTR簡單說即點擊該結算按鈕的次數占該頁面的總訪問次數的百分比。例如，在2014年10月25日這一天，一共有200萬人打開了這個購物車的頁面，其中有20萬人點擊「結算」並成功到達了結算頁面，那麼這一天該按鈕的CTR即為20萬/200萬乘以100%，即10%。
CR，簡單來說就是實際進行了消費活動的顧客佔總訪客數量的百分比。現在，我們就有了兩個版本的購物車。一個是現有版本，我們稱之為A；一個是我新設計的版本，我們稱之為B。我們的目標是想要知道，B的效果是否比A來得好。
那麼，為了衡量效果，我們就要明確我們要觀測的數據。這裡，我們選擇CTR和CR作為我們的觀測數據。如果新設計上線後，這兩個數據如果有上升，那麼就代表著這個新的設計是一個很好的改進。
按用戶（流量）劃分控制組和實驗組
接下來我們將用戶劃分成用戶組和實驗組。按用戶分組也稱作按流量分組。例如，我們可以讓50%來到天貓的用戶看到舊的設計，另外50%來到天貓的用戶看到新的設計。
需要注意的是，我們必須盡量保證同一個用戶在實驗期間所能看到的是同一個設計。如果他剛才看到的結算按鈕在下面，現在又看到結算按鈕在上面了，那麼對他而言一定是一件很困惑的事情。
小知識：劃分組的過程由伺服器的特定演算法完成，這類演算法我們一般稱之為分桶演算法（Bucketing Algorithm）。分桶也就是分組，是一個概念。對網站請求進行分桶的那部分程序叫做請求分桶（Request Bucketer）。
按頁面劃分控制組和實驗組
有的時候，按照用戶分組會存在一些問題。例如，如果你的實驗是關於搜索引擎優化（SEO）的，那麼可能就需要按照頁面來劃分控制組和實驗組。例如，對於50%的購物車頁面，無論誰訪問，都是看到原來的設計；對於其他50%的購物車頁面，則是新的設計。
SEO的基本目的就是讓搜索引擎更好搜索到網站的頁面，所以我們希望在實驗期間每次對於同一個頁面，搜索引擎看到的結果都是一致的。這樣才可以對比兩種不同設計的頁面對於搜索引擎爬蟲的效果孰優孰劣。
典型的SEO優化包括對標題的優化。例如，控制組中的頁面標題是放入了商家的寶貝數量，例如「艾迪達斯旗艦店 - 1020件商品 - 上天貓，就購了！」；實驗組中的頁面標題是放入了商家上傳的照片的數量，例如「艾迪達斯旗艦店 - 4558張照片 - 上天貓，就購了！」。別小看這樣細小的變化，業界的確有不少成功的SEO優化就是由細小的變化所產生的。
按頁面劃分的細節問題
按頁面劃分的時候，如果僅僅劃分為兩個組，可能會出現一些問題。比如，如果對天貓商家頁面進行按頁面分組，如果在實驗期間正好某商家自身發生了非常瘋狂的大促，那麼它所在的那一組的數據可能會直線飆升。這就可能引起我們的誤解，我們可能以為這是由於實驗本身造成的影響，於是造成了錯誤判斷。
簡單的解決方法就是劃分為四個組，而不是兩個組：
控制組1
控制組2
實驗組1
實驗組2
如果在實驗組1裡面的某個商家因為其自身原因，數據飆升，帶動了整個實驗組1的數據飆升。但是，實驗組1的數據卻沒有什麼很大的起色的話，那麼說明是商家自身原因導致，而非新的功能帶來的影響。
分組的比例分配
分組的比例分配不一定要是50%：50%，因為有些新功能是很可能造成不好的影響的，特別是試用一些新技術。在流量或者頁面很多的情況下，哪怕是99%：1%的比例分配也是可以的，因為在後面還有採樣的過程。對於淘寶，就算是1%的流量也是非常巨大的，所以樣本總量（population）夠大，對1%流量採樣和50%的流量採樣一般是沒什麼區別的。
互斥實驗
有些實驗之間是互斥的，可能會互相影響結果。例如，實驗A的存在會讓實驗B的效果適得其反。
簡單的方法就是開闢「泳道」（swimlane）。就好像在游泳的時候，你在你的泳道游你的蛙泳，我在我的泳道游我的自由泳，咱們互不侵犯。拿按頁面劃分來舉例，我們可以讓實驗A所用的所有頁面佔網站總頁面的20%，實驗B佔據20%，並且實驗A和實驗B所涉及的頁面互不相交（即互斥）。
在A/B測試中要注意什麼
不要過早下定論。一個實驗上線後，不能急著在兩三天內就下定論。統計學上有一個概念叫做statistical confidence，有專門的方法可以用於計算。只有當計算出來的數據達到一定閥值的時候，我們才可以（從統計學上）說這個新的設計是成功或者失敗的。我們可以用現成的計算器來計算。
盡量減小偏差（bias）。例如，如果你對頁面進行分組採用的方式是讓賣拐杖的頁面成為控制組、不賣拐杖的頁面成為實驗組，那這裡面就會產生很大的偏差。因為一般買拐杖都是老年人在買，或者中年的子女在幫老人買，青少年不太可能去買。所以，兩組之間就會產生很大的用戶的性格的差異，對實驗結果的影響就可能很不好了。
所有的產品都可以進行A/B測試
A/B測試允許我們快速演進我們的產品。我認為，除了互聯網行業之外，其他行業也應該學習快速進行A/B測試的思想，創造更好的、質量更高的產品。
A/B測試的場景很多，不同的A/B測試方法每天都在幫我們創建更好的世界。建議大家可以上網搜索，並和身邊的人一起討論如何應用假設測試打造更好的產品。
後語：
用這種A/B測試的方式，確實能驗證剛開始對交互模凌兩可，拿捏不定的設計。
本文轉載自：微信公眾號：前端早讀課
作為一枚創業小兵，我回答一句：很簡單，1成本太大，2用戶基數太小。
美團一直在做。
有自己開發的資料庫系統和頁面上所有點擊鏈接的跟蹤代碼。
除了一些很難A/B test評估的新功能/優化，所有的大功能和大部分的小功能都會有做這種測試。
印象中騰訊就曾經做過這種測試，但卻很少聽說中小型網站會做這種測試。個人估計了幾個原因：
1、用戶群體不夠大。首先這種測試只能使用小概率推送測試頁面，不然大量用戶發現自己瀏覽的頁面和別人的不一樣，會對你的網站的權威造成質疑。但如果測試人數不達到一定數量級，測試數據就不具備參考意義。所以像騰訊網、新浪微博這種網站就有可行性，因為別人1%的用戶量已經是百萬級的了
2、需要產品負責人有數據分析意識。行業並沒有形成通過數據挖掘和數據分析指導產品設計和交互設計的風氣，或者是為了快速上線，直接就忽略了用戶調研的步驟，所以很多人壓根都不知道有這個方法，或者沒有意識到它的好處，甚至覺得這是為自己製造更多工作量首先，A/B 測試本來也不必大量使用；第二，再該用的時候並沒有少用，大概被發現或者出來說的少，不過總的來說，還是第一點原因比重大。
具體原因也可以歸結為一部分產品原因和一部分技術原因，其中產品原因占多數。
產品上的原因是因為實際上並沒有那麼多的地方需要進行 A/B 測試，大多數情況下產品同學都對新的設計心裡有數或者假裝心裡有數，其實也確實沒那麼多地方需要糾結到非要做 A/B 測試才行 -- 這裡必須提一點： A/B 測試和灰度發布雖然看起來比較像但不是一回事，相對來說，灰度發布更常見。
技術上的原因就是 A/B 畢竟要麻煩點，雖然不是什麼有難度的問題（這裡明確反對其他答案中提到技術壁壘的觀點，其實只是麻煩，根本到不了技術壁壘的地步），但是當技術同學面對 N 多新需求的時候，其實心裡不太願意折騰費力不一定討好的 A/B 測試 -- 這種事折騰一次也就夠了。國內公司更多還是缺乏A/B的意識，不知道、不了解A/B對於網站和公司帶來的意義和價值，最近我們首頁在做A/B，效果很明顯，新首頁跳出降低30%，最主要能驅動產品和開發不斷迭代，優化。
最近我發現百度在做。
百度一下一個名人，使用不同的電腦，搜索出來的結果是不同的。一個是整合了很多的結果，另一個則是普通 搜索結果。
2.自身團隊沒多少人，一個人做兩個方案，不面雷同過多，沒多大意義，另外，人不多，但是大家也不是閑著沒事。
3.就算那些大網站也是需要有一個有很想做事的團隊才可以做的，如果不是想做好一件事情，很少有人會去想到這個，畢竟很麻煩。
12.26更
前段時間問了我廠另個部門的同事，我們都不做AB測的嗎？
他說，當然做啊，我們還是ABCD測呢！
我說，那為啥我從來不知道？
他說，你知道了，那我們還測什麼！
分個類。
一類是做了你不知道：
1、有些公司在做，只是你不知道，因為你只看到它的一個版本
2、有些公司在做，只是名字不太洋氣。比如我廠，名字很接地氣，叫「分流測試」
3、有些並不是在大規模做，會提前用小流量做A/B TEST，然後選擇結果好的那個。
1、沒時間——比如正式上線前的小流量測試，是需要提前幾天的數據累計的。
2、用戶量級不夠不需要做。
3、團隊覺得沒必要
可能正確的認識到優化controlled testing對revenue的Benefit的不多？
樓上都說的不錯，但我想說的是，
網站做AB Test是不會讓你輕易察覺的！！
基本上是覺得沒有好的實現框架。
要做這件事第一個工具是流量分層進行實驗的框架，
第二件事是完善的數據分析和報表展現的平台。
這些東西稍上規模的公司都有自己的實現。但是沒見什麼開源的實現（谷歌提供的那個還是太弱了）。
沒發現應該主要是不知道。
比如，大家很難發現百度上同時跑著幾百個實驗。
AB Testing是用數據驅動的方式來優化產品，不要想的太複雜！
A/B testing 確實是一個好東西可以清晰的讓人知道which one is better，可惜目前來說耗時太長了，客戶不停的催，技術人員不停地修改，導致最終的內測時間被大大的縮減。況且在目前的國內市場上，很多客戶只顧短期價值而喪失長久的機會，他們不care說我的用戶更喜歡哪一個，他們更希望的是我們給到的KPI或者ROI。
看氛圍，bing這塊做的很不錯，因為從PM到各級Manager都很重視數據。
國內團隊，有的壓根不做，有的沒氛圍，也不太懂。
有搜索特性的系統，幾乎沒有不做的
之前有針對競價著陸頁做了下A/B測試,整體力不從心的地方就是用戶基數小,以至於最終的效果分析無法正確得到評估
需要耗費的時間長一倍，一般項目趕著上線都是加班加點的，沒辦法留出時間來做A/Btest。test的樣本有幾個，差別性在哪裡也都是要事先分析好的，要不然得出的結果能有多大的改善也很難說
推薦閱讀：