支撐Pinterest日均1000+次試驗的A/B測試平臺揭秘

編者按:本文詳細介紹了 Pinterest 內部A/B測試平臺的搭建過程,對于無論是有技術能力和資源想要自建A/B測試系統的大公司,還是想在業務中引入第三方A/B測試方法和工具的中小公司都極具參考意義。

1

作為一家數據驅動的公司, Pinterest 是非常依賴試驗來指導產品和功能迭代的。

 

Pinterest 隨時都有大約1000個試驗在進行,并且試驗的數量每天都在增加。 因為試驗數量和相應記錄數據的持續增加,衍生了向工程師提供一個可靠易用平臺的需求,來保證他們使用的時候沒有錯誤。 為了避免由試驗者造成的一般錯誤, Pinterest 引入了輕量級的配置 UI ,QA 工作流和簡化的 API 接口來支持跨平臺的A/B測試。

 

在構建試驗平臺時, Pinterest 優先考慮以下要求:

 

1.實時配置更改:需要能夠快速地關閉試驗或實時啟動試驗,不需要每次更改配置的時候都進行代碼部署,特別是在修復網站故障的情況下。

 

2.輕量化過程:設置試驗不應該比一個正常的功能啟動更復雜,這樣就可能阻止用戶做出可以預測到的錯誤。

 

3.客戶端不可知:使用者不必為每個平臺學習新的試驗方法。

 

4.試驗分析:為了得出更好的試驗結論,我們建立一個易于使用的分析控制面板。

 

5.可擴展性:要求整個系統在線上服務和離線試驗數據的過程中都可以擴展。

 

簡化的過程

Pinterest 的試驗都遵循一個共同的模式:

 

1)通過初始設置創建試驗,建立假說,記錄驗證該假說的方法。

 

2)將試驗披露給 Pinners ,增加新群組和禁用組,通過篩選器來優化用戶。

 

3)結束試驗時,將代碼提交給所有的 Pinners ,或者回滾代碼并記錄試驗結果(根據試驗結果決定提交新代碼或回滾)。

 

在以前的框架中,這些變化全都是通過代碼實現的。 然而, Pinterest 希望建立一個新的架構,在這個架構中,用戶可以在 UI 界面里實現變更,提供交互反饋和驗證,并且這個基于配置的框架的變更推送獨立于代碼發布之外。

 

像語法錯誤、不平衡組分配、重疊群或違反試驗程序這樣的常見實驗錯誤都會進行交互驗證。 Pinterest 的A/B測試平臺主動提供了預先搜索建議來減少人為輸入,如下圖2所示。 現在進行一次試驗通常只是需要進行一些點擊。

 

為了讓配置可以被任意客戶端實時訪問, Pinterest 利用內部系統以序列化格式存儲所有試驗設置,并在數秒內將它們同步到試驗系統的每個主機。 一個典型的配置文件在反序列化之后具有以下內容:

{“holiday_special”:

{

“group_ranges”: {

“enabled”: {“percent”: 5.0, “ranges”: [0, 49]},

“hold_out”: {“percent”: 5.0, “ranges”: [50, 99]}

},

“key”: “holiday_special”,

“global filter”: user_country(‘US’),

“overwrite_filter”: {“enabled”: is_employee()},

“unauth_exp”: 0,

“version”: 1

}

}

 

配置與代碼分離的好處是可以對試驗設置進行即時更新,這意味著配置變化,如增加試驗組的流量不需要重新進行代碼部署。 這就將試驗從生產部署中解放出來,大大加快了迭代速度,特別是在需要緊急更改時。

質量保證

一個簡單的試驗可能會影響到數以百萬計的 Pinners ,所以 Pinterest 配備了高標準的測試操作流程和嚴格的質量保證工具。 試驗應用程序還配置了一個審查工具,這個工具可以為每個試驗變化創建一個審查過程。 圖3顯示了一個修改組范圍和篩選器的待定更改。 審批人可以通過 UI 界面指定,并以電子郵件方式通知。

 

對于大多數試驗,有一個由平臺開發者、用戶和數據科學家組成的跨團隊協助小組。幾乎每個更改都需要協助者仔細檢查規劃,假設,關鍵結果,觸發邏輯,過濾器設置,組驗證和文檔。這樣的過程在我們的網絡應用程序上執行,以使每次更改都需要填充一名幫助者。除此之外,還有一個定期的試驗助手培訓計劃,以確保每個團隊至少有一個人得到認證。

 

一個試驗通常伴隨著代碼變化,比如將對比組/實驗組的信息嵌入到決策邏輯中。 Pinterest 要求試驗用戶通過 Pull Requests 按鈕在試驗平臺添加一個 Pull Request(PR) 鏈接,這樣幫助者和分析師就很容易跟蹤試驗行為,并在需要時進行調試。 此外,它們還將每一個變化作為評論發送到 Phabricator (我們的庫管理工具)中對應的 PR 中。

 

用戶還可以在 UI 界面創建一個正在進行試驗的測試拷貝。 它們將被移植到如圖5所示的測試面板中。 在測試面板中所做的任何更改都不會影響到正在進行的產品試驗,并且測試結果僅對測試工程師可見。如果測試結果不錯,測試工程師就可以通過點擊 Copy To Prod 按鈕將其移植到產品中。

 

API

試驗 API 是用戶通過 UI 將他們的應用代碼鏈接到試驗設置的接口。兩種主要的應用方法如下:

def get_group(self, experiment_name)

def activate_experiment(self, experiment_name)

 

要注意的是, get_group 方法返回的是調用者所指示的組的名稱。 在內部,組是通過計算基于試驗信息的哈希值得到的,并且這種方法沒有副作用。 另一方面,調用 active_experiment 方法向日志系統發送消息,并對分析結果做出貢獻。這有助于分析實驗結果。 這兩種方法足以覆蓋大多數用戶案例,并且通常以如下方法使用:

# Get the experiment group given experiment name and gatekeeper object, without actually triggering the experiment.

group = gk.get_group(“example_experiment_name”)

# Activate/trigger experiment. It will return experiment group if any.

group = gk.activate_experiment(“example_experiment_name”)

# Application code showing treatment based on group.

if group in [‘enabled’, ’employees’]:

# behavior for enabled group

pass

else:

# behavior for control group

pass

上述代碼中的 Gatekeeper 對象 gk 是一個試驗所需要的用戶/會話/元信息的封裝器。 除了上述的 Python 庫,我們還有一個獨立的 JVM (Scala 和 Java) 庫,可以對 Javascript 和移動APP(安卓和 iSO )提供支持。

設計和架構

 

試驗平臺從邏輯上可以分為三個部分:配置系統,一組 API 接口和分析路徑。 它們通過定向數據流連接:

 

1.配置系統將用戶在 Web UI 所做的修改保存到我們試驗數據庫中,這些信息以序列化的格式在一分鐘以內的時間間隔內同步到每一臺服務器中。

 

2.試驗對象更新試驗配置,通過 API 來驗證試驗邏輯,比如試驗類型和組分配。

 

3.由試驗對象所產生的活躍試驗記錄將通過內部 Singer 服務器傳送到 Kafka 。 分析路徑將根據這些試驗記錄,按照用戶定義的參數創建試驗報告,并發送到控制面板。

 

總結

這套系統于去年夏天推出后,支持了 Pinterest 內部的大部分實驗。 一些團隊功能,比如實時參數控制面板、實驗郵件通知、交互文檔和協作工具,以及 SEO API/UI 也被添加到系統中。

 

本文由吆喝科技編譯自 Pinterest 博客,原文鏈接:

https://engineering.pinterest.com/blog/building-pinterest%E2%80%99s-ab-testing-platform

9333 Views
即刻實踐文章理論 A/B測試 灰度發布 產品優化 免費申請
Please wait...

訂閱我們

對于每位訂閱讀者,每兩周,吆喝科技會為您發送4篇精選文章,可能是最新的A/B測試實踐,也會是你所期待的增長干貨。
qq宠物捕鱼大师 极速时时接口 内蒙古时时遗漏数据 香港赛马会走势图 北京时时赛车 浙江快乐12开奖直播 河内一分彩app 江苏快3时时彩 今期开码结果开奖 重庆时时计划_人工版 上海快3官网下载