【酷澎數據力應用3：顧客體驗】天天上千次AB測試高度自動化，UX決策全面數據驅動

數據驅動決策是酷澎核心企業文化，數據工程師和數據科學家遍布酷澎不同部門。舉凡美術設計、介面設計、行銷策略以及其他業務環節，酷澎許多決策會利用數據來驗證最佳做法。他們最常用的驗證方法是A/B測試，酷澎App中，每個功能、每個介面設計細節、每個商品推薦邏輯，不是經過A/B測試驗證，就是正在A/B測試。

酷澎執行A/B測試的模式是觀察新做法相較既有做法的對使用者體驗的影響，不會一次測試兩種新功能。執行測試時，工程師會撰寫App改動程式碼及指標監測程式碼，前者會部署到正式版App，在實際商業情境中觀察顧客體驗指標，後者則會擷取實驗相關指標，來監控實驗環境及顧客反應。

每天，酷澎App上執行超過1,000個A/B測試，需要處理30億個相關事件。為了確保這些測試能妥善進行，且不會影響到App穩定度、顧客體驗或其他測試，酷澎打造了實驗平臺，中心化檢查實驗前程式碼、管理實驗設定、監控實驗指標、通報實驗異常、自動終止不良實驗，並根據各式指標彙整出實驗結果報告。

用Lambda架構兼顧實驗結果報告的時效性及準確性

實驗平臺中，最核心的系統是A/B測試系統，負責從顧客互動事件等指標來計算出實驗結果報告。此系統採用了Spark平臺來實現Lambda架構，分為快速處理層（Speed layer）和批次處理層（Batch layer）來各自計算實驗結果。前者著重於快速產出結果，後者則強調高精確度。這兩個處理層的計算結果，會再整合為最終實驗結果，存入資料庫紀錄。

快速處理層的實驗報告計算邏輯是，只會計算上次計算結果到當次計算期間的數據，每隔15分鐘更新一次實驗報告。這個做法的好處是，能讓內部使用者快速窺見實驗情況。不過，這種做法可能會因為數據延遲性等問題，導致計算結果並非百分之百準確，且偏差幅度會不斷累積，最終使實驗結果失真。

而另一個批次處理層，則是每次都會重新擷取實驗開始至計算當下的原始數據，從頭開始計算整體實驗報告。也就是說，就算過往報告因為數據錯誤而產生偏差，只要後來數據有校正，便不會影響新報告。這種處理模式較費時，每1.5小時才會更新一次實驗結果報告，不過結果更加精確。

為了同時計算上千個A/B測試的實驗報告，這些運算過程套用了Akka框架來進行分散式運算。此框架下，Spark的運算資源能更有效分配給不同並行任務，且單一運ㄔ算節點當機時，節點會自動重啟，不會連帶影響到其他實驗。

酷澎A/B測試系統採取Lambda架構，分為會用完整實驗數據計算結果的批次處理層，以及一定時間就會根據當下可用數據計算實驗結果的快速處理層。這樣的設計，可以確保實驗結果精確度，也支援高時效性分析。圖片來源／酷澎

設計程式碼自動化檢查機制，避免A/B測試造成不可逆系統錯誤

酷澎App高達8成的技術事故源自於A/B測試。這是因為，一口氣在不同作業系統、不同App版本、不同地區執行成千上百個實驗時，工程團隊難以鉅細靡遺檢查每一行程式碼。

發生事故時，酷澎會撤銷A/B測試的B程式邏輯（新做法），將所有使用者導回穩定的A程式邏輯（預設做法）。然而，很多時候，實驗程式碼沒有確實分割A/B程式邏輯，導致撤銷B邏輯會連帶使A邏輯也發生異常，事故處理變得更加複雜。

為了減少這種情況，酷澎打造了一個程式碼檢查機制，自動辨別可能造成A邏輯更動的程式碼，並通報開發人員。

這個機制分為4個步驟。第一步，當實驗者提交A/B測試用的App程式碼，系統會於Git層級偵測測試程式碼相對於原始程式碼的異動，分為新增（Addition）、刪除（Deletion）、更動（Modification）3類。

第二步，系統會分別將原始App程式碼及測試程式碼轉化為抽象語法樹（AST，Abstract Syntax Tree），以樹狀圖呈現出程式碼架構，來兩兩比較差異。前一步偵測到的異動程式碼，會進一步分類為新增、刪除、更動及移動（Movement）4種模式，以供後續檢查。

第三步，前述4種異動程式碼，會根據各自檢查規則來分析語法和執行順序，以判斷是否會影響A邏輯。舉例來說，如果新增了一行宣告式程式碼，但還沒有於他處被呼叫，就會判斷為無影響風險；若新增了一行在A跟B邏輯都有可能執行的表達式程式碼，則會判斷為有影響風險。

第四步，系統會標註出有影響A邏輯風險的程式碼，再發出警告，要求重新調整程式碼。若程式碼影響幅度很大，連風險程式碼的上層程式碼都會連帶標註。

酷澎強調，他們使用的判斷規則不一定適用於所有部署環境和系統架構，更不是萬靈丹。不過，啟用此檢查系統後，錯誤程式碼行數減少了27%，B邏輯實驗連帶影響A邏輯的情況也減少了30%。

酷澎會自動化檢查A/B測試程式碼是否有將A/B邏輯完善切割，以避免事故發生時難以復原回既有邏輯。圖為新增程式碼的檢查規則，若程式碼被判斷為有影響A邏輯風險，就會通報工程師修改程式碼。圖片來源／酷澎

打造規則式自動監測系統，大幅簡化實驗監測流程

執行A/B測試時，數據工程師和數據科學家必須監測許多數據指標，這包括系統面的延遲、錯誤率、測試族群分配、流量，以及使用者互動面的轉換率、點擊率、停留時間等。

指標監測機制的設計和部署都相當複雜，因為追蹤指標數量多、許多指標會相互影響、程式碼需要和不同系統溝通，而且不同指標還需要不同判別方法及應對動作，例如某些指標達標會要求直接終止實驗，另一些指標則需要通知實驗者來調整實驗方法。

以前，酷澎工程師部署監測機制需要花上2周，當實驗方法中途有調整，監測程式碼還必須隨之調整。為了降低監測實驗指標的時間和IT人力成本，酷澎設計了一個規則式監測系統，統一管理指標數據查詢和執行終止實驗等後續動作。也就是說，工程師部署監測機制時，只需對這一個系統設定查詢指令和不同指標觸發的動作，大幅簡化過往作業。

這個監測系統的運作模式是，與A/B實驗指標相關的原始數據會存放於MySQL，這些原始數據會拋轉到一個時間序列資料庫。系統每分鐘自動對時間序列資料庫執行一次查詢指令，當指標達到一定門檻，則會執行工程師當初設定的動作，例如自動終止實驗，或發送警報給實驗負責人。

轉換率下滑時快速通報，10分內自動中斷不利消費者體驗的A/B測試

A/B測試對象是酷澎消費者，若測試中功能明顯造成消費者體驗下滑，會有降低獲利，甚至流失消費者的潛在風險。

為了減少這些損失，酷澎做了通報系統，在消費者轉換率明顯下滑時通知實驗負責人。不過，此系統採取批次運算模式，最快反應時間是4小時，止損能力有限。後來，他們打造了新通報系統，利用Spark Streaming每隔2分鐘分析一次串流資料，大幅增加數據即時性。

酷澎判斷新功能導致消費者體驗明顯下滑的指標是新功能與消費者轉換率關聯性。若系統連續5次計算都判斷新功能拉低了轉換率，便會自動終止A/B測試，並通報實驗負責人。也就是說，從消費者體驗明顯下滑到測試終止，反應時間只需10分鐘，是先前系統反應速度24倍。

A/B測試可能會導致使用者體驗下滑。酷澎會追蹤測試功能的消費者轉換率，若明顯降低，最快10分鐘就能自動終止實驗。以此圖為例，新功能轉換率低了20%，若無法快速終止實驗，會損失大量潛在營收。圖片來源／酷澎

用ZooKeeper管理A/B測試設定數據，以維持大量實驗穩定性

酷澎他們使用ZooKeeper來統一管理儲存A/B測試所需的設定數據，例如測試OS、App版本、A/B測試受眾設定等。當測試方法有調整，ZooKeeper會快速同步設定到10,000個負責處理A/B測試設定的分散式運算節點，以避免不同節點設定暫時產生落差，進而影響實驗品質。

ZooKeeper運算節點分為調度運算工作的領導者節點（Leader node），以及負責執行這些工作的追隨者節點（Follower node）。這些節點會持續進行領導者節點選舉（Leader election），依照節點可用運算資源等狀態來認定領導者節點。

不過，這些節點的資源常會隨著使用者連線情況浮動，造成領導者選舉不穩定，大幅影響分散式運算效率。為了解決此痛點，酷澎加入了一種新節點，名為觀察者節點（Oberserver node）到運算環境，專門處理使用者連線相關任務，且不參與領導者選舉。為了進一步降低使用者連線延遲，酷澎還打造了SDK，利用虛擬資料中心（VDC）設定來尋找離系統最近的觀察者節點。有了這些做法，領導者和追隨者節點便能穩定執行領導者選舉，進而維持分散式運算效率。

ZooKeeper處理數據量極大，每當更新後重啟，ZooKeeper於開機階段會一次傳送超過100GB的設定數據。為了確保節點間頻寬，酷澎選擇將ZooKeeper JVM部署於較貴的頻寬保證執行個體上。

酷澎表示，實驗平臺上的許多機制都是為了規模化而設計。有高速、穩定、精確、標準化進行大量A/B測試的能力，不僅使酷澎於韓國拓展業務規模及多樣性時能持續用數據來驅動決策，甚至進軍多國市場時，他們都有意用同一套實驗平臺來管理全球業務所需的A/B測試。

 相關報導