優酷用戶觸達平台技術大揭秘

csdn 發佈 2020-08-22T12:54:58+00:00

但當我們深挖這些用戶觸達運營場景時,發現如下問題:1)觸達渠道建設成本高,PUSH、站內信、簡訊、微信公眾號、支付寶生活號等觸達場景接入各業務時,存在重複建設接入的問題;

作者| 阿里文娛技術專家 曾辰

責編 | 李雪敬

出品 | CSDN(ID: CSDNnews)

前言

優酷在用戶運營場景上,沉澱了豐富的用戶運營及營銷觸達策略。為了保障用戶的持續活躍,當用戶進入產品生命周期的後半段(預流失/流失狀態)就需要精準洞察用戶,在恰當的時機,通過正確的渠道,向用戶推送個性化的內容達到召回、轉化及促活的目的。但當我們深挖這些用戶觸達運營場景時,發現如下問題:

1)觸達渠道建設成本高,PUSH、站內信、簡訊、微信公眾號、支付寶生活號等觸達場景接入各業務時,存在重複建設接入的問題;

2)過分關注單一觸達方式在局部場景的應用,缺乏整體視角和統一機制,包括渠道間的聯動及頻次控制;

3)數據分析及沉澱能力薄弱,有單點數據,但缺少整體鏈路數據,同時觸達策略無法復用等。

基於以上問題,我們打造了優酷統一觸達平台,它是基於用戶行為分析和洞察一站式觸達平台,打通了優酷業務域內人群、素材、渠道、觸達策略全鏈路,支持觸達AB實驗疊代能力,提供全鏈路效果數據。

觸達平台目前整體架構大圖及業務能力如下,除了支持主動觸達矩陣外,還支持搜索、小喇叭等非標資源位的觸達。除此之外,結合入口人群、策略編排及執行、數據回流構成了整個觸達平台的鏈路。

平台架構實現

從平台架構大圖中可以看到,架構核心主要包括入口層、策略層、通道層。人群及事件作為平台入口層,接入各類業務的能力,它控制了平台整體的起始調度執行;策略層是整個平台的中樞,提供觸達策略的制定及執行;通道層整合了各個底層觸達通道,它的核心是物料和數據源的能力。三層架構自上而下,共同組成了觸達核心鏈路,下面針對各層的主要模塊進行拆解。

一)人群及事件

統一觸達平台作為觸達業務的承接方,需要對接眾多的業務觸達需求,所以對平台的適配能力提出了很大的要求。而作為入口節點,承擔了主要的職責。目前我們主要提供離線人群、業務事件適配,離線人群主要針對用戶運營等場景,而事件主要用於實時系統通知及外部業務對接的觸達能力。

離線人群

離線人群是通過人群標籤圈選,通過數據接口導入人群數據,從而進行逐一的觸達。離線人群處理最主要的挑戰,是如何保障人群發送效率,在儘可能短的時間內完成發送。基於這個目標,我們採用阿里集團分布式任務調度服務的分布式調度能力,基於大人群分片,多層下溯,充分利用分布式的能力。

調度引擎也是基於任務調度的引擎。根據任務類型主要分為流程任務、等待任務;流程任務主要針對離線人群流程入口節點的調度,而等待任務是流程任務因在等待節點中斷流程執行,在之後恢復執行的任務。目前支持多種調度策略,定時、立即發送,單次、周期任務,最終轉化成調度表達式。流程任務的整體調度流程分3層:

  1. 獲取人群類型、人群數量以及分頁等基本信息;

  2. 分頁獲取人群用戶列表,並完善用戶帳戶信息;

  3. 根據配置細分成更小的人群分片,分片信息暫存 nosql。

人群任務及事件任務都支持流程等待,因為人群策略實現上略有差異,所以等待流程的實現也略有差異,但整體一致。任務暫存至 nosql 資料庫,以任務需恢復時間時刻(分鐘)為 key,等待任務的調度需要每分鐘掃描以當前時刻為 key 的等待流程。

通過分布式的能力,能非常高效的完成人群的調度,但也因此引入了其他的問題,內存與線程等問題,最終,我們在發送效率及服務穩定性之間找到了一個平衡點。

  1. 人群規模不可控,經常會有上億的人群場景,人群信息預加載內存後,短時間對內存產生了極大的開銷。為了解決這個問題,我們引入了 nosql 進行了人群信息的暫存,在子任務執行時,再預加載人群數據;

  2. 人群任務觸發時,執行引擎線程都是滿負載運行;最初我們考慮運行效率,在觸達渠道節點又引入了一層異步線程,但事與願違,異步線程池的等待任務隊列在短時間打滿,並又占用大量內存,最終取消了異步發送邏輯。另一方面,除了渠道服務,觸達的物料素材可能會依賴於外部數據源,在高並發服務調用下,對下流業務服務產生了極大的壓力。為此,我們引入勻速器模式,針對各個業務提供的預設 qps 執行調用。

消息事件

消息事件的實時性、業務數據能力,正好是離線人群的補充。消息事件也是觸達平台對外部業務提供的較為便捷的對接入口。同時,我們通過消息事件將會員觸達系統、人群導入等內部的鏈路拉通。通過事件方式接入,消息的觸達時機由業務側控制,觸達平台業務通過等待節點對消息發送時機做干預。

為了能支持各類業務方,也為了減少業務方的對接成本,觸達平台對接入消息不做任何協議約束;完全依賴觸達平台的事件適配能力。業務方只需要提供消息topic及tag,以及消息體樣例。為了解決消息的適配,觸達平台的事件管理主要提供了以下能力:

  1. 消息過濾器,通過 MVEL 表達式提取目標消息;

  2. 目標欄位映射,規範觸達內部的消息格式;

  3. 占位符及參數表達式,消息數據加工;

通過以上3個能力,基本解決了消息統一適配的問題。通過 MVEL 表達式,可以靈活的支持各類業務需求的配置。總結下,消息事件的處理就是如下的流程:

上面提到,離線人群的缺點是無法攜帶業務內容,這對一些千人千面的觸達需求不能很好的支持。而業務消息在一些營銷場景下也不能很好的支持,基於此我們引入了 ODPS 數據導入的能力。它有離線人群的業務特性,又有事件消息的業務能力,而且技術實現上統一將導入轉化成消息事件,使其與消息處理邏輯保持一致。目前導入是針對一些特有的業務場景,使用頻次會較低,但其自由度較高。導入人群實現方案結合了離線人群以及事件人群的能力,能在滿足業務訴求的同時能有較高的發送效率。

二)策略執行引擎

策略即觸達業務邏輯,作為統一觸達平台,我們希望通過編排來替代原先需要硬編碼的業務邏輯。觸達平台通過一種有向無環圖的形式,來形象的表述這種策略。當然上面講的人群及事件、以及後續會著重解析的物料模塊都是策略的一部分。但這一部分,主要來分析下整體的圖形策略編排、以及策略執行引擎。

首先,需要明確節點、邊的定義,通過對觸達關鍵鏈路的拆解,明確了下如下節點和邊的搭建規範。

按照規範,我們產出了如下觸達策略。實現層面,我們用 node,edge 兩個列表進行存儲,通過首尾相連,組成一個 Graph。節點以及條件邊都有對應類型的控制器實現,通過解析後的 Graph,依次執行對應控制器。

在執行階段,執行引擎根據策略編排規範,逐一執行各個節點。當然,前置數據預處理、調度邏輯已經在人群、事件入口已完成。執行引擎執行順序如下:

  1. 接收人群分區任務、事件消息任務以及等待任務;

  2. 獲取流程對應節點流程圖;

  3. 執行上下文數據預處理,並進行執行引擎數據收集;

  4. 定位首個執行節點,等待任務需要從上一次終端節點下一個節點開始執行;

  5. 執行首個節點對應控制器;

  6. 節點執行結束,獲取後續節點列表,並逐一執行;

  7. 節點中斷或所有節點執行完成,更新相關計數,退出執行引擎。

執行引擎的職責比較明確,需要保證觸達任務高效穩定的執行。主動觸達場景對執行引擎的執行效率沒那麼大的要求,只是針對大人群的觸達,因為耗時較久,目前主要的瓶頸還是下流服務。對執行引擎主要性能要求,來源於被動觸達場景,因為面向C端,對RT及RT穩定性有很大的要求。這塊將是後續執行引擎優化的重點,同時對任務間的資源隔離也是需要著重考慮的點。

三)物料及數據源

觸達平台的物料,泛指渠道節點依賴的素材。物料基於渠道模板配置,且支持事件、自定義數據源的占位符渲染能力。模板能力相對簡單,但在物料模塊實現上需要對模板進行對應的支持,所以模板的實現應該較為的通用,便於後續模板的擴展及改動。物料的渲染是對預設占位符的變量能力的替換,從而實現不同用戶觸達消息的個性化能力。目前我們已支持事件占位符、數據源占位符。

  1. 事件占位符只針對事件流程,可以對事件消息體內容進行邏輯加工處理,產出我們需要的占位符變量;

  2. 數據源占位符相對通用,不局限於流程類型,對定義的數據源結果進行二次加工產出需要的占位符變量。這個的數據源一般是一個外部的服務,需要預先確認服務,方法,以及入參出參的映射。

數據源難點及實現

物料渲染階段,相對較為複雜的是數據源占位符的渲染,有以下難點:

  1. 數據源入參不足

    事件、導入人群,因人群本身就攜帶了業務參數,使用相對方便,一般數據源入參都能映射到人群消息變量上;離線人群本身只攜帶了用戶id,所以在很多業務場景使用數據源能力會受限,非常受到限制;

    實現方案

    a) 任務配置環節,通過與其他平台的交互,引入對應的業務入參,業務參數在任務級別是靜態的,通過數據源調用在實現消息個性化;

    b) 通過ODPS業務數據表導入,人群信息同時攜帶業務信息;藉助ODPS的開發能力以及數據動態更新能力,能覆蓋各類負載的觸達需求。

  2. 複雜業務配置受限

    數據源能力目前僅支持在物料占位符上,一個數據源配置一個服務調用,對需要多個服務組合調用場景並不能很好的支持;目前需要通過硬編碼的形式再產出一個新的服務

    實現方案

    a) 將數據源的能力擴展至前置節點中,通過串行編排,實現數據源鏈式執行的能力;

    b) 支持數據源之間的聯動,通過上下文傳遞數據源占位符等信息,作為後續節點的輸入。

  3. 高並發場景

    離線人群使用阿里分布式調度服務MapReduce模型,事件人群直接是對消息隊列的消息消費。在流程執行中,對物料模塊會產生極大的壓力,數據源服務提供方的RT參差不齊

    實現方案

    a) 基於入口節點的高並發執行場景,數據源不適合異步化,異步執行在高並發場景時會使數據源任務場景大量的堆積,最終會產生大量的內存壓力;

    b) 權衡整體的平台負載及觸達性能,我們採用了數據源的同步調用,針對多數據源場景進行並發調用以提高整體的執行效率。

數據能力

基於觸達平台化的背景,必須提供一套可復用的數據能力,來適配未來各類的業務的數據需求。在明確了觸達轉化鏈路上的曝光、點擊、轉化等各個指標項後,我們通過統一的埋點,拉通整體的數據回流鏈路,真正提供平台化的數據能力。

數據回流

觸達平台定義 utrace 用於關聯整個觸達營銷業務鏈路,一個 utrace 可以追溯到觸達營銷計劃,觸達渠道,內容素材,實驗分桶,算法相關信息,以及其他統計維度的欄位。在執行投放任務時,自動化營銷平台基於上述欄位生成 utrace。最終,通過 utrace,將渠道側的曝光、點擊數據,收銀台的到訪,下單進行統一串聯,關聯觸達計劃、實驗分桶等。

總結及展望

目前,優酷統一觸達平台能力基本完善,通過人群圈選、事件消息對接各類觸達業務的能力;通過策略編排,結合實時條件邊、數據源自定義等能力,能夠承接複雜觸達編排業務場景。在系統性能方面,目前平台承接了大量業務事件消息鏈路,執行引擎能在毫秒級別完成策略的執行,真正做到實時觸達;同時每日執行的人群任務,能在小時級別內完成千萬級別人群的觸達,同時支持多任務並發執行,真正做到高效觸達。在系統穩定方面,為了避免任務間相互影響,我們通過執行線程預分配進行隔離,保證各業務鏈路的穩定性。同時利用限流的勻速器模式,保證資源及外部數據源的平穩執行,減少流量尖刺等帶來的系統異常。

未來,我們在技術層面對平台的建設,主要是兩個方向:

第一, 建設全域觸達矩陣,拉通主動觸達場景的編排能力。主動觸達不同被動觸達,因為直接面向C端用戶,需要有更高的系統穩定性,以及更短的響應時間,這對平台策略執行引擎提出了更大的要求

第二, 支持狀態躍遷的策略能力。需要引入狀態機機制,對用戶狀態進行生命周期式的管理,這對平台的架構會是一個很大的挑戰。

關鍵字: