編輯導語：策略產品經理實踐往往會經歷A/B測試上線流程，那麼其流程具體是什麼樣呢？有哪些需要注意的點呢？本文作者來為大家做詳細的說明。
本文將介紹大多數公司中A/B測試的上線流程（如圖5-1所示），主要分為以下幾個環節：
一、提出需求
策略產品經理基於先驗判斷、數據分析結論或者領導要求，需要上線一個策略實驗需求。
二、設計實驗
策略產品經理了解相關技術邏輯，設計單變數實驗並撰寫策略實驗文檔，包括但不限於實驗邏輯描述，如何驗證實驗假設，以及預期的數據收益。
三、技術工程師自測
演算法工程師完成需求，測試工程師介入測試（有時候策略產品經理需要充當測試工程師的角色），添加實驗白名單，確保自己的測試賬號命中實驗。
四、策略產品經理體驗策略
策略產品經理在A/B測試上線后通過將自己的測試賬號在不同的實驗組中切換，反覆驗證實現邏輯是否完全符合需求文檔，並仔細體驗兩組實驗的主觀差異（如果擁有中台系統，可以通過後台實現同一用戶的內容推薦順序對比），時間允許的情況下可以寫主觀評估報告。
五、上線后的檢查點1
上線后2小時觀察相關數據，主要通過實時數據判斷實驗開啟后是否存在問題，檢查以下數據是否正常並記錄在文檔。如果存在問題，立即檢查問題；如果沒有問題，在下一個檢查點重新確認。
1. 候選集曝光量是否符合預期
如果是涉及內容候選集的實驗，需要檢查內容候選集曝光是否是0。如果實驗沒問題，該數值應該是大於0的數字。
2. 服務端請求日誌的數據量是否符合預期
策略產品經理一般很難看到該數值，筆者的經驗是在實驗開啟后，找演算法工程師一起檢查一下服務端請求日誌的監控，如果實驗正常開啟則請求數據量不為0。
筆者遇到多次實驗開啟但是服務端未生效的問題，可能是上線流程存在問題，如果檢查不及時在第二天才發現，會影響項目進度。
如果實驗流量比例過高導致性能壓力劇增，需要調低流量比例。
3. 實驗開啟后的過濾策略或排序策略是否生效
如果是過濾策略，需要檢查用戶推薦日誌中實驗組需要過濾的內容標籤是否存在。
如果是排序策略，需要對用戶推薦日誌中的前50條結果進行隨機抽樣分析，檢查帶有響應標籤的內容排序是否更靠前。策略產品經理需要驗證上線產品是否符合預期並記錄到實驗文檔中。
六、檢查點2
上線24小時后觀察數據變化，此時檢查的重點是實驗是否存在更深層次的實現漏洞。
一般來說，24小時后的數據結果往往和結束點的數據結果趨勢相同，此時的檢查可以提前發現數據趨勢，明確不符合預期的部分（如果有問題，可以提前重新檢查一遍實現方式；如果沒有，則通過，不用檢查）。
如果有時間，建議策略產品經理再次體驗實驗組和對照組的策略，此次的體驗和上次的感受是不同的，因為實驗開啟時第一次體驗實驗組策略可能會有新奇感，並且重心在於測試邊界用例而非用同理心來理解用戶的情緒。
在檢查點2重新體驗實驗組策略，會對用戶的情緒理解得更純粹，不僅消除了新奇感帶來的誤差，而且可以更加放鬆地置身於產品中，以普通用戶的心態來使用產品，此時最容易獲得用戶洞察。
七、結束點
在結束點需要終止實驗，基於多天累計數據，對相應指標進行數據分析並形成數據報告。
關於結束點的選取，不同類型的產品和不同的觀察指標有所不同，具體的選擇方式如下：
- 對於日活級產品（DAU/MAU大於50%的產品）：普通指標需要觀察3個完整天以上（一般為4天），次日留存指標需要觀察7個完整天以上（一般為8天），次周留存指標需要觀察14個完整天以上（一般為15天）。
- 對於周活級產品（DAU/MAU小於50%的產品）：此類產品用戶並非每天活躍，並且具有強周期性。普通指標需要觀察7個完整天以上，一般為8天，因為需要一個周期內的用戶行為對比。次日留存指標需要觀察10個完整天以上，一般為15天，因為需要兩個周期內，兩個分組的用戶行為對比。次周留存指標需要14個完整以上，一般為15天，因為需要兩個周期內兩個分組的用戶行為對比。
以上數據為經驗數據，主要依據是筆者經歷的大多數A/B測試的次日留存指標在第7天趨於穩定，第8天、第9天、第10天和第7天的結果基本一致。
其他指標的結束點時間同理，本質上是因為用戶行為數據會逐漸收到固定的值。
結束點時間的選擇是「實驗精準度」和「項目迭代速度」的折中，如果追求實驗精準度，每個實驗都可以開啟一年之久，但這樣的話在緊張的項目迭代周期中效率就會受到影響，大多數公司以單周迭代或者雙周迭代的節奏開展工作。
八、分析實驗結果
在結束點以後策略產品經理需要分析實驗結果，並給出如下的書面分析。
- 分析實驗數據的結果是否符合預期，以及可能的原因。一般需要參考原始實驗假設，並且結合自己的主觀體驗報告來嘗試回答這個問題。
- 符合預期的實驗，下一步優化的點是什麼。
- 不符合預期的實驗，分析是假設錯誤還是驗證錯誤，下一步改進點是什麼。
九、灰度上線
如果實驗取得了統計置信的正向收益，需要對該策略進行灰度發布，但是流程上會因是否需要發布客戶端新版本而有所區別。
- 如果需要發版，走版本審核的通用灰度流程，一般需要在小渠道放量，觀察產品在不同手機型號下是否存在漏洞。
- 如果不需要發版，關閉原試驗，在A/B測試平台將該實驗狀態調整為「灰度發布狀態」（平台需要支持該功能），調整實驗組用戶的佔比，觀察天級指標的變化情況。比如第一天放量30%，觀察目標指標（比如人均停留時長）在全量用戶上的變化。灰度上線的目的是觀察A/B測試在全量用戶上真正取得的效果，此時雖然不是嚴格A/B測試驗證，但也是十分必要的，下文會介紹為什麼正收益的A/B測試全量後效果不如原實驗結果明顯。
十、回測機制
在KPI考核周期之前一般需要有組織地對有收益的實驗進行回測，所謂「回測」，實際上是對歷史實驗的重新測試。
因為在實驗期間有收益不代表一直存在收益（A/B測試存在局限性，可能用戶群的征分佈發生了改變），所以需要對考核周期內（比如說一個季度內）取得了較大收益的實驗重新測試，預期是拿到同樣正向的收益（數據幅度可能會有差別，這是正常的）。
實驗流程是前人通過不斷試錯總結出來的寶貴經驗，有三個核心收益。
1. 慢即是快
雖然每個實驗規範化的文檔和對應的檢驗將會增加大概3小時的時間成本，但對於演算法或者策略這樣為期數周且持續佔用流量的實驗來說，是非常必要的。
因為一個錯誤實現的實驗，輕則導致數周時間無效，重則導致重要假設的錯誤驗證。我們認真做好每個實驗，會比盲目地大量做淺嘗輒止的實驗更加高效。
實驗迭代速度加快，不是通過減少實驗的規範，而是通過自動化流程的建立和效率工具的開發來實現的。
2. 假設驅動
通過系統的假設、實驗驗證的方式來進行探索，能夠持續地增加我們對於業務、模型、數據的認知。
A/B測試的成功率正常是小於20%的（成熟產品A/B測試成功率更是小於10%），但基於假設驅動的實驗方法，即使是失敗的實驗，我們也能從中提取知識，挖掘新的優化點。
另外，建立系統的認知，能夠使我們找到持續可迭代的改進方案，而非隨機的策略優化。
3. 持續積澱
對於演算法策略團隊而言，每一個實驗即一份學習資料，積累的實驗報告對公司內部的其他業務方向、新人培訓等將有巨大的學習交流價值。
這本用無數實驗數據總結出的「實驗教科書」能夠放大單個實驗的收益，筆者自己便是最好的例子，筆者和同事們共享實驗資料庫和實驗結論，使所有人都能更好地理解內容推薦業務，更好地理解用戶行為，實現縮小自我、產品大眾、平台共享的價值觀。
十一、總結
本文首先介紹了策略產品經理需要了解的Fisher實驗設計三原則，策略產品經理在A/B測試相關項目中最重要的事是通過對業務的深刻理解做出合理假設並設計實驗（做出合理假設的基礎是擁有數據分析能力和用戶洞察，並非一定要了解A/B測試的數學原理）。
同時，筆者介紹了不同當下互聯網公司對於A/B測試重視程度，有利於部分有跳槽想法的策略產品經理進行科學決策，畢竟每家公司的基因很難改變而個人的機會成本很高，希望大家都能選擇適合自己的「產品環境」。
然後介紹了A/B測試的相關分類，並重申了筆者的觀點—A/B測試並非是所有公司的標準配置，最後介紹了實際工作中A/B測試上線的相關流程。
這些方法論是筆者多年實踐經驗所得，根據經驗估算可以將A/B測試的失敗率從30%~40%降低至5%左右。
在項目推進周期中，常見的情況是某個A/B測試實驗開啟一周后發現實驗方式存在問題，以致於需要修復漏洞甚至推倒重來，而在緊張的項目周期中7天時間十分寶貴。
提升A/B測試實驗成功率（實驗后數據顯著提升）的兩個核心秘訣是遵守實驗流程和做出有數據依據的用戶假設。
作者：韓瞳，文章選自《策略產品經理實踐》，2020年7月出版。
未經出版社或作者書面授權，禁止轉載，違者追究法律責任
題圖來自 Unsplash，基於 CC0 協議