一、前言

1.1 什么是積分體系？

積分體系如今越來越普遍，是很多線上線下商家都會(huì)采用的用戶消費(fèi)激勵(lì)體系，例如：淘寶的金幣、京東的京豆等；此外，各大運(yùn)營商、航空公司、連鎖酒店、線下商超等也都有自己的積分玩法。積分的價(jià)值是連接用戶，增加活躍、保持用戶粘性。通過增加用戶積分價(jià)值感的手段，實(shí)現(xiàn)業(yè)務(wù)內(nèi)循環(huán)。

vivo積分體系能力已經(jīng)非常豐富，主要包括以下能力：

• 積分商城：積分體系主入口，提供豐富的禮品兌換、活動(dòng)玩法，強(qiáng)化積分價(jià)值感知
• 任務(wù)中心：重要的積分獲取入口，引導(dǎo)用戶了解業(yè)務(wù)、培養(yǎng)用戶習(xí)慣的重要玩法
• 活動(dòng)中心：提供豐富的活動(dòng)玩法，增加積分體系的可玩性和豐富度，更好地提升用戶參與度

vivo積分貫穿整個(gè)vivo生態(tài)下的互聯(lián)網(wǎng)應(yīng)用，同時(shí)手機(jī)廠商互聯(lián)網(wǎng)業(yè)務(wù)的獨(dú)特性（不僅局限于單一類型業(yè)務(wù)）也造就了vivo積分與其他行業(yè)生態(tài)積分體系的差異性，這些差異性著重體現(xiàn)在vivo積分是與各個(gè)業(yè)務(wù)形態(tài)緊密合作，相互滲透。如下圖例顯示在對應(yīng)簽到、任務(wù)中心都與業(yè)務(wù)方強(qiáng)相關(guān)聯(lián)。

在積分體系里任務(wù)體系是很重要的一環(huán)，行業(yè)內(nèi)會(huì)基于任務(wù)的形式刺激用戶活躍，引導(dǎo)用戶完成業(yè)務(wù)上高價(jià)值的行為，最終給予用戶回饋（發(fā)放積分）。

1.2 什么是任務(wù)？

玩過游戲的同學(xué)都知道，游戲內(nèi)日常都會(huì)有任務(wù)，有目的地指引玩家進(jìn)行游戲活動(dòng)，并給予玩家一定獎(jiǎng)勵(lì)。

對于積分產(chǎn)品（業(yè)務(wù)）而言，任務(wù)體系一般希望引導(dǎo)用戶了解產(chǎn)品、提高產(chǎn)品活躍度、培養(yǎng)用戶習(xí)慣，總而言之是期望用戶在使用產(chǎn)品的過程中不斷產(chǎn)生價(jià)值行為，通過直接或間接的方式幫助業(yè)務(wù)方達(dá)成業(yè)務(wù)指標(biāo)，同時(shí)用戶因完成任務(wù)得到獎(jiǎng)勵(lì)，有持續(xù)產(chǎn)生高價(jià)值行為的動(dòng)力，最終形成正向循環(huán)。

1.3 福格模型

基于以上分析我們可以看出積分任務(wù)體現(xiàn)出來的是典型的“福格模型”，通過合理的獎(jiǎng)勵(lì)去推動(dòng)符合業(yè)務(wù)價(jià)值的行為。

（圖片來自網(wǎng)絡(luò)，混沌大學(xué)）

福格行為模型是一個(gè)用來探尋用戶行為原因的模型，它認(rèn)為要讓一個(gè)行為發(fā)生，必須同時(shí)具備三個(gè)元素：動(dòng)機(jī)、能力、觸發(fā)器。

也就是說，只有當(dāng)一個(gè)人有足夠的動(dòng)機(jī)，并且有能力去做到，而且有能觸發(fā)用戶行動(dòng)的觸發(fā)器來提醒的時(shí)候，一個(gè)行為才最終可能發(fā)生。

那么vivo的任務(wù)體系是如何搭建的呢，系統(tǒng)建設(shè)又走過了哪些歷程？在本次文章中我們將為大家慢慢揭曉。

二、發(fā)展

2.1 階段一：初探

（1）業(yè)務(wù)模型分析

• 任務(wù)模型：“用戶 A 完成了 B 動(dòng)作發(fā)放 C 獎(jiǎng)勵(lì)（或者觸發(fā)某種邏輯）”，我們將滿足這種模式的需求定義為一個(gè)任務(wù)。
• 任務(wù)周期：結(jié)合業(yè)務(wù)場景，我們發(fā)現(xiàn)任務(wù)周期大致分為：新手任務(wù)（全局只能完成一次）、每日任務(wù)、每月任務(wù)。
• 任務(wù)狀態(tài)：存儲(chǔ)業(yè)務(wù)狀態(tài)，包括任務(wù)的完成狀態(tài)，以及獎(jiǎng)勵(lì)領(lǐng)取狀態(tài)。

（2）系統(tǒng)目標(biāo)

• 快速配置任務(wù)，按周期以及業(yè)務(wù)場景確定任務(wù)類型
• 記錄任務(wù)完成狀態(tài)及獎(jiǎng)勵(lì)領(lǐng)取狀態(tài)

（3）實(shí)現(xiàn)方案

注：上圖中“業(yè)務(wù)方”特指vivo生態(tài)下的服務(wù)方；“端側(cè)”特指客戶端APP。

如上圖所示，階段一的設(shè)計(jì)方案雖然有配置，但在邏輯層還是有很大的開發(fā)成本， 在階段二我們著重解決定制化開發(fā)效率的問題。

2.2 階段二：用戶行為激勵(lì)體系建設(shè)

（1）痛點(diǎn)分析

積分任務(wù)中心初版在線上運(yùn)行一段時(shí)間后發(fā)現(xiàn)，雖然任務(wù)基礎(chǔ)信息可以通過配置化完成，但遠(yuǎn)沒有達(dá)到預(yù)期：通過配置化就能夠?qū)崿F(xiàn)任務(wù)快速上線。

回顧階段一的設(shè)計(jì)，其實(shí)僅僅是引入了任務(wù)的定義與配置，但任務(wù)的行為以及達(dá)成判定都由業(yè)務(wù)方實(shí)現(xiàn)，在項(xiàng)目對接上有不少弊端：

• 跨項(xiàng)目協(xié)作周期長：跨項(xiàng)目管理難度大，進(jìn)度對齊、溝通協(xié)調(diào)，case by case開發(fā)，系統(tǒng)耦合嚴(yán)重，靈活性低，業(yè)務(wù)方邏輯重、開發(fā)成本高。
• 業(yè)務(wù)上運(yùn)營效率低：一個(gè)季度上線不了幾個(gè)任務(wù)，加上數(shù)據(jù)分析周期，整體跨度長，效果不理想。

通過分析積分任務(wù)的業(yè)務(wù)場景，我們發(fā)現(xiàn)大多數(shù)任務(wù)行為都是app端側(cè)產(chǎn)生的行為，比如用戶在瀏覽器端瀏覽新聞給予積分獎(jiǎng)勵(lì)。

結(jié)合互聯(lián)網(wǎng)業(yè)務(wù)都有日常埋點(diǎn)，我們很容易想到可結(jié)合埋點(diǎn)上報(bào)捕獲用戶行為，同時(shí)為了解決我們初版任務(wù)系統(tǒng)的弊端，我們重新梳理出vivo積分任務(wù)系統(tǒng)需要支持的核心功能點(diǎn)：

• 引入行為模型：建設(shè)集行為定義、采集、計(jì)算、觸達(dá)為一體的模型體系
• 建設(shè)行為SDK：拉取行為配置、上報(bào)行為、行為在端側(cè)支持過濾、任務(wù)完成觸達(dá)提醒
• 支持實(shí)驗(yàn)?zāi)芰Γ?/strong>支持任務(wù)灰度測試能力，同時(shí)支持基于用戶標(biāo)簽定向投放任務(wù)

（2）行為上報(bào)流程

（3）方案交互序列圖

整體流程：

• App 端啟動(dòng)時(shí)激活行為SDK拉取端側(cè)行為配置
• 行為SDK針對上報(bào)的行為埋點(diǎn)，經(jīng)過匹配、過濾、去重等策略，最終將行為上報(bào)
• 行為上報(bào)至服務(wù)端進(jìn)行用戶標(biāo)簽判斷、實(shí)驗(yàn)策略判斷、行為計(jì)算，最終將任務(wù)結(jié)果返回給行為SDK
• 行為SDK接收到響應(yīng)后將獎(jiǎng)勵(lì)結(jié)果通過toast/snackbar將配置的UI交互展示給用戶，用戶可手動(dòng)領(lǐng)取積分獎(jiǎng)勵(lì)，或者自動(dòng)發(fā)放

（4）場景示例

用戶瀏覽新聞，點(diǎn)贊資訊評論，行為SDK上報(bào)此事件，判定達(dá)成任務(wù)，返回snackbar提示用戶手動(dòng)領(lǐng)取獎(jiǎng)勵(lì)。

（5）業(yè)務(wù)效果

經(jīng)過以上升級，我們的任務(wù)系統(tǒng)可以支持以下能力：

• 涉及埋點(diǎn)型任務(wù)，業(yè)務(wù)方可以優(yōu)雅對接，不需要額外關(guān)心任務(wù)達(dá)成的判斷，直接基于SDK透傳埋點(diǎn)即可；
• 新任務(wù)可以快速支持配置，業(yè)務(wù)方一次接入，后續(xù)零成本開發(fā)；
• 基于用戶標(biāo)簽、AB實(shí)驗(yàn)平臺，支持任務(wù)實(shí)驗(yàn)配置能力，可快速驗(yàn)證任務(wù)上線效果。

上線周期大大縮短：原行為類任務(wù)從需求評審，到設(shè)計(jì)開發(fā)測試上線，再到生產(chǎn)環(huán)境灰度測試，完整的周期可由原來的1-3個(gè)月縮短至1-3人天。

2.3 階段三：擴(kuò)大行為采集源，豐富觸達(dá)形式

（1）痛點(diǎn)分析

場景引入：

某天游戲側(cè)反饋希望接入我們的任務(wù)，但場景是“給游戲付費(fèi)用戶發(fā)送積分獎(jiǎng)勵(lì)，同時(shí)要求付費(fèi)指定類型的游戲，且獎(jiǎng)勵(lì)的積分值根據(jù)付費(fèi)金額而定（不同的區(qū)間給予不同的獎(jiǎng)勵(lì)，不足1元按1元計(jì)算）”。

在剖析這個(gè)應(yīng)用場景時(shí)，我們延展發(fā)現(xiàn)以下主要痛點(diǎn)：

• 行為采集源單一：非埋點(diǎn)行為類的任務(wù)不支持
• 觸達(dá)形式單調(diào)：只支持簡單的toast以及snackbar

為了解決以上痛點(diǎn)，我們做了多方面的技術(shù)調(diào)研。

（2）業(yè)務(wù)模型

從本質(zhì)上業(yè)務(wù)模型并沒有大的變化，依然是“收集行為、判定任務(wù)關(guān)聯(lián)行為是否達(dá)成、任務(wù)的獎(jiǎng)勵(lì)發(fā)放、對用戶的觸達(dá)”，其實(shí)我們需要著重關(guān)注的是以下幾點(diǎn)：

• 行為采集源的拓展
• 支持復(fù)雜行為計(jì)算
• 動(dòng)態(tài)的規(guī)則配置

（3）數(shù)據(jù)采集層

在數(shù)據(jù)采集層上我們盡可能覆蓋更多的數(shù)據(jù)源，包括埋點(diǎn)、數(shù)據(jù)庫（MySQL）、消息隊(duì)列、API/RPC接口等，以下為當(dāng)前數(shù)據(jù)采集的數(shù)據(jù)流向圖：

采集能力完善

• 集群管理：不同的業(yè)務(wù)方、不同的任務(wù)，相應(yīng)產(chǎn)生的數(shù)據(jù)量級各不一樣，為了防止單點(diǎn)導(dǎo)致業(yè)務(wù)數(shù)據(jù)處理不及時(shí)，我們在設(shè)計(jì)上可以支持為采集任務(wù)動(dòng)態(tài)配置集群，提升消息處理及時(shí)性。
• 數(shù)據(jù)“源”管理：定義采集來源，可動(dòng)態(tài)配置RocketMQ/Kafka消息，并支持動(dòng)態(tài)創(chuàng)建監(jiān)聽器。
• 元數(shù)據(jù)管理：定義指定采集行為的基礎(chǔ)信息，包括行為事件存儲(chǔ)介質(zhì)、事件類型、過期時(shí)間、集合名等等。
• 數(shù)據(jù)預(yù)處理：主要指數(shù)據(jù)過濾，通過對比排查，我們最終選擇aviator的表達(dá)式引擎進(jìn)行過濾處理。
• 數(shù)據(jù)歸一：業(yè)務(wù)方采集的源數(shù)據(jù)定義格式各一，為了數(shù)據(jù)計(jì)算層的統(tǒng)一，我們會(huì)將元數(shù)據(jù)進(jìn)行“格式化”，便于后續(xù)統(tǒng)一處理。
• 數(shù)據(jù)存儲(chǔ)：源事件存儲(chǔ)，在存儲(chǔ)介質(zhì)選擇上我們有多維度的考量，數(shù)據(jù)量大、能夠滿足聚合計(jì)算、方便清理，最初我們選擇了ES，但通過性能測試對比，ES在聚合計(jì)算時(shí)性能有明顯的差距，最終我們選擇了MongoDB以及TiDB。

數(shù)據(jù)歸一配置示例：

（4）規(guī)則計(jì)算層

事件的采集與計(jì)算層，我們在設(shè)計(jì)上將其獨(dú)立開，采集層通過分布式消息將事件上報(bào)到計(jì)算層，經(jīng)過計(jì)算最終將結(jié)果行為異步通知到任務(wù)層。

規(guī)則配置示例：

（5）表達(dá)式引擎

再回到最初的業(yè)務(wù)場景需要“要求付費(fèi)指定類型的游戲，且獎(jiǎng)勵(lì)的積分值根據(jù)付費(fèi)金額而定（不同的區(qū)間給予不同的獎(jiǎng)勵(lì)，不足1元按1元計(jì)算）”，為了滿足業(yè)務(wù)層靈活多變的邏輯需要，我們引入了表達(dá)式引擎，便于業(yè)務(wù)靈活動(dòng)態(tài)調(diào)整。

從多個(gè)維度的技術(shù)調(diào)研，最終我們選擇AviatorScript做為我們的表達(dá)式引擎。

AviatorScript是一個(gè)高性能、輕量級的java語言實(shí)現(xiàn)的表達(dá)式求值引擎，主要用于各種表達(dá)式的動(dòng)態(tài)求值。現(xiàn)在已經(jīng)有很多開源可用的java表達(dá)式求值引擎，為什么還需要Avaitor呢？

1. Aviator的設(shè)計(jì)目標(biāo)是輕量級和高性能 ，相比于Groovy、JRuby的笨重，Aviator非常小，加上依賴包也才450K,不算依賴包的話只有70K；當(dāng)然，Aviator的語法是受限的，它不是一門完整的語言，而只是語言的一小部分集合。
2. Aviator的實(shí)現(xiàn)思路與其他輕量級的求值器很不相同，其他求值器一般都是通過解釋的方式運(yùn)行，而Aviator則是直接將表達(dá)式編譯成Java字節(jié)碼，交給JVM去執(zhí)行。

簡單來說，Aviator的定位是介于Groovy這樣的重量級腳本語言和IKExpression這樣的輕量級表達(dá)式引擎之間。

表達(dá)式引擎使用示例

// 數(shù)據(jù)清洗過濾
originEvent.pay_status == 1 && string.contains("11,12,13,14,15,16,92,93,95", originEvent.product_type + "")
// 規(guī)則計(jì)算
let value = eventObject.value / 100;
let success = value >= 1;
return seq.map('success',success,'data',value);

（6）任務(wù)層

在應(yīng)用層，用戶直觀感覺的任務(wù)層，主要包括以下邏輯：任務(wù)與行為的關(guān)聯(lián)配置、任務(wù)的投放、任務(wù)的獎(jiǎng)勵(lì)發(fā)放、用戶的觸達(dá)、用戶任務(wù)的狀態(tài)。

（7）觸達(dá)層

• 自定義彈窗：業(yè)務(wù)方可基于vivo建站平臺自動(dòng)創(chuàng)建豐富多彩的頁面交互效果，異步事件任務(wù)可以基于push中轉(zhuǎn)透傳結(jié)果。
• 消息透傳：任務(wù)結(jié)果可通過MQ消息異步傳遞至業(yè)務(wù)方端側(cè)，可消費(fèi)轉(zhuǎn)入消息盒子，或用作其他邏輯。

觸達(dá)交互示意圖：

三、整體系統(tǒng)架構(gòu)

四、服務(wù)穩(wěn)定性

4.1 系統(tǒng)防護(hù)

• 服務(wù)降級：接入限流、熔斷組件
• 集群隔離：按業(yè)務(wù)場景做服務(wù)單元隔離，避免高并業(yè)務(wù)場景影響整個(gè)服務(wù)
• 異步執(zhí)行：非核心功能異步化（例如行為軌跡）、服務(wù)依賴方接口異步（例如請求業(yè)務(wù)方發(fā)放禮品）

4.2 服務(wù)拆分

大系統(tǒng)根據(jù)業(yè)務(wù)模塊拆分，整個(gè)積分任務(wù)系統(tǒng)按業(yè)務(wù)職責(zé)主要拆分為如下幾個(gè)系統(tǒng)：

• 事件采集服務(wù)（事件采集、過濾、映射、存儲(chǔ)）
• 事件計(jì)算服務(wù)（事件計(jì)算、通知）
• 任務(wù)服務(wù)（任務(wù)判定達(dá)成、獎(jiǎng)勵(lì)觸達(dá)）

4.3 服務(wù)監(jiān)控

• 系統(tǒng)監(jiān)控：完善的CPU、日志中心告警、DB主從延時(shí)、消息積壓、慢服務(wù)等
• 數(shù)據(jù)監(jiān)控：完成的行為事件鏈路監(jiān)控，便于排查定位

五、寫在最后

5.1 任務(wù)中心建設(shè)過程感想

• 系統(tǒng)設(shè)計(jì)上需要關(guān)注業(yè)務(wù)模型抽象的能力，避免一開始就留坑；
• 系統(tǒng)防護(hù)設(shè)計(jì)，常規(guī)套路：限流、熔斷、降級、基于CAP理論執(zhí)行；
• 使用發(fā)展的眼光看待系統(tǒng)建設(shè)，系統(tǒng)的設(shè)計(jì)需要經(jīng)過反復(fù)的迭代，不斷完善，“稍稍跑在業(yè)務(wù)前面的技術(shù)架構(gòu)”可能是最理想的。

5.2 未來構(gòu)思

• 打造平臺擴(kuò)展能力：將任務(wù)能力封裝完善，能夠拓展對上層業(yè)務(wù)提供復(fù)用能力。
• 獎(jiǎng)勵(lì)平臺能力建設(shè)：當(dāng)前任務(wù)發(fā)放的獎(jiǎng)勵(lì)主要形式為vivo積分，后續(xù)可進(jìn)一步擴(kuò)展，接入全品類的獎(jiǎng)勵(lì)類型。
• 組合時(shí)序行為事件：當(dāng)前業(yè)務(wù)上只支持單行為事件的采集，還不支持行為有前后依賴關(guān)系，或者多個(gè)行為事件共同達(dá)成后完成任務(wù)。
• 實(shí)時(shí)計(jì)算能力提升：當(dāng)前設(shè)計(jì)可能存在實(shí)時(shí)性波動(dòng)的風(fēng)險(xiǎn)，例如MQ消息消耗阻塞、數(shù)據(jù)庫binlog監(jiān)聽延遲，對實(shí)時(shí)性要求高的場景不友好。

附：

1、關(guān)于用戶行為數(shù)據(jù)采集的私密性

很多人普遍認(rèn)為SDK采集數(shù)據(jù)會(huì)涉及個(gè)人隱私，這主要還是不了解SDK數(shù)據(jù)采集的技術(shù)原理。

SDK：Software Development Kit，直譯過來就是軟件開發(fā)包，用N行軟件代碼采集數(shù)據(jù)。SDK采集的任何數(shù)據(jù)都來自用戶的主觀行為，企業(yè)在正常商業(yè)活動(dòng)中獲取的個(gè)人隱私數(shù)據(jù)并不違反法規(guī)，而我們積分的任務(wù)其實(shí)是用戶有意主動(dòng)去完成行為而獲得一定的收益，同時(shí)我們也通過隱私聲明明確告知用戶且獲得用戶同意。