??

點擊關注“有贊coder”

獲取更多技術干貨哦～

作者：子固部門：數據中臺

一、背景

有贊是一個商家服務公司，致力于幫助每一位重視產品和服務的商家成功。隨著移動互聯網的流量增長紅利漸漸褪去，商家獲得新的流量越來越困難，幫助商家實現更有效的流量轉化與長期目標的增長是有贊SaaS服務的應有之義；同時，隨著有贊SaaS功能的不斷完善，服務的商家不斷增多，而業務場景也越來越復雜，考慮到有限的研發資源，提升產品和技術的迭代效率成為當務之急。

在硅谷，增長黑客等數據驅動增長的方法論，正在幫助如Facebook、Google等如此體量的公司實現持續的業務高速增長；在國內，通過數據手段來驅動業務增長也取得了共識，數據成為賦能增長的核心手段。其中，A/B測試作為數據驅動增長的核心工具，可以有效地提升流量的轉化效率和產研的迭代效率。 因此，作為數據團隊，基于對數據驅動增長的思考，我們首先構建了有贊ABTest系統。

二、A/B測試概覽

2.1 簡介

A/B 測試是一種對比分析方法，通過對流量進行細分和隨機實驗，并監控和跟蹤實驗效果，來判斷實驗所代表的策略的可行性和有效性。

• 對比：通過對流量的隨機細分，來進行有效的獨立隨機實驗，可以排除外在條件的影響，因此更加科學。

• 分析：通過跟蹤和分析實驗的事實效果數據，來判斷實驗的可行性和有效性，因此更加精確。

如下圖所示，示例 A/B 測試將目標人群隨機劃分為A、B兩組，分別展示不同的頁面，然后通過跟蹤和對比A、B兩組用戶的轉化率，來比較A、B頁面的效果；顯而易見的，A組頁面的轉化效果好于B組頁面。

相比原有基于時間的如T+30的效果對比，A/B測試可以排除時間和人為因素等外在所有因素的影響，并且保障同時進行的場景實驗相互獨立互不干擾，可以準確而且高效地評估實驗效果。

2.2?應用場景

A/B 測試解決的是策略優化的問題，即從多個可選策略里找出最優策略。常見的應用場景包括：

• 灰度發布：技術&算法迭代
• 功能優化：界面模塊、樣式風格、交互方式等
• 內容優化：推廣海報、落地頁、內容模塊、文案等
• 運營優化：運營策略、溝通話術等

2.3 核心概念

我們參考了Google的論文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》，考慮到流量的隔離、復用以及細分，引入了以下幾個核心概念：

應用：應用是對流量和系統的劃分，比如商詳頁可以是一個應用，推薦系統也可以是一個應用。應用實現對流量的隔離，一個應用下可以包含多個場景。場景： 場景是指需要對比不同策略的業務場景，場景是進行A/B測試的業務單元，一個場景下可以包含1個或1個以上的實驗(測試中的場景通常至少包含2個實驗)。流量在同一應用下的不同場景之間可以被復用。實驗： 實驗代表場景下的策略，由實驗配置來描述，即一份實驗配置對應一個業務策略。同一場景下的實驗相互之間是互斥的，場景的分流結果返回且僅返回一個實驗。實驗的主要配置如下圖所示(示例場景為ABTest平臺的底部答疑提示)：

流量來源： 流量來源用來指定實驗流量細分的粒度和比例，流量來源可以是具體的上一層某個實驗，也可以是不指定實驗即來源于大盤流量。一個實驗可以有一個或多個流量來源。

2.4 增長測試迭代

A/B 測試通常是一個持續的迭代過程，包含5個步驟，即產生實驗想法、評估實驗優先級、設計和開發實驗、分析數據以及應用結果。《硅谷增長黑客實戰筆記》將其視為一個數據驅動增長的標準流程，因此我們也稱之為增長測試迭代流程。

產生實驗想法。產生實驗想法是進行實驗的第一步，要求盡可能多地提出有可能提升業務目標的實驗想法。

評估實驗優先級。由于產品研發資源是有限的，不同的實驗想法對于提升業務目標的效果也各不相同，我們需要評估實驗想法的優先級，優先選擇產出大、置信度高且容易實現(即ICE標準)的想法來進行嘗試。ABTest系統通常假設實驗想法已確定，實驗想法的產生和評估我們會在增長分析平臺里實現(將在后續文章中介紹)。

設計和開發實驗。主要包括：1)確定實驗變量和分流策略；2)在ABTest平臺上配置應用、場景、實驗以及流量來源；3)根據示例代碼，完成ABTest SDK接入；4)測試、驗證并上線應用和實驗場景。

分析數據。主要包括：1)確定實驗評價的核心度量指標；2)配置通用數據度量模型，或者接入自定義度量數據；3)查看ABTest平臺效果報表，判斷試驗的有效性和顯著性。

應用結果。判斷最優實驗，并通過實驗100%切流上線或者實驗下線來應用實驗結果。

三、ABTest系統設計

3.1 交互流程

ABTest系統主要包括三個部分，分別為ABTest平臺、ABTest SDK以及數據流。ABTest 系統交互流程如下圖所示：

3.2 ABTest平臺

ABTest平臺是用戶(管理員)與ABTest系統的主要交互接口，主要提供以下功能：

• ABTest元數據管理。用戶可以在ABTest平臺上完成完備的元數據管理操作，包括應用、場景與實驗的創建、編輯和刪除以及配置的發布等。

• ABTest接入的開發和測試支持。用戶可以方便地查看完整可用的接入示例代碼，可以輸入分流用戶標識進行測試，以及查詢實時日志等。

• 實時報表和離線效果報表。實時報表包含實時請求、曝光和點擊等數據，效果報表支持實驗的請求/曝光/點擊/轉化等相關指標的對比，同時支持點擊率、轉化率、千次曝光轉化等指標的顯著性判斷。

• 異常監控和告警。平臺實時監控 SDK 上報的 ABTest 請求數、失敗數和延遲時間等數據，一旦發現異常即發出告警。

3.3 ABTest SDK

考慮到目前有贊的技術棧現狀，ABTest系統提供了Java和Node兩種客戶端SDK。ABTest SDK主要實現以下3種能力：

• 實驗配置動態分發。SDK實現了針對場景標識+用戶分流標識的一致性哈希算法，根據場景的實驗流量配置，進行實驗配置的動態分發。
• 上報ABTest請求日志、業務自定義日志以及監控日志。
• 基于ABTest埋點規范生成前端埋點標識。SDK 生成包括abTraceId(請求唯一標識)和bcm(請求結果標識)等追蹤標識，用以透傳到前端埋點來追蹤用戶行為。

3.4 數據流

數據流負責收集ABTest相關的日志并產出實時和離線報表數據，如下圖所示：

主要涉及以下數據組件：

• NSQ：收集SDK上報的ABTest后端請求日志和自定義上報日志
• Kafka：收集前端埋點日志和NSQ后端日志
• Flink：實時數據處理，產出實時報表數據
• Hive/Spark：離線數據處理，產出實驗效果數據和評價數據
• HBase：存儲實時報表和離線報表的數據，并支持ABTest平臺查詢
• Druid：存儲ABTest實時監控數據和抽樣日志，并支持ABTest平臺查詢

四、ABTest的可用性保障

業務方接入ABTest會有兩個核心關切，包括ABTest接入成本與易用性、ABTest數據價值，即業務方希望以盡量低的成本簡單可靠地接入ABTest，然后獲取準確且充分的ABTest度量數據。

可用性保障解決的是ABTest接入成本與易用性的問題。我們的工作主要包括提升平臺易用性、優化SDK、開發和測試方案支持以及監控和告警等方面。

提升平臺易用性

• 支持完備的ABTest元數據管理，實現較好的用戶體驗
• 實現應用級的角色和權限
• 支持場景修改配置的發布和審批
• 支持實驗的商家id或者用戶分流標識的白名單

優化Java和Node SDK

• 優化SDK性能。考慮到商詳頁Node端的場景等對CPU性能比較敏感，我們使用了很多方法來優化計算性能，包括基于推送來更新配置、使用多級緩存、簡化計算鏈路和邏輯、后端日志批量上報等(對于極端性能敏感場景，可以使用前端分流的方案)。
• 實現客戶端配置自動化和透明化。例如NSQ的配置和上報日志的開關等，均通過ABTest平臺推送來配置和更新，用戶(開發)在代碼層面不用關心。SDK因此也不依賴于用戶的配置而可以實現一些對用戶透明的能力，比如監控日志上報等。
• 優化一致性哈希算法。實驗流量配比基于權重值計算，支持最細粒度為 1/16384 的流量劃分，基于MurmurHash和模數映射實現一致性哈希，并盡量降低因流量切換帶來的體驗不一致的影響。

開發和測試方案支持

• 支持分別針對Java和Node端的示例代碼，包括引入代碼庫、初始化、獲取實驗配置以及前端埋點等。
• 支持daily、QA、預發、生產等4種應用環境。
• 支持輸入分流用戶標識獲取實驗配置，以測試和還原A/B分流結果。
• 支持實時日志明細查詢，查詢條件包括日志類型、實驗以及以及分流用戶標識等。

監控和報警

• ABTest SDK自動采集并上報性能數據。

• ABTest平臺支持監控數據的計算和基于規則的異常檢測，并接入有贊告警平臺，實現異常告警。

五、ABTest的度量數據產出

對于業務方來說，ABTest系統的核心價值在于實驗的度量數據。度量數據的產出解決的是業務方對ABTest數據價值的核心關切，即通過產出ABTest相關數據、提升數據的準確性并充分挖掘數據的意義，來科學地評價實驗的可行性和有效性。

ABTest系統的數據產出主要包括ABTest數倉數據、實時報表和監控數據以及效果報表。

5.1 數據倉庫數據

主要的ABTest相關數據都會維護到數據倉庫，包括：

• ABTest元數據維度快照表，如應用、場景、實驗和流量配置等
• ABTest日志，包括請求日志、自定義上報日志、曝光和點擊日志等
• ABTest效果數據，包括原始效果數據和效果歸因數據等
• 以上明細數據的ETL處理數據，包含中間層(dwd)、匯總層(dwa)以及產出層等粒度

5.2 實時報表和監控數據

目前實驗的實時報表主要包括實驗的請求、曝光和點擊等的5分鐘粒度匯總數據，基于Flink產出，主要用于展示ABTest場景的實時分流情況。

監控數據由ABTest SDK上報，經Flink處理后接入Druid，產出監控指標以供ABTest平臺查詢。監控指標主要為性能數據，包括ABTest請求量、請求失敗量、日志上報時延、待上報日志量、待執行和被拒絕的線程數等。ABTest平臺在應用首頁展示實時監控數據，同時后臺會定時查詢，發現異常則告警給應用負責人。

5.3 效果報表

實驗效果是指用于評價ABTest實驗表現是否好壞的數據指標，即實驗的評價標準。效果報表是ABTest平臺數據報表的核心，包含了ABTest具體實驗的評價數據，如下圖所示：

我們的主要工作包括：

通用效果模型

考慮有贊主要提供的是電商SaaS服務，有贊商家經營的主要目標是提升銷售額。因此，我們實現了基于實驗的請求→曝光+點擊→成交的轉化歸因模型，用于產出ABTest實驗的請求/曝光/點擊/支付等相關指標(如請求量、點擊量、支付金額)及其衍生指標(如點擊率、轉化率、千次曝光轉化金額)的數據。這就是ABTest平臺的通用效果模型，用于為ABTest場景提供默認的實驗度量。

效果歸因模型把曝光和點擊視為“因”，成交轉化視為“果”，優先級計算時直接效果優先于間接效果、瀏覽優于點擊優于曝光、登錄用戶id優于前端埋點標識，并采用末次歸因。

ABTest埋點規范

通用效果模型依賴于前端埋點的曝光和點擊日志的上報，即實驗場景只要執行了任意實驗，都需要上報ABTest的埋點日志。這里的曝光和點擊是指ABTest實驗的曝光和點擊，前端同學容易誤解成前端組件的曝光和點擊，導致ABTest返回不展示前端組件時而錯誤地沒有上報ABTest日志。

• 事件參數：abTraceId(必填)、bcm(選填)，均可從返回實驗配置里直接透傳到前端。
• 事件標識：曝光(事件標識包含view)；點擊(推薦頁面瀏覽事件即enterpage，參數寫入URL，或者點擊事件即事件標識包含click，二選一)。

對于ABTest接入的前端埋點成本，我們考慮使用無痕埋點的方式完全規避掉，大致方案是埋點SDK靜默生成和上報pv_id并在后端實現透傳。

支持次數和人數指標

由于曝光、點擊、支付、點擊率、轉化率以及平均曝光轉化金額等指標都涉及到次數和人數兩種口徑類型，不同的業務場景可能關注的指標類型各不相同。效果報表專門對次數和人數指標做出區分，并在前端支持查詢。

特別地，針對人數指標，考慮到跨天去重，由于ABTest平臺支持用戶選定時間范圍進行查詢，一開始我們采用HyperLogLog的基數去重計數。采用基數去重的好處是可以基于天級增量數據進行累加，可以支持用戶的靈活查詢；缺點是存在一定誤差，在某些場景比如算法優化下是不可接受的。因此我們做了支持精確去重計數的重構，基于查詢截止日期回溯枚舉30天來做精確人數計算。

區分直接和間接轉化效果

直接效果指商品效果，效果歸因時要求曝光&點擊和支付都發生在同一個商品上；間接效果即店鋪效果，效果歸因只要求是同一個店鋪。通常來說，店鋪級的優化會關注店鋪整體的影響即間接轉化效果，而直接提升商品轉化的優化則關注直接效果。

兩類效果數據ABTest平臺都有產出，并且在實驗場景的設置中支持自定義選擇。

接入自定義歸因效果數據

在ABTest的實際應用場景里，不同場景可能對轉化效果的口徑和歸因的口徑等要求各不相同，比如營銷插件(如優惠券)的轉化效果定義為插件的核銷金額，商品推薦的轉化效果定義為點擊進入推薦商品詳情頁后的成交金額。

因此，ABTest效果數據除了提供默認的通用效果模型，還支持了自定義歸因效果數據的接入，允許業務方提供定制的歸因數據口徑；而對于重要場景的歸因數據定制，我們也可以提供支持。

還有一類重要的轉化效果數據，即實驗引導的用戶行為事件。ABTest平臺計劃打通埋點系統，使用戶可以指定任意用戶行為事件作為轉化目標，從而產出用戶行為轉化效果。

反作弊過濾

考慮爬蟲和刷單等行為及其近似行為對ABTest效果的影響，單個用戶的極端行為，如大量的曝光與支付、大金額訂單，都可能會給實驗的評價指標帶來決定性的變化。因此實驗評價數據有必要對異常用戶的數據進行過濾。

我們主要結合絕對值規則和分布3σ原則，對前端日志數據和支付數據進行用戶過濾，ABTest平臺默認展示過濾后數據，同時也支持原始數據的查詢。

顯著性判斷

ABTest本質上是抽樣實驗，ABTest效果數據反映的是當前實驗覆蓋的用戶的表現現狀，考慮到樣本量和隨機性，實驗組的效果指標比基準組好不一定能說明實驗組就更好。

顯著性判斷就是基于統計學的假設檢驗方法來科學地判斷同一場景下的實驗兩兩之間到底孰優孰劣。有贊ABTest場景的樣本量較大，我們采用Z檢驗法來做假設檢驗。根據檢驗統計量：

來計算z-score及其對應的顯著性水平p-value；通過對比p-value與指定顯著性水平如95%，來判斷實驗組是否顯著好于基準組。

六、ABTest系統的評價

ABTest解決的是選擇最優策略的問題，當我們在諸多可選策略里并不清楚哪個策略是最優的時候，ABTest可以幫助我們：1)選擇更優的策略；2)避免選擇更差的策略。因此，ABTest的價值包含兩個方面，即更優策略的價值增量和更差策略的規避風險。考慮到有贊的業務場景，我們將極限提升GMV指標作為ABTest系統的北極星指標。

極限提升GMV的定義為：在擁有兩個及以上實驗的場景中，平均請求轉化金額最好的實驗對最差實驗的提升量相對于場景全部請求量的提升GMV之和，即：

其中，i為擁有兩個及以上實驗的場景，(i,j)為場景i中的實驗j，Gmv為歸因到實驗的互斥GMV，Req為實驗請求量。

極限提升GMV是一個理想的指標，度量了ABTest系統的價值。更全面的，ABTest系統的評價指標包括：

我們應該努力提升ABTest的覆蓋面，并且重點投入到GMV提升量更大、影響力更高的實驗場景中去。

七、展望和總結

7.1 展望

目前ABTest系統還遠沒達到完全成熟的狀態，接下來我們會持續投入，繼續努力提升ABTest系統的可用性和數據價值。重點工作包括：

實現ABTest前端無痕埋點，以消除前端埋點的接入成本。

增長分析接入ABTest平臺，實現ABTest數據的自助分析和數據洞察，幫助業務方更好的理解數據并優化實驗。

更豐富的自定義轉化目標，包括與埋點系統打通以及支持自定義轉化目標等。

上線評測報告功能，通過自動化產出實驗評測報告，來給場景實驗做全面充分的評價。

努力提升ABTest系統在公司的影響力，讓數據驅動增長成為小伙伴們的共識。

7.2 總結

A/B 測試是數據驅動增長的核心工具，我們希望通過構建ABTest系統來幫助產研小伙伴更好地做產品技術迭代和幫助商家更好地實現增長，從而也為我們接下來的數據驅動增長的探索奠定基礎。本文主要介紹了A/B測試的概念、ABTest系統的設計以及我們做的一些工作與思考。由于篇幅所限，很多細節沒有完整表述，歡迎有興趣的同學聯系我們一起探討，有表述錯誤的地方也歡迎指正。

對于數據驅動增長中ABTest系統沒有覆蓋到的部分，對于基于數據增長想法的產生，我們會基于增長分析來解決，嘗試跨越數據分析與業務落地的鴻溝；對于用戶行為數據等的采集和挖掘，我們基于埋點與采集平臺來解決，并構建有贊用戶行為核心數據資產。ABTest系統、增長分析平臺以及埋點與采集平臺共同構成了數據增長團隊的“增長三劍客”，我們的實踐成果會繼續在后續文章中介紹。

擴展閱讀

有贊埋點實踐

有贊埋點質量保障

Flink 滑動窗口優化

基于時間加權的用戶購買類目意愿計算

有贊推薦系統關鍵技術

有贊數據中臺建設實踐

數據資產，贊之治理

SparkSQL在有贊大數據的實踐(二)

HBase Bulkload 實踐探討

Vol.320

最后打個小廣告

有贊數據中臺團隊

長期招人，期待你的加入～

如果你是

數據增長、數據倉庫、數據產品、算法、基礎組件以及平臺系統等方面的人才

如果你也是聰明、皮實、有要性的小伙伴

如果你對電商、SaaS有更多想法

歡迎投遞簡歷：

zigu@youzan.com

加入我們，一起enjoy!

??

總結

以上是生活随笔為你收集整理的yii 使用 有赞sdk_有赞ABTest系统：数据驱动增长实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。