一、前言

1.1 什么是積分體系？

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

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

• 積分商城：積分體系主入口，提供豐富的禮品兌換、活動玩法，強化積分價值感知
• 任務中心：重要的積分獲取入口，引導用戶了解業務、培養用戶習慣的重要玩法
• 活動中心：提供豐富的活動玩法，增加積分體系的可玩性和豐富度，更好地提升用戶參與度

vivo積分貫穿整個vivo生態下的互聯網應用，同時手機廠商互聯網業務的獨特性（不僅局限于單一類型業務）也造就了vivo積分與其他行業生態積分體系的差異性，這些差異性著重體現在vivo積分是與各個業務形態緊密合作，相互滲透。如下圖例顯示在對應簽到、任務中心都與業務方強相關聯。

在積分體系里任務體系是很重要的一環，行業內會基于任務的形式刺激用戶活躍，引導用戶完成業務上高價值的行為，最終給予用戶回饋（發放積分）。

1.2 什么是任務？

玩過游戲的同學都知道，游戲內日常都會有任務，有目的地指引玩家進行游戲活動，并給予玩家一定獎勵。

對于積分產品（業務）而言，任務體系一般希望引導用戶了解產品、提高產品活躍度、培養用戶習慣，總而言之是期望用戶在使用產品的過程中不斷產生價值行為，通過直接或間接的方式幫助業務方達成業務指標，同時用戶因完成任務得到獎勵，有持續產生高價值行為的動力，最終形成正向循環。

1.3 福格模型

基于以上分析我們可以看出積分任務體現出來的是典型的“福格模型”，通過合理的獎勵去推動符合業務價值的行為。

（圖片來自網絡，混沌大學）

福格行為模型是一個用來探尋用戶行為原因的模型，它認為要讓一個行為發生，必須同時具備三個元素：動機、能力、觸發器。

也就是說，只有當一個人有足夠的動機，并且有能力去做到，而且有能觸發用戶行動的觸發器來提醒的時候，一個行為才最終可能發生。

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

二、發展

2.1 階段一：初探

（1）業務模型分析

• 任務模型：“用戶 A 完成了 B 動作發放 C 獎勵（或者觸發某種邏輯）”，我們將滿足這種模式的需求定義為一個任務。
• 任務周期：結合業務場景，我們發現任務周期大致分為：新手任務（全局只能完成一次）、每日任務、每月任務。
• 任務狀態：存儲業務狀態，包括任務的完成狀態，以及獎勵領取狀態。

（2）系統目標

• 快速配置任務，按周期以及業務場景確定任務類型
• 記錄任務完成狀態及獎勵領取狀態

（3）實現方案

注：上圖中“業務方”特指vivo生態下的服務方；“端側”特指客戶端APP。

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

2.2 階段二：用戶行為激勵體系建設

（1）痛點分析

積分任務中心初版在線上運行一段時間后發現，雖然任務基礎信息可以通過配置化完成，但遠沒有達到預期：通過配置化就能夠實現任務快速上線。

回顧階段一的設計，其實僅僅是引入了任務的定義與配置，但任務的行為以及達成判定都由業務方實現，在項目對接上有不少弊端：

• 跨項目協作周期長：跨項目管理難度大，進度對齊、溝通協調，case by case開發，系統耦合嚴重，靈活性低，業務方邏輯重、開發成本高。
• 業務上運營效率低：一個季度上線不了幾個任務，加上數據分析周期，整體跨度長，效果不理想。

通過分析積分任務的業務場景，我們發現大多數任務行為都是app端側產生的行為，比如用戶在瀏覽器端瀏覽新聞給予積分獎勵。

結合互聯網業務都有日常埋點，我們很容易想到可結合埋點上報捕獲用戶行為，同時為了解決我們初版任務系統的弊端，我們重新梳理出vivo積分任務系統需要支持的核心功能點：

• 引入行為模型：建設集行為定義、采集、計算、觸達為一體的模型體系
• 建設行為SDK：拉取行為配置、上報行為、行為在端側支持過濾、任務完成觸達提醒
• 支持實驗能力：支持任務灰度測試能力，同時支持基于用戶標簽定向投放任務

（2）行為上報流程

（3）方案交互序列圖

整體流程：

• App 端啟動時激活行為SDK拉取端側行為配置
• 行為SDK針對上報的行為埋點，經過匹配、過濾、去重等策略，最終將行為上報
• 行為上報至服務端進行用戶標簽判斷、實驗策略判斷、行為計算，最終將任務結果返回給行為SDK
• 行為SDK接收到響應后將獎勵結果通過toast/snackbar將配置的UI交互展示給用戶，用戶可手動領取積分獎勵，或者自動發放

（4）場景示例

用戶瀏覽新聞，點贊資訊評論，行為SDK上報此事件，判定達成任務，返回snackbar提示用戶手動領取獎勵。

（5）業務效果

經過以上升級，我們的任務系統可以支持以下能力：

• 涉及埋點型任務，業務方可以優雅對接，不需要額外關心任務達成的判斷，直接基于SDK透傳埋點即可；
• 新任務可以快速支持配置，業務方一次接入，后續零成本開發；
• 基于用戶標簽、AB實驗平臺，支持任務實驗配置能力，可快速驗證任務上線效果。

上線周期大大縮短：原行為類任務從需求評審，到設計開發測試上線，再到生產環境灰度測試，完整的周期可由原來的1-3個月縮短至1-3人天。

2.3 階段三：擴大行為采集源，豐富觸達形式

（1）痛點分析

場景引入：

某天游戲側反饋希望接入我們的任務，但場景是“給游戲付費用戶發送積分獎勵，同時要求付費指定類型的游戲，且獎勵的積分值根據付費金額而定（不同的區間給予不同的獎勵，不足1元按1元計算）”。

在剖析這個應用場景時，我們延展發現以下主要痛點：

• 行為采集源單一：非埋點行為類的任務不支持
• 觸達形式單調：只支持簡單的toast以及snackbar

為了解決以上痛點，我們做了多方面的技術調研。

（2）業務模型

從本質上業務模型并沒有大的變化，依然是“收集行為、判定任務關聯行為是否達成、任務的獎勵發放、對用戶的觸達”，其實我們需要著重關注的是以下幾點：

• 行為采集源的拓展
• 支持復雜行為計算
• 動態的規則配置

（3）數據采集層

在數據采集層上我們盡可能覆蓋更多的數據源，包括埋點、數據庫（MySQL）、消息隊列、API/RPC接口等，以下為當前數據采集的數據流向圖：

采集能力完善

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

數據歸一配置示例：

（4）規則計算層

事件的采集與計算層，我們在設計上將其獨立開，采集層通過分布式消息將事件上報到計算層，經過計算最終將結果行為異步通知到任務層。

規則配置示例：

（5）表達式引擎

再回到最初的業務場景需要“要求付費指定類型的游戲，且獎勵的積分值根據付費金額而定（不同的區間給予不同的獎勵，不足1元按1元計算）”，為了滿足業務層靈活多變的邏輯需要，我們引入了表達式引擎，便于業務靈活動態調整。

從多個維度的技術調研，最終我們選擇AviatorScript做為我們的表達式引擎。

AviatorScript是一個高性能、輕量級的java語言實現的表達式求值引擎，主要用于各種表達式的動態求值。現在已經有很多開源可用的java表達式求值引擎，為什么還需要Avaitor呢？

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

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

表達式引擎使用示例

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

（6）任務層

在應用層，用戶直觀感覺的任務層，主要包括以下邏輯：任務與行為的關聯配置、任務的投放、任務的獎勵發放、用戶的觸達、用戶任務的狀態。

（7）觸達層

• 自定義彈窗：業務方可基于vivo建站平臺自動創建豐富多彩的頁面交互效果，異步事件任務可以基于push中轉透傳結果。
• 消息透傳：任務結果可通過MQ消息異步傳遞至業務方端側，可消費轉入消息盒子，或用作其他邏輯。

觸達交互示意圖：

三、整體系統架構

四、服務穩定性

4.1 系統防護

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

4.2 服務拆分

大系統根據業務模塊拆分，整個積分任務系統按業務職責主要拆分為如下幾個系統：

• 事件采集服務（事件采集、過濾、映射、存儲）
• 事件計算服務（事件計算、通知）
• 任務服務（任務判定達成、獎勵觸達）

4.3 服務監控

• 系統監控：完善的CPU、日志中心告警、DB主從延時、消息積壓、慢服務等
• 數據監控：完成的行為事件鏈路監控，便于排查定位

五、寫在最后

5.1 任務中心建設過程感想

• 系統設計上需要關注業務模型抽象的能力，避免一開始就留坑；
• 系統防護設計，常規套路：限流、熔斷、降級、基于CAP理論執行；
• 使用發展的眼光看待系統建設，系統的設計需要經過反復的迭代，不斷完善，“稍稍跑在業務前面的技術架構”可能是最理想的。

5.2 未來構思

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

附：

1、關于用戶行為數據采集的私密性

很多人普遍認為SDK采集數據會涉及個人隱私，這主要還是不了解SDK數據采集的技術原理。

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