技術文章 » vivo積分任務體系的架構演進-平臺產品系列05

vivo積分任務體系的架構演進-平臺產品系列05

2023-05-04 12:00:27

作者：vivo 網際網路平臺產品研發團隊- Mu JunFeng

積分體系作為一種常見行銷工具，幾乎是每一家企業會員行銷的必備功能之一，在生活中隨處可見，隨著vivo網際網路業務發展，vivo積分體系的能力也隨之得到飛速提升，本篇主要介紹vivo積分任務體系的系統建設歷程。

一、前言

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監聽延遲，對實時性要求高的場景不友好。

附：

關於使用者行為資料採集的私密性：很多人普遍認為SDK採集資料會涉及個人隱私，這主要還是不瞭解SDK資料採集的技術原理。

 

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