「A/B測試不一定是最好的評估方法，它不是萬能的，但是我覺得，不會A/B測試肯定是不行的。」

撰文 | 藍洞商業 郭朝飛

抖音為什麼叫抖音？

當然，這不是張一鳴拍腦袋的結果，它與字節跳動內部一個名為A/B測試的工具有關。

抖音做出產品demo之後，起了很多名字，各自logo也不同。他們將這些名字放在不同應用市場，但位置、預算等條件是一致的，測試了各自對用戶的吸引力程度、下載轉化率等指標。

抖音當時排第二，團隊討論後認為，長期來看抖音更符合認知，也更能體現產品形態，就選了這個「第二名」。

從最初的今日頭條，到後來的抖音、西瓜視訊，再到懂車帝、飛書等構建成的產品矩陣，外界一直好奇，字節跳動持續迭代的方法論到底是什麼？

事實上，在字節跳動過去的九年間，大量的A/B測試幾乎每天都在進行。就在不久前，字節跳動旗下面向企業的智能科技品牌——火山引擎舉行品牌發布會，基於大數據、人工智慧和基礎服務等技術能力，為企業提供系統化的全鏈路解決方案，助力企業務實地創新，給企業帶來持續、快速增長，而A/B測試是火山引擎智能營銷套件中的一個工具。

如果說字節快速迭代的秘訣是數據驅動的話。A/B測試是最能夠體現數據驅動價值，也最能代表數據驅動理念的。

事實上，A/B測試早已在亞馬遜、Google等海外互聯網公司被廣泛應用和傳承。

但在國內，A/B測試還處於初級階段。不久前，火山引擎市場部做過一個市場調研。1000家企業的樣本數據顯示：在企業的日常業務和管理中，A/B測試的普及率並不高，滲透率不足30%。

A/B測試到底是什麼？有何神奇之處？既然如此強大，在國內外市場為何「冰火兩重天」？

A/B測試並不是互聯網的專利

互聯網圈有一句話，頂級PM（產品經理）只能跑贏一半A/B實驗。

但如果追溯起來，A/B測試並不是互聯網的專利。很早的時候，A/B實驗就被用於醫藥實驗等科研領域，比較著名的便是英國海軍外科醫生詹姆斯·林德出海，在船上用臨床實驗治療壞血病的案例。

那是1747年，航行中很多人患上壞血病。林德選了12名比較嚴重的病例，分為6組，在6天的時間裡，把他們安排在一起，吃食完全一樣。實驗的關鍵之處在於，根據當時的流傳說法，給每組吃不同的可能治療壞血病的東西。比如，一組每天吃兩個橘子、一個檸檬，一組喝蘋果汁，其他方案還包括喝酸醋、海水等。後來，實驗證明吃橘子、檸檬是有用的。

回過頭來看，該實驗未必完全嚴謹，比如患者的年齡、民族、地區等問題是否考慮進去。時至今日，其背後蘊含的A/B實驗精神與理念已經進入多個領域和行業，尤其在互聯網行業被廣泛應用。

A/B實驗，又被稱為小流量實驗。在互聯網領域，簡單說就是針對要改進的某項功能、UI、邏輯策略等，提供兩種或多種備選方案，從總體用戶中抽取一小部分，隨機將抽取出的流量分配給不同方案。比如讓一部分用戶使用A方案，一部分用戶使用B方案，最終結合一定的統計方法，通過實驗數據對比來確定最優方案。

A/B測試在互聯網公司大規模應用，是在美國的Google、亞馬遜、Facebook等公司。

一位有Google工作經歷的人士透露，Google用A/B測試最廣泛的是搜索、廣告兩大團隊，因為這兩項業務用戶量超級大，結果都容易用數據衡量。

上述人士透露，他曾在Google總部工作過一段時間，他當時的主要任務就是通過改進Google搜索廣告的產品，來提升Google廣告點擊率和營收。

當時，Google每月搜索廣告的產品上會做幾百、上千次實驗，他會嘗試不同的產品改動，不同的優惠策略、賣點，看看哪個轉化率更高。他發現，100個實驗版當中，可能60~70個都對用戶沒有影響，剩下的幾十個版本中，有十幾個可能會比正在用更好，把這些更好的版本上線、推給更多的用戶，就可以持續提升轉化率，高效率地試錯。

Google翻譯設計師Pendar Yousefi與Olivia Grace在一篇文章中指出，在Google翻譯網頁版的改版中，A/B測試就起到了重要作用。

一開始Google將翻譯結果文檔框做成了藍底白字，但用戶反饋不好。重新設計時，很多設計人員猶豫甚至質疑，是否要換掉藍底白字。

Google做了A/B測試，一組實驗用藍底白字，另一組用灰底黑字。A/B測試的結果顯示，採用藍底白字的翻譯結果文檔框後，用戶使用Google翻譯的頻率和次數明顯減少。最終，為了便於長篇翻譯結果的可讀性，Google還是改了過來。

「雖然有種種不情願，但我們還是將藍底白字更新成了灰底黑字。」Pendar Yousefi與Olivia Grace在文章中寫道。

相比Google，亞馬遜的產品更龐雜、繁瑣，運營策略也更龐雜，因此亞馬遜的實驗數量更多，因為它可以優化的點特別多。

貝索斯曾經說過，亞馬遜的成功，秘訣就是每年、每月、每天不斷進行實驗。

字節跳動一位高級實驗工程師曾這樣描述A/B測試：一方面我們無法承擔任何一個錯誤特性影響上億用戶體驗的嚴重後果；另一方面我們又希望能夠分離並量化每個特性的影響。

這就需要我們設計並堅持使用一套數據驅動的方法，使得我們可以以較小的風險對新特性進行評估，積極試錯積累經驗；並且這個方法有能力排除其他因素（如同時開發的其他特性、時間因素等）的干擾；最後，除了”好’或者’不好”，我們希望這個方法也能夠給出定量的結果。

為了解決上述問題，普遍使用的方法是小流量隨機實驗，也就是A/B實驗。

理念和認知受限

在國內，A/B測試也算不上新鮮事物。

一位資深互聯網運營人記得，2012年前後他第一次接觸A/B測試，彼時A/B測試與精益創業等理念一同從外國傳入。後來創業時，他第一次將A/B測試應用於課程詳細頁的版本測試中。

但不得不承認，目前A/B測試在國內關註度並不高，普及程度與影響力也遠不及美國市場。

從根子上說，A/B測試首先不是技術問題，而是理念與認知問題。

在前述管理者看來，一些國家的教育體系中，貫穿著類似A/B測試的理念，比如早在幼稚園時期，就會讓兒童觀測豆子生長過程中淋水與不淋水的差異。當這種A/B測試、實驗系統根植於理念中時，在產業界、企業界就不用推廣，是自然而然的選擇。

在國內市場，很多時候決策者判斷是否要做A/B測試，不是根據數據判斷，更多是依據經驗。這裡的決策者是廣義的，可能是技術總監、產品總監，也可能是產品經理、研究人員。一些團隊會認為，某個產品的好壞，產品經理可以根據用戶洞察、產品價值洞察來判斷，最重要的、最關鍵的是產品經理的個人能力。

事實上，決策者也明白A/B測試的重要性，但並不認為它是最重要的。原因在於，在他們看來，不做A/B測試可能不會直接影響產品的成敗，也不會直接決定產品的後續發展。

對於企業來說，是否選擇A/B測試，還需要平衡成本與效率的問題。選擇做A/B測試，不僅有研發成本，還有時間成本。也就是說，搭建測試系統需要支出更多開發版本，搭建完成後，還要經歷一個測試、等待、決策的時間周期。

從管理角度來看，是否做A/B測試，完全依賴於怎麼算帳。一個應用如果不做精細測試，很可能發展了三四個月之後發現，方向不對，就會浪費時間和機會；但是做測試，就需要投入金錢成本。總的來說，提前通過測試來試錯，結果會更高效。

「所以為什麼越大的團隊、大廠越容易做A/B測試，而越小的公司就越難？」前述管理者提醒道。

據火山引擎一位數據智能解決方案負責人透露，他們做過調研和沙盤推演後發現，企業自建A/B測試平臺會涉及到各種技術成本和運維成本。小企業雖然存在剛需，但是自建系統壓力大。

所以，最終的行業走向應該是，企業無需自行搭建測試系統，尤其是傳統企業、創業公司，可以採購第三方的產品與服務，把專業的事交給專業的人。目前已有字節跳動這樣的大廠，通過自己的ToB品牌火山引擎開放相幹產品，是做A/B測試的不錯選擇。

並非「萬能公式」

A/B測試系統的研發，護城河並不低。

因此，對於採購A/B測試的公司來說，尷尬之處就是國內市場可選擇的標的並不多，而且相當一部分還是小規模公司，這也是當前國內A/B測試發展緩慢原因之一。

在火山引擎A/B測試的一位產品工程師看來，準確的分流是A/B測試的基礎門檻，A/B測試平臺要保證科學的流量分割、流量層直接的正交互斥，使得實驗不受干擾。

「如果分流不準，實驗效果就肯定不準，就不知道怎麼去迭代你的推薦模型，然後不能更多地留住用戶，不能賣更多的廣告，這是一個完整的鏈條。」這位產品架構師補充道。

此外，更龐雜的是指標設計和解讀以及置信度的統計方法，一旦出現失誤，更易導致錯誤的結論。

因此，在A/B測試中存在很多「坑」，一不小心就會出錯。

比如，經常被採用的奇偶數分流，就是一種錯誤的分流方式。

有些企業通過用戶的ID尾號奇偶性做分流測試。雖然從極限理論上來看，奇數和偶數各占一半，看起來沒有什麼問題。但是從實操上來看，企業的數據的充分積累達到極限的邊界並不現實，而且用這些數據來做A/B測試，更是完全違背了小流量實驗的原則。

實際上，A/B測試要求，盡可能地保持實驗組和對照組流量分布一致（與總體流量也需保持分布一致），否則得出的實驗數據並不具有可信性。

再比如，A/B測試中不能隻簡單觀測實驗數據的漲跌，不考慮實驗結果是否顯著。這是因為，實驗觀測得到的是樣本數據，不是整體數據。如果隻對數據進行簡單的計算，對於實驗結果的判斷很可能會出錯。

因此，需要結合統計學的方法，在評估實驗結果時加入相應的統計學指標，如置信度、置信區間、統計功效等。原則上，如果實驗結果不顯著，或者說不置信，便不能判斷數據的漲跌，是否是由實驗中採取的策略造成的，也可能由抽樣誤差造成的，就不能盲目地全量發布新策略/否定新策略。

當然，有必要提及的是，A/B測試不是萬能的，並不一定適用於所有場景。

用字節跳動副總裁楊震原的話說，「A/B測試不一定是最好的評估方法，它不是萬能的，但是我覺得，不會A/B測試肯定是不行的。」

破局者出現

火山引擎全面開放，為市場提供了一種選擇。

與很多公司不同的是，A/B測試是寫入字節跳動的基因與文化當中的，也曾在字節跳動的產品矩陣中扮演重要角色。

楊震原2014年加入字節跳動，進入公司他就聽說，當時張一鳴還在寫代碼，那時字節就已經在做A/B測試。兩年後，A/B測試變成字節內部廣泛使用的工具，增加了很多功能，被叫作Libra平臺。2019年以後，A/B測試對外開放，服務外部客戶。

目前，A/B測試在字節內部可謂應用廣泛，從產品命名、交互設計，到廣告優化、市場活動、用戶增長，甚至包括修改字體、彈窗、界面大小這樣的細節。

兩個月前，火山引擎大數據應用產品總監張錦波分享過一個案例。字節旗下一款短視訊APP，與同類產品相比，留存比較低。持續分析後，發現主要原因是大部分新用戶沒有上滑操作，體會不到上滑會帶來更多、更豐富、好玩的視訊。

產品經理做了一個A/B測試。他們設計了一個半動態化的上滑引導，一個月內針對新用戶採用10%的流量，對照組和實驗組各占5%，希望借此提升上滑操作滲透率與新用戶留存。

他們失敗了。新用戶的次留、2留、3留沒有顯著提升，錯誤操作的滲透率卻提升了4%。實驗結論是：這種半動態式的引導樣式其實對於核心指標是沒有收益的。

在第二輪測試中，他們設計了全動態式的引導方案。結果新用戶的次留、2留、7留上全部顯著提升，幅度在8%—10%之間。

進一步分析發現，發達地區與欠發達地區也有差異，前者上滑功能滲透率提升明顯，高於平均水平，後者新用戶留存並沒有提升。原因可能是，發達地區工作生活節奏快，如果沒有直觀的上滑操作引導，耐心用完就會馬上跳出。

「內部基本上就是，能用A/B測試的都用。」楊震原總結道。

數據顯示，當前字節跳動每日新增約1500個A/B測試實驗，服務於400多項業務，累計做了70多萬次實驗。

火山引擎A/B測試與對手相比，競爭力主要在兩個方面。

一方面，從能力的完備性和實驗場景的豐富度來講，火山引擎是相對領先的。比如實驗基礎的流程管控能力、實驗後報告分析能力等，這些都是在字節內部反覆實踐沉淀下來的。場景自不用說，字節有短視訊、直播、推送、廣告、搜索等等。

另一方面，火山引擎開放後，除了產品，更強調服務，客戶採購之後，會在實驗方法論、分析、後續運維等方面幫助客戶，讓工具在客戶內部真正落地，產生業務價值。

拿悟空租車來說，其租賃平臺在付款時，有一個押金繳納環節，無法使用信用免押的用戶，必須同時支付一筆數額較大的押金，這可能會給用戶用車決策帶來較大的影響，直接影響平臺成單率與收入。悟空租車希望找到一種方式，降低押金開銷對用戶用車決策的負面影響，從而提升平臺的下單轉化率。

悟空租車團隊與火山引擎合作，推出新的設計方案，通過A/B實驗產品，用小流量進行方案試錯。實驗兩周後，新方案為「最終下單完成」指標直接帶來近7%的增長。

火山引擎A/B測試成為一個行業變量，同時也是字節To B的一把密鑰。