一個實時精準觸達系統的自我修養
問題定義
在網際網路行業,唯一不變的就是一直在變化。作為技術同學,我們經常會碰到以下幾種需求:
當使用者收藏的商品降價後及時通知使用者,促進雙方交易達成;新使用者或90天內未成交的使用者瀏覽多個商品後引導使用者主動和賣家聊天、也可以給使用者發個紅包促進使用者首單的達成;
這些需求本質上是這樣的邏輯:實時採集分析使用者行為,透過規則計算,對符合條件的使用者進行精準觸達。普通開發模式很難比較好的承接這類需求,為此我們專門研發了omega系統解決這類問題。omega系統分為三個子系統:
-
使用者觸達中心
我們在之前文章已經詳細說明前兩部分,本次我們將著重闡述使用者觸達系統是如何設計和實現策略靈活配置和精準觸達的。
系統設計
2.1、邏輯架構
為了方便讀者理解,我們簡單回顧omega系統的邏輯架構。omega系統基於高內舉低耦合的原則進行拆分,每個部分本身是獨立完整的系統,也可以組裝後提供服務。
-
第一層是使用者行為採集中心,透過採集端上請求的MTOP(應用閘道器)介面和端上使用者行為埋點,將資料清洗為規整的使用者行為資料;
-
第二層是CEP規則計算中心,透過解析DSL生成Blink(Flink)流計算任務,輸出滿足規則的使用者;
-
第三層為使用者觸達中心,定義觸達策略和通道,將策略實時觸達給使用者。
三層環環相扣,既可單獨對外提供服務,也可聯合對外承接業務,目前已經在承接使用者增長、玩法和安全相關業務。
以使用者增長業務舉例,當使用者在體驗的過程中,運營透過合理策略組合,引導使用者完成交易行為,到達產品形態上的“啊哈”時刻。這些策略在端內可能是權益透出、POP和實時Push,在端外是Push、簡訊和外呼等手段。Omega系統透過整合端內/端外的主動/被動觸達渠道,以使用者的實時狀態為核心,實現了一套滿足長週期運營的策略編排技術方案體系。
2.2、觸達流程
觸達流程本身比較明確,我們將流程拆分為多個小的節點,每個節點之間透過配置化方式組合,保證每個節點是可插拔、可替換的實現。整體使用者觸達系統處理流程如下:
-
接收CEP規則計算結果,包括規則名和滿足規則的使用者;
-
Action路由層根據規則名查詢所有訂閱此規則的Action列表;
-
Action過濾層根據一定策略過濾有效Action列表,過濾策略包括黑/白名單,灰度、人群和疲勞度策略;
-
Action下發層會根據策略配置執行,可以是通用的觸達,比如發push、簡訊;也可以是呼叫其他業務系統,比如呼叫安全系統處罰;也可以將Action下發到端上執行;
-
Action執行後將相關資訊按照通用協議埋點,方便後續資料統計;
使用者觸達是omega系統流程的最後一環,需要封裝足夠多的通用觸達能力,保證觸達的實時性、有效性,不然對使用者體驗會有傷害,接下來透過詳細設計看下使用者觸達系統如何保證觸達策略可組裝、可插拔的靈活配置和觸達實時性等特性。
2.3、詳細設計
注:metaq是阿里內部使用的MQ框架;HSF是RPC框架。
使用者觸達中心的目標是可以單獨提供服務,支援靈活可插拔配置和策略精準觸達,所以在設計上著重減少對外部依賴,對外透過MQ方式減少對外部系統直接依賴和耦合;對內明確各子模組的功能邊界,透過配置化方式組合子模組。
使用者觸達中心的主要作用是維護觸達策略和封裝標準觸達能力,整體分為以下部分:
-
輸入資料來源:使用者觸達中心可以接收上層規則中心計算結果,也可以由外部業務系統主動觸發;
-
觸達物料包括文案、圖片等維護在雲投放系統(閒魚素材管理系統),後續會接入離線資料補充更細粒度的基礎資訊,包括使用者畫像、商品資料等。
-
Action路由層維護Action與規則之間的訂閱關係,包括訂閱的有效時間、優先順序等要素;
-
Action過濾層採用責任鏈模式設計,各filter相互獨立,可動態插拔和靈活配置;
-
Action實現層封裝了各種通用觸達能力實現,目前主要是雲端和客戶端兩種,後續可透過faas模式提供Action靈活快速上線能力。為了保證在客戶端執行Action的實時性,我們專門維護了與客戶端的長連通道,透過針對性最佳化,提升通道的資料傳輸速度和到達率,對端上觸達進行了重點保證。
-
Action觸達後會按照統一埋點協議記錄,後續會整理埋點上報和資料開發流程,減少資料開發成本,方便業務方檢視Action實驗效果和實驗歸因。
線上效果
使用者觸達中心上線後已經透過配置化方式承接多個業務,包括閒魚金鱗雙十一玩法、使用者增長、租房、租賃等多個業務場景,透過運營靈活配置策略和權益的實時精準觸達,拿到以下資料結果:
對目標人群觸達準確率大幅提升;
金鱗玩法延遲在1s內;
授人以魚不如授人以漁,提供運營工具,徹底解放開發資源;
其中雙十一專案對實時性要求高而且QPS比較高,對Omega系統尤其是使用者觸達中心的效能和實時觸達能力進行充分驗證。最終瀏覽商品降價場景Push點選率較離線有大幅提升。
總結展望
Omega系統是針對實時性要求高、運營主導、快速實驗這類場景解法的高度抽象。秉承這個理念,使用者觸達中心封裝多種通用觸達能力,支援靈活可插拔的filter配置和設計標準埋點協議以支援業務快速實驗和資料歸因分析。後續我們將支援離線畫像資料標準接入和資料迴流分析標準化,打通業務上下游資料,在功能上實現流程閉環。也歡迎讀者交流討論。
本文為阿里雲內容,未經允許不得轉載。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69947441/viewspace-2668316/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Preact:一個備胎的自我修養React
- 一個野生程式設計師的自我修養程式設計師
- 《前端的自我修養》前端
- 一位賭狗前端的自我修養前端
- 執行時應用自我保護(RASP):應用安全的自我修養
- Kafka實戰(三) - Kafka的自我修養與定位Kafka
- 一個程式的自我修養「GitHub 熱點速覽 v.22.19」Github
- 執行緒池的自我修養執行緒
- 安全研究者的自我修養
- IT技術人員的自我修養
- 「認知」打工人的自我修養
- 積累→設計→執行:論遊戲系統策劃的自我修養遊戲
- IT技術管理者的自我修養
- 侃透了:運維人的自我修養運維
- 論漏洞管理平臺的自我修養
- java從零開始系列-一個前端程式設計師的自我修養Java前端程式設計師
- 一個數值策劃的自我修養:做數值就是做體驗!
- 切圖崽的自我修養-梳理Jquery APIjQueryAPI
- 很認真的談一談程式設計師的自我修養程式設計師
- 小成本二遊的自我修養!又一款二遊做出了個性
- 切圖崽的自我修養-SeaJs重要概念剖析JS
- 《蝙蝠的“自我修養”》專案詳細介紹
- 碼農節快樂|一個系統,高效解決複雜事件採集-計算-實時觸達事件
- 遊戲設計師的自我修養(一):認識玩家,理解玩家遊戲設計師
- 遊戲設計師的自我修養(一):認識玩家、理解玩家遊戲設計師
- 演員的自我修養:網路電影的顛覆與自我顛覆
- 遊戲設計師的自我修養(三):理解玩家遊戲設計師
- 遊戲運營的自我修養:細緻、高效、敏感遊戲
- 《程式設計師的自我修養》-讀書筆記程式設計師筆記
- 程式設計師的自我修養-編譯連結程式設計師編譯
- 一棵韭菜的自我修養:用Python分析下股市,練練手Python
- 全棧的自我修養: 003Axios 的簡單使用全棧iOS
- 社交APP定製開發---一對一直播交友原始碼的自我修養APP原始碼
- 再牛逼的出場也敵不過配角的宿命——論一個強大BOSS的自我修養
- 切圖崽的自我修養--[BUILD]構建工具思路梳理UI
- 程式設計師的自我修養筆記之裝載程式設計師筆記
- 遊戲策劃的自我修養-核心競爭力篇遊戲
- 《程式設計師自我修養》讀書筆記程式設計師筆記