一個優秀的Push平臺,需要經歷怎樣的前世今生
對閒魚使用者來說,因為閒魚商品庫存只有一件,商品的時效性很強,因此當使用者關注的賣家上新、瀏覽的商品發生降價或者平臺為使用者找到一批高價效比商品時,使用者期望儘快被通知。Push已經成為使用者與閒魚平臺聯絡的重要紐帶。
本文將以技術同學視角,介紹閒魚Push從離線手工投放的1.0版本進化到智慧個性化的2.0版本的發展過程,詳細說明遇到的問題和技術方案選型,以期給讀者帶來一些思考和解決類似問題的思路。
閒魚Push1.0
當閒魚all in無線後,平臺需要把與使用者相關的優質內容推送給使用者,便於使用者快速找到想購買的商品和感興趣的內容。平臺亟需一個Push產品化方案保證將優質內容以Push的形式觸達到使用者,提升使用者體驗。基於這樣的前提,閒魚Push1.0方案的主要思路如下:
1. 計算Push使用者名稱單
a. 計算與使用者強相關的優質Push場景,根據場景得到使用者名稱單
b. 垂直業務根據使用者畫像等條件,圈選業務的目標人群
2. 基於場景疲勞度過濾每個使用者能傳送的場景列表
3. 對每個使用者的場景列表進行全域性擇優,挑選點選率最高的場景作為目標場景
閒魚Push1.0方案簡單明瞭,流程清晰,而且離線流程方便監控告警和問題排查,滿足當時的業務需求,上線後執行穩定。在很長一段時間內1.0方案的核心架構和流程沒有太大變更。但隨著業務發展,閒魚Push1.0方案的一些弊端開始暴露,包括
Push使用者名稱單計算不夠實時
訊息卡片樣式不夠豐富
Push觸發時機單一
Push場景比較少
這些問題最終導致Push點選率無法繼續提升,觸碰到1.0方案的天花板。為了解決這些問題,我們對閒魚Push系統進行幾個方面的最佳化升級,並最終重構了閒魚Push系統。
閒魚Push1.1
為了給Push使用者提供更好的使用者體驗,豐富使用者Push場景,我們優先考慮從訊息樣式、觸發時機和使用者場景幾個方面最佳化擴充套件現有閒魚Push方案,最佳化項主要分為訊息feeds流升級、Push時間個性化、實時Push等。
訊息feeds流升級
Push會沉澱到客戶端的訊息板塊,而訊息板塊也是使用者進入閒魚後瀏覽最頻繁的板塊之一,訊息樣式最開始只支援文字訊息和圖片訊息,這類訊息樣式的問題是對使用者來說有效資訊曝光少、而且訊息樣式單一。為此我們對訊息展示形式進行升級,透過feeds方式展示訊息,提升有效資訊曝光率,最佳化訊息樣式,打造訊息板塊的使用者心智。feeds流升級上線後效果明顯,因為使用者感興趣的內容相比透出更多,UV點選率和使用者次留相對提升都很大。
第一條為feeds流訊息,之後是圖片訊息,相對來說,feeds流訊息可以透出更多有效資訊
Push時間個性化
閒魚Push1.0方案主要支援的是定時批次Push,實際的執行情況是定時批次給目標使用者發Push。Push觸發時機比較單一,人為造成流量較為集中,增加系統穩定性風險;另外統一的觸發時機並不適用於所有使用者,存在對部分使用者打擾的情況。
針對這種情況,我們最佳化了Push觸發時機,由演算法根據使用者行為計算預測每個使用者的觸發時機。演算法將使用者相對平均的分在一天之中,在使用者相對活躍的時間段將Push觸達給使用者,減少對活躍使用者騷擾,也使得Push觸達的使用者群體分層更加合理健康。
實時Push
閒魚Push1.0方案主要覆蓋的是使用者相關離線場景,對使用者實時行為產生的場景覆蓋不夠,而且這類場景較離線場景相比實時性更高,對使用者來說相對更重要。針對這個問題,我們增加了對實時場景覆蓋,將使用者行為抽象成關係模型,以IFTTT作為系統整體觸發機制。當關系一側的使用者行為發生變更後觸發對另一側的觸達,這類場景實時性更強,和使用者強相關,提升使用者Push場景豐富度,增強使用者粘性。實時Push場景上線後Push點選率相對離線場景提升1倍以上,具體技術細節可參考《閒魚IFTTT》。
以上是我們針對閒魚Push1.0的功能最佳化和增強,透過這些能力也擴充套件支援了更多場景和業務,最終組合在一起成為閒魚Push1.1版本。
閒魚Push的今生
閒魚Push1.1整體上線後極大提升了使用者Push場景豐富度和使用者體驗。隨著對Push和使用者理解的深入,我們發現還有最佳化提升的空間,包括:
平臺視角不夠,現有的最佳化更偏向點對點,需要從閒魚Push平臺視角將這些點連成線形成合力,產生1+1>2的效果
現有閒魚Push流程的本質還是離線計算,演算法無法進行更加實時的個性化和全域性擇優,對使用者體驗有一定影響
場景配置不夠靈活,新增場景成本高,制約了豐富使用者Push場景的進度
基於這些原因,我們最終對閒魚Push系統進行重構和升級,打造閒魚Push實時智慧投放平臺Hermes。Hermes取自希臘神話,他聰明(智慧)、行動敏捷(快)、多才多藝(多種觸達),最能契合閒魚Push實時智慧投放平臺的使命願景。
邏輯架構
Hermes架構與閒魚Push1.0完全不同,以實時為目標,在場景素材準備、演算法全域性調優和Push傳送等關鍵環節實現實時或準實時,提升Push內容時效性;另外從平臺角度出發,將Hermes分為配置中心、匹配中心和任務中心,各個子系統定義互動的資料協議,彼此沒有強依賴。三個子系統的作用分別是:
配置中心
配置中心負責維護平臺核心資料模型,給業務方提供頁面操作配置Push場景和素材,降低業務方接入成本;並且把配置資料以離線全量和實時增量的方式同步給演算法模型,作為匹配依據。
匹配中心
匹配中心又稱為演算法擇優中心,匹配中心負責訓練演算法擇優模型,根據場景和素材配置為每個使用者個性化篩選,根據每個素材歷史點選率資料排序,根據使用者近期行為召回使用者最有可能感興趣的素材和個性化內容。
任務中心
任務中心負責Push觸發時機和實際觸達,任務中心核心支援定時觸發、實時觸發和時間個性化觸發,目的是對Push觸發方式收口,為不同的業務和場景選擇不同觸發方式,幫助業務實現業務目標。另外是對觸達進行收口,方便平臺編排觸達計劃,包括觸發時間和傳送量級,保證達到業務目標同時不會對Hermes和業務下游系統造成過大瞬時壓力。
業務效果
Hermes平臺上線後效果非常明顯,主要表現為:
Push點選率相對提升達到兩位數
使用者場景覆蓋量直接翻倍
Push點選啟用的DAU也超過歷史最高水平
總結
本文介紹了閒魚Push從前世離線計算的1.0版本,發展到多項功能最佳化的1.1版本,最終進化成今世的實時智慧投放平臺的全過程,其實閒魚Push的每個階段都契合當時業務發展需要,但對於使用者體驗的無限追求最終產出了閒魚Push實時智慧投放平臺Hermes。希望這種方式可以幫助讀者理解閒魚Push發展的業務背景和技術方案選型考量。接下來我們還會有一篇文章詳細說明Hermes的技術方案,包括系統架構、技術選型、效能最佳化和穩定性保障措施,歡迎大家繼續關注。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69900359/viewspace-2682087/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分享一個優秀的chatgpt平臺ChatGPT
- 基礎資料平臺的前世今生
- 程式設計師前世今生 (6年PHP 開發的經歷)程式設計師PHP
- 雲原生的前世今生(一)
- 一份優秀的前端開發工程師簡歷是怎樣的?前端工程師
- SAP 雲平臺 ABAP 程式設計環境的前世今生程式設計
- RabbitMQ的前世今生MQ
- InfiniBand 的前世今生
- MySQL 的前世今生MySql
- Mybatis的前世今生MyBatis
- Unicode的前世今生Unicode
- Dubbo的前世今生
- Serverless 的前世今生Server
- IPD的前世今生
- CRM的前世今生
- DBHub的前世今生
- 資料中臺的前世今生 :帶你全面瞭解阿里巴巴做資料中臺的歷史阿里
- React ref 的前世今生React
- React Portal的前世今生React
- 遊戲的前世今生遊戲
- HTTP/2.0的前世今生HTTP
- 元件化的前世今生元件化
- 聊聊 HTAP 的前世今生
- 聊聊ChatGPT的前世今生ChatGPT
- 外掛的前世今生
- 邦芒簡歷:一份真正優秀簡歷應該是這樣的
- 製作一個小成本 ARG — ARG 的前世今生(二)
- 怎樣把自己培養成為一個優秀的程式設計師程式設計師
- iOS Device ID 的前世今生iOSdev
- JavaScript – 非同步的前世今生JavaScript非同步
- “錕斤拷”的前世今生
- 資料庫的前世今生資料庫
- Redux的前世-今生-來世Redux
- LangChain和Hub的前世今生LangChain
- 中國SaaS的前世今生
- SAP Cloud for Customer的前世今生Cloud
- HTTP 協議的前世今生HTTP協議
- lua保護的前世今生