vivo霍金實驗平臺設(shè)計與實踐-平臺產(chǎn)品系列02
一、前言
互聯(lián)網(wǎng)企業(yè)經(jīng)歷過野蠻生長的開拓紅利期之后，逐漸越發(fā)重視產(chǎn)品發(fā)展的科學(xué)化、精細(xì)化，從粗放型向集約型轉(zhuǎn)換。在美國，增長黑客等數(shù)據(jù)驅(qū)動增長的方法論，正在幫助如Google、Microsoft、Facebook等全球科技巨頭實現(xiàn)持續(xù)的業(yè)務(wù)增長；在國內(nèi)，數(shù)據(jù)精細(xì)運(yùn)營、AB實驗分析來驅(qū)動業(yè)務(wù)有效增長也逐漸成為共識，成為核心手段。其中，A/B測試平臺作為典型代表，自然成為了國內(nèi)主流公司中必不可少的核心工具，有效的提升流量的轉(zhuǎn)化效率和產(chǎn)研的迭代效率。
在過去幾年，vivo互聯(lián)網(wǎng)持續(xù)重視科學(xué)的實驗決策，這意味著所有對用戶的改動的發(fā)布，都要決策者以相應(yīng)的實驗結(jié)論作為依據(jù)。比如，修改頂部廣告的背景色、測試一個新的廣告點擊率 (CTR) 預(yù)測算法，都需要通過實驗的方式進(jìn)行，那么一個強(qiáng)大的A/B實驗平臺就非常重要了。vivo霍金實驗平臺（以下簡稱霍金）已經(jīng)從一個單一系統(tǒng)成長為了解決A/B實驗相關(guān)問題的公司級一站式平臺，助力互聯(lián)網(wǎng)核心業(yè)務(wù)的快速、準(zhǔn)確實驗，高效推動業(yè)務(wù)增長。
二、項目介紹
2.1 A/B實驗
在互聯(lián)網(wǎng)領(lǐng)域，A/B實驗通常指一種迭代方法，這種方法可以指導(dǎo)如何改進(jìn)現(xiàn)有產(chǎn)品或者服務(wù)。以提升某個產(chǎn)品下單轉(zhuǎn)化率為例，AB實驗過程中，我們設(shè)計了新的下單頁面，和原頁面相比，頁面布局和文案做了調(diào)整。我們將用戶流量隨機(jī)分成A/B兩組（分別對應(yīng)新舊頁面），50%用戶看到A版本頁面，50%用戶看到B版本頁面，經(jīng)過一段時間的觀察和統(tǒng)計，發(fā)現(xiàn)A版本用戶下單轉(zhuǎn)化率為70%，高于B版本的50%。那么我們得出A版本效果好，進(jìn)而將新頁面推送并展示給所有用戶。
以上就是一個利用AB測試迭代產(chǎn)品功能的具體應(yīng)用，我們將A/B實驗的完整生命周期分為三個階段：
- 實驗前，明確改進(jìn)目標(biāo)，定義實驗指標(biāo)，完成相關(guān)功能開發(fā)和上線；
- 實驗中，制定每個實驗組流量比例，按照分流比例開放線上流量進(jìn)行測試；
- 實驗后，實驗效果評估并決策。
2.2 分層實驗?zāi)Ｐ?/span>
霍金的分層實驗?zāi)Ｐ蛥⒖脊雀璋l(fā)布的重疊實驗框架論文：《??Overlapping Experiment Infrastructure: More, Better, Faster Experimentation??》完成設(shè)計。
2.3 平臺發(fā)展及在vivo業(yè)務(wù)中的應(yīng)用和價值
霍金啟動于2019年，歷經(jīng)三年多的發(fā)展，目前日均實驗數(shù)量達(dá)到900多個，高峰期1000+。
- 支撐vivo國內(nèi)與海外業(yè)務(wù)，服務(wù)公司20多個部門。
- 通過標(biāo)準(zhǔn)化的實驗流程降低了實驗門檻，提升實驗效率。
- 通過自動化的數(shù)據(jù)分析工具輔助業(yè)務(wù)快速決策，提升產(chǎn)品迭代速度，有效助力業(yè)務(wù)發(fā)展。
- 平臺能力復(fù)用，避免不同組織重復(fù)建設(shè)的情況，有效的提升了生產(chǎn)效率。
三、霍金系統(tǒng)架構(gòu)
3.1【實驗人員】
實驗人員包含多個角色，供業(yè)務(wù)方在霍金管理后臺進(jìn)行實驗、指標(biāo)的管理和實驗效果的分析。
3.2【實驗門戶】
包括兩部分功能：實驗管理和實驗效果分析。
3.2.1 實驗管理
平臺提供可視化頁面供業(yè)務(wù)方進(jìn)行實驗配置、分流策略的選擇、流量的分配以及白名單的管理。
3.2.2 實驗效果分析
包括如下4個核心能力：
1. 指標(biāo)管理
不同實驗關(guān)注指標(biāo)不同，為了實現(xiàn)效果評估自動化，平臺提供了指標(biāo)配置和集成能力。
【必看指標(biāo)】：通常為業(yè)務(wù)核心指標(biāo)，每個實驗都需要保障不能有明顯負(fù)向的指標(biāo)，平臺通過集成大數(shù)據(jù)指標(biāo)管理系統(tǒng)，這部分指標(biāo)結(jié)果直接復(fù)用指標(biāo)管理系統(tǒng)的數(shù)據(jù)服務(wù)。
【個性化指標(biāo)】：通常為實驗中臨時分析的指標(biāo)，如某banner樣式實驗，觀察的指定banner的曝光點擊率。平臺提供了自定義指標(biāo)配置的能力，并通過大數(shù)據(jù)計算平臺自動生成計算任務(wù)，實現(xiàn)自定義指標(biāo)自動化產(chǎn)出數(shù)據(jù)的能力。
2. 對比分析和顯著性結(jié)論
效果評估的可視化展示，平臺沉淀了對比分析和顯著性結(jié)論等可視化組件。非常直觀的告知實驗者，每個實驗方案相比對照方案整體提升幅度以及每日的漲跌幅。同時給出指標(biāo)的置信區(qū)間和顯著性結(jié)論。
3. AA分析
平臺提供的AA分析，目的是幫助實驗者驗證實際進(jìn)入實驗的不同方案的人群，實驗前在業(yè)務(wù)核心指標(biāo)上是否存在顯著差異，輔助實驗者判斷實驗結(jié)論是否可靠。
4.分流實時監(jiān)控
可以直觀的看到實時分流的效果，針對流量異常可以及時人工干預(yù)和解決。
3.3 【實驗分流服務(wù)】
1. 多端接入服務(wù)
平臺根據(jù)業(yè)務(wù)的不同訴求提供豐富的接入能力，如針對安卓客戶端的Android SDK、服務(wù)端的JAVA SDK、基于NGINX進(jìn)行分流的H5實驗服務(wù)、dubbo/http服務(wù)，C++ SDK待建設(shè)。
2.實驗分流的方式
平臺提供了穩(wěn)定高效的在線實時分流服務(wù)。
- 【隨機(jī)分流】：根據(jù)用戶標(biāo)識符基于哈希算法對人群進(jìn)行隨機(jī)分組并分流
- 【指定人群分流】：實驗前圈定一撥人群并打上標(biāo)簽進(jìn)行分流
- 【協(xié)變量均勻分流】：在基于哈希算法對人群隨機(jī)分組的時候，雖然分組的人群數(shù)量等比例劃分，但是分組的人群分布的指標(biāo)存在不均勻的情況，導(dǎo)致實驗效果達(dá)不到預(yù)期。為了解決這個痛點，平臺推出了協(xié)變量平衡算法，
該算法能夠保證人群在進(jìn)行分組樣本量均勻的同時，人群上指標(biāo)分布也是均勻的。
詳見本文：4. vivo霍金實驗平臺實踐→4.1 協(xié)變量平衡算法 的詳細(xì)介紹。
- 【基于openresty web服務(wù)分流】：針對服務(wù)端非JAVA語言，對性能有著嚴(yán)苛要求的業(yè)務(wù)方，我們在NGINX基于OpenResty采用lua腳本實現(xiàn)了一套實驗分流功能，以http接口提供服務(wù)，平均響應(yīng)時間小于1ms，p9999<20ms。
3.4 【分流數(shù)據(jù)處理服務(wù)】
采用公司統(tǒng)一的數(shù)據(jù)采集組件進(jìn)行分流數(shù)據(jù)的采集、加工，并最終存儲至HDFS。
3.5【指標(biāo)計算服務(wù)】
獨立的服務(wù)用于高效計算指標(biāo)結(jié)果，同時配備了指標(biāo)計算失敗重試和監(jiān)控告警機(jī)制，有效的保證了指標(biāo)計算成功率。
3.6【數(shù)據(jù)存儲】
主要是利用MySQL來進(jìn)行業(yè)務(wù)數(shù)據(jù)的存儲，同時采用Ehcahe進(jìn)行實驗配置的主要緩存，Redis作為輔助緩存，最后實驗分流的數(shù)據(jù)經(jīng)過加工處理后保存到HDSF中，供后續(xù)的實驗數(shù)據(jù)分析使用。
四、霍金實踐
上面介紹了霍金的發(fā)展情況以及整體的系統(tǒng)架構(gòu)，接下來介紹下在平臺發(fā)展過程中遇到的問題以及對應(yīng)的解決方案。
4.1 協(xié)變量平衡算法
4.1.1 遇到的問題
業(yè)務(wù)方在進(jìn)行實驗對象分組的時候，最常用的做法是根據(jù)實驗對象的某個屬性進(jìn)行哈希后對100取模，根據(jù)結(jié)果分到不同組。雖然hash算法分流可以做到尾號號段分布均勻，但是分完組后，可能存在不同組的實驗對象在某些指標(biāo)特征上分布不勻均，導(dǎo)致實驗效果評估不準(zhǔn)確。如下圖所示（圖中四個不同顏色代表不同的人群以及對應(yīng)的指標(biāo)類型）：
有沒有一種方式能夠?qū)崿F(xiàn)對人群進(jìn)行均勻分組的同時，保證人群對應(yīng)的指標(biāo)分布也是均勻的呢，如下圖所示：
4.1.2 解決方案
1. 協(xié)變量平衡算法
該算法能夠保證對人群進(jìn)行均勻分組的同時，人群對應(yīng)的指標(biāo)分布也是均勻的。整體由三部分組成，示意圖如下：
（1）離線分層抽樣
需要經(jīng)歷如下3個步驟：
- 和業(yè)務(wù)方確定核心指標(biāo)
- 采用等比例分層+Kmeans聚類模型完成指標(biāo)對應(yīng)的用戶的分層抽樣
- 將分層抽樣好的數(shù)據(jù)寫入hive庫相關(guān)表中
這里介紹下等比例分層抽樣
等比例分層抽樣：
第i層應(yīng)抽取的樣本數(shù)量；第i層的總體樣本數(shù)量；N 全體可用的流量總數(shù)；n 本次實驗設(shè)定的流量樣本數(shù)量
假設(shè)N為3kw，n為50w。按照以下維度進(jìn)行分類：
共有9種組合，確定每種組合別在總量中的占比（總數(shù)N=3kw，通過在全體可用流量中篩取特定人群）：
通過公式計算得到每層的樣本數(shù)量；對應(yīng)分類的樣本數(shù)量（總樣本量60w）：
至此完成了整個離線分層抽樣的工作，接下來介紹下實時均勻分組。
（2）實時均勻分組
需要經(jīng)歷如下4個步驟：
- 數(shù)據(jù)同步
通過配置的定時任務(wù)將準(zhǔn)備好的分層抽樣數(shù)據(jù)由hive庫相關(guān)表同步至redis，數(shù)據(jù)包括每天的用戶標(biāo)識符（uid，下同）到層的映射，以及每天每層所擁有的用戶占比。
- 實驗創(chuàng)建
通過實驗編號，實驗組編號和每個實驗組的樣本量創(chuàng)建實驗。創(chuàng)建的實驗會與當(dāng)前最新一天的用戶數(shù)據(jù)相關(guān)聯(lián)，通過 樣本量 * 層用戶占比可以確定該層每個實驗組的樣本量。
- 實驗分流
通過實驗編號和用戶標(biāo)識符（uid） 先找到用戶所在的層，之后將用戶均勻的分配到該層下的實驗組中，保證實驗組之間在不同層上分流的用戶均勻。如下圖所示：
- 用戶數(shù)據(jù)刪除
因為我們采取的方案需要每天同步大量數(shù)據(jù)，所以對于無用的用戶數(shù)據(jù)需要及時刪除，增加資源利用率。
實時均勻分組整體流程圖如下：
在做實時均勻分組的時候，面臨性能和存儲的壓力，為此我們分別設(shè)計了高性能分流方案和高內(nèi)存利用率用戶信息存儲方案設(shè)計。
高性能分流方案
我們通過不同的redis數(shù)據(jù)結(jié)構(gòu)和lua腳本完成層下桶的均勻分配
方案1
預(yù)先分配每一個桶的樣本量，每次選出當(dāng)前樣本量最多的桶
Redis結(jié)構(gòu)：HASH，field為對應(yīng)的桶編號，value為桶對應(yīng)的當(dāng)前樣本量
方案2
預(yù)先分配每一個桶的樣本量，每次選出當(dāng)前樣本量最多的桶
Redis結(jié)構(gòu)：SORTED SET，key為對應(yīng)的桶編號，score為桶對應(yīng)的當(dāng)前樣本量
方案3
通過當(dāng)前層樣本量與桶大小取模選出命中的桶
Redis結(jié)構(gòu)：HASH
方案1：在只有兩個桶時擁有最高的性能，是方案3的1.05倍，但其性能隨著桶的增多而線性減少。
方案2：擁有穩(wěn)定的性能。
方案3：擁有穩(wěn)定的性能，但性能是方案2的1.12倍，是單GET請求性能的58%。
綜合考慮選擇方案3。
高內(nèi)存利用率用戶信息存儲方案設(shè)計
uid-層的內(nèi)存消耗對比
方案1：使用redis string存儲。
方案2：分為10000個hash存儲。
方案3：分為10000個一級桶，每個一級桶下有125個二級桶。
假設(shè)uid為15位數(shù)字，層id為2位數(shù)字，考慮過期時間，不考慮cluser模式下的額外消耗，不考慮malloc內(nèi)存碎片和占用。
綜合考慮選擇方案3。
（3）離線分析驗證
因為協(xié)變量算法實驗流程比較復(fù)雜，所以我們還是采用人工取數(shù)的方式進(jìn)行實驗效果的分析。
4.2 Java SDK
4.2.1 遇到的問題
早期Java SDK的能力較弱，只提供了分流，需要接入方上報分流結(jié)果數(shù)據(jù)，對接入方而言改造成本較大；故當(dāng)時主要以Dubbo接口對外分流服務(wù)，在服務(wù)內(nèi)由平臺服務(wù)端統(tǒng)一進(jìn)行分流結(jié)果數(shù)據(jù)的上報。
隨著接入方越來越多，頻繁發(fā)生Dubbo線程池耗盡、或者因為網(wǎng)絡(luò)原因?qū)е路至魇〉那闆r發(fā)生，導(dǎo)致分流體驗很差，影響實驗效果分析；面對上述問題，平臺除了不斷地做性能優(yōu)化外，還需要不停的對應(yīng)用服務(wù)器等資源做擴(kuò)容，造成一定的資源浪費(fèi)。
4.2.2 解決方案
針對上述情況，霍金開發(fā)團(tuán)隊經(jīng)過充分的技術(shù)方案研究，對Java SDK進(jìn)行了數(shù)次升級，成功解決上述問題。目前具備了實驗分流、分流結(jié)果的上報、實驗配置實時&增量更新、SDK自監(jiān)控等核心功能，極大的提升了分流的穩(wěn)定性和成功率。
4.2.3 SDK6大核心能力
1. 分流結(jié)果上報
在SDK內(nèi)部依托公司的數(shù)據(jù)采集組件進(jìn)行分流結(jié)果的上報。
2. 分流結(jié)果上報失敗的兜底方案
在進(jìn)行分流上報的時候，因為數(shù)據(jù)鏈路無法保證數(shù)據(jù)100%的完整性，如果遇到機(jī)器宕機(jī)，業(yè)務(wù)服務(wù)異常，網(wǎng)絡(luò)異常等情況，實驗分流數(shù)據(jù)上報失敗，直接影響實驗效果分析。
如何保證在任何情況下實驗分流數(shù)據(jù)100%不丟失，為此霍金實驗平臺設(shè)計了一套分流數(shù)據(jù)落磁盤的方案，作為異常場景的兜底措施，從而100%保證了數(shù)據(jù)的完整性，設(shè)計圖如下：
3. 實驗配置實時&增量更新
在通過定時任務(wù)拉取實驗配置至業(yè)務(wù)方本地緩存的方式外，還提供了實時和增量更新，適用于對實驗配置變更時效性要求高的業(yè)務(wù)，可以通過開關(guān)控制，動態(tài)生效，默認(rèn)采用實時增量更新 + 定期全量更新，方便業(yè)務(wù)方靈活使用。下面是配置實時與增量更新的流程圖：
在實時更新發(fā)生失敗的情況下，我們設(shè)計了失敗退避策略：采用指數(shù)級失敗退避策略, 默認(rèn)長輪詢的間隔為1s，每次失敗間隔增加2倍, 最大為60, 所以增長序列為1, 2, 4, 8, 16, 32, 60；每次成功將間隔置為1。
此外我們做了數(shù)據(jù)最終一致性的保證，保證SDK拉取配置時最終可以拉取到最新的配置，且不會出現(xiàn)配置回退：
- 實驗信息和模塊信息緩存的刷新是線性的。
- 同一次變更的實驗信息緩存的刷新在模塊信息緩存刷新之前（發(fā)送緩存刷新消息時保證實驗緩存刷新消息在模塊緩存刷新消息之前）。
- 模塊信息緩存的刷新時不會出現(xiàn)版本號跳躍問題（緩存方法入?yún)⒓由习姹咎枺⑿戮彺鏁r將數(shù)據(jù)庫的版本號與傳入的版本號對比，如果版本號不一致則打印日志并使用傳入的版本號作為此次緩存刷新的版本號）。
- SDK拉取配置并更新本地配置時，只更新拉取配置版本號大于等于本地配置版本號的配置
4. 多級配置管理
SDK 支持多級配置管理，優(yōu)先級依次為：方法入?yún)⒌呐渲?原有) > 業(yè)務(wù)方配置中心灰度配置 > 業(yè)務(wù)方配置中心配置 > 遠(yuǎn)程默認(rèn)配置 > 本地默認(rèn)配置；業(yè)務(wù)方配置中心灰度配置是指在配置中心通過配置指定機(jī)器ip進(jìn)行功能灰度。
5. 分流策略兜底
采用SDK痛點之一是新增功能后需要業(yè)務(wù)方隨之升級，否則新功能無法使用，進(jìn)而影響業(yè)務(wù)。為此霍金設(shè)計了一套兜底方案，在SDK中探測到新增的策略不存在時，通過dubbo泛化調(diào)用的方式訪問霍金服務(wù)器，保證分流功能正常；有效的保證業(yè)務(wù)方有充足的時間升級到最新版本，提升用戶體驗。
6. SDK監(jiān)控告警
采用SDK的另一個痛點是SDK集成在業(yè)務(wù)方服務(wù)端的進(jìn)程中，所打印的錯誤信息自己看不到，依賴業(yè)務(wù)方的反饋，顯得很被動，不能第一時間跟進(jìn)處理和解決問題；針對這種情況，霍金實驗平臺設(shè)計一套SDK自監(jiān)控方案。
自監(jiān)控數(shù)據(jù)按照時間精度預(yù)聚合后通過埋點域名上報到通用監(jiān)控，自監(jiān)控支持內(nèi)銷，新加坡和印度環(huán)境。通過監(jiān)控我們可以直觀的看到每個業(yè)務(wù)、實驗、SDK版本等維度是否存在錯誤信息，并根據(jù)相應(yīng)維度配置告警，方便開發(fā)人員第一時間跟進(jìn)處理和解決問題。
4.3 H5實驗
4.3.1 遇到的問題
業(yè)界在做H5實驗時，通常做法是開發(fā)H5 SDK，讓業(yè)務(wù)方前端引入。
存在如下幾個問題：
- 需要業(yè)務(wù)方前端做代碼改動進(jìn)行適配
- 另外需要對實驗的頁面或者元素做遮罩，因存在頁面跳轉(zhuǎn)對用戶體驗有一定影響
- 實驗功能發(fā)生變化時，需要業(yè)務(wù)方升級H5 SDK
- 整個H5實驗接入周期比較長，存在一定的接入門檻
4.3.2 解決方案
那么有沒有一種簡單快捷的方式，只需要接入方在后臺配置完實驗就完成整個H5實驗的接入呢？為此霍金開發(fā)團(tuán)隊設(shè)計了一套方案順利解決了該問題，整個H5實驗架構(gòu)基于開源apisix搭建，業(yè)務(wù)方在霍金管理后臺創(chuàng)建實驗時，所有基于nginx的路由配置全部自動化通過接口下發(fā)完成（配合工單審核），無需接入方在代碼層面做任何修改，無侵入性，大大提升業(yè)務(wù)方做H5實驗的效率。
這里解釋下幾個名詞：
- 【公共VUA】：vivo unified access。vivo統(tǒng)一接入層，可以理解是后續(xù)替換nginx的產(chǎn)品，基于開源apisix搭建。
- 【霍金VUA】：為霍金單獨搭建的VUA平臺，做H5實驗時，公共VUA將需要做實驗的頁面代理到霍金VUA，霍金VUA通過開發(fā)的霍金分流APISIX插件完成實驗分流。
- 【VUA變更平臺】：基于NGINX的配置變更通過在該平臺上可視化操作后下發(fā)至VUA平臺（公共VUA/霍金VUA）。
（1）H5實驗的整體時序圖
（2）NGINX → VUA 分流方案切換
公共VUA將需要做實驗的頁面代理到霍金VUA，霍金VUA通過開發(fā)的霍金實驗平臺分流APISIX插件完成實驗分流。
多版本實驗分流
1）H5多版本實驗介紹
同一個url做實驗，通過霍金分流，不同用戶訪問到的url都是相同的，但是頁面訪問內(nèi)容不同（因為多版本實驗是將頁面版本資源發(fā)布到不同的機(jī)器上），然后通過霍金實驗平臺分流訪問不同的資源。
2）H5多版本實驗分流原理
- 公共VUA將多版本實驗對應(yīng)的靜態(tài)資源請求代理到霍金VUA。
- 霍金VUA通過APISIX插件 按照實驗配置選擇upstream并代理到對應(yīng)的靜態(tài)資源服務(wù)器。
3）流程示意圖
- 多版本實驗分流
- 多頁面實驗分流
- 霍金實驗平臺分流APISIX插件
- H5實驗的分流數(shù)據(jù)采集
多頁面實驗分流
1）H5多頁面實驗介紹
多個不同url做實驗，通過霍金分流，不同用戶訪問到不同的url頁面。
2）H5多頁面實驗原理
- 公共VUA將多頁面實驗對應(yīng)的入口業(yè)務(wù)路徑的靜態(tài)資源請求代理到霍金VUA。
- 霍金VUA通過APISIX插件 按照實驗配置重寫路徑到不同的頁面。
3）流程示意圖
霍金實驗平臺分流APISIX插件
流程示意圖如下：
插件開發(fā)規(guī)范參考：
??https://apisix.apache.org/zh/docs/apisix/plugin-develop??
H5實驗的分流數(shù)據(jù)采集
H5實驗的分流數(shù)據(jù)保存在霍金VUA平臺的access_log中，經(jīng)過如下幾個步驟最終存入HIVE庫的DW表中，供后續(xù)的數(shù)據(jù)分析使用。
五、實驗效果分析
該模塊包括指標(biāo)服務(wù)、數(shù)據(jù)分析與效果展示、準(zhǔn)實時指標(biāo)計算、AA分析等功能，因篇幅有限，不在此展開。
六、總結(jié)與展望
本文主要通過介紹A/B實驗在vivo的平臺化、產(chǎn)品化的建設(shè)和實踐，實現(xiàn)了以下的價值和能力：
- 用戶可在平臺上完成創(chuàng)建實驗-數(shù)據(jù)分析-決策-調(diào)整實驗的閉環(huán)，操作簡單，靈活性高；
- 提供科學(xué)可靠的多層分流算法，流量可復(fù)用，無需發(fā)版即可快速驗證產(chǎn)品方案、運(yùn)營策略、優(yōu)化算法；
- 提供實時實驗分流監(jiān)控、小時級的指標(biāo)監(jiān)控以及離線數(shù)據(jù)分析功能；
- 支持自定義指標(biāo)，無需等待分析師開發(fā)報表，即配即查。
但還存在用戶體驗等問題，后續(xù)我們會重點在實驗流程，數(shù)據(jù)服務(wù)功能諸如指標(biāo)配置（常用指標(biāo)固化、指標(biāo)配置簡化）和數(shù)據(jù)展示（交互優(yōu)化、多維分析、歸因分析）等進(jìn)行優(yōu)化和完善，持續(xù)提升用戶體驗。
參考資料：
