1. 程式人生 > >安排!活動素材的億級使用者精準投放

安排!活動素材的億級使用者精準投放

浪費了“黃金五年”的Java程式設計師,還有救嗎? >>>   

作者:閒魚技術-齊悟

1.背景

  隨著閒魚使用者快速增長,運營活動越來越趨於精細和個性化,運營會根據使用者偏好為其投放合適的活動,如下圖所示在閒魚首頁商品展示時,會在商品的列表中插入活動Banner,通過這些活動banner引導使用者進入到相應活動會場,實現會場導流。閒魚投放系統負責閒魚運營活動的配置、管理、投放。

主要解決了以下幾個問題
  1.配置環境隔離問題,根據開發規範,任何線上業務必須先進行線下環境釋出,測試驗證通過後再發布上線。所以提供的管理平臺需要擁有線上和線下環境隔離的能力。

  2.檢索中的效能問題,在同一資源位下會配置多個活動,每次檢索時需要把該資源位下的所有活動拉出來,按照條件進行篩選出符合要求的活動,這個過程會隨著資源位下的活動增多檢索遇到效能瓶頸。

  3.人群管理問題,在活動中會配置投放的人群,每次檢索活動時人群作為活動的檢索條件,需要驗證使用者是否屬於當前活動的人群,所以需要解決使用者和人群關係的管理。

  4.AB測試問題,運營投放的活動往往需要進行AB測試比較不同策略的表現,此時需要提供AB測試的能力。
下面將通過介紹閒魚投放系統設計、技術方案設計和實現過程,進一步闡述如何解決上面提出的四個問題。

2.系統架構設計

  閒魚投放系統是一個配置管理和配置檢索的系統,換句話講他不生產任何活動素材,他只是活動素材的搬運工。下面介紹閒魚投放的系統設計。

  如上圖所示閒魚投放系統共分為了活動素材層、投放配置層、業務流程層和應用層四個層次。

  活動素材層是對在閒魚投放系統中所有素材源的彙總,目前閒魚投放中主要彙集了三種素材魯班素材、馬赫素材、TPP素材,魯班素材提供了使用者個性化Banner的能力,他的原理是根據使用者的行為獲取到偏好的商品,然後把商品圖和素材模板組合為一個Banner;馬赫素材提供規則圈選商品,他的原理是利用規則引擎把規則轉換為SQL語句,然後利用該SQL在商品表中撈出符合規則的商品,同時馬赫利用流計算能力對增量商品也實現了實時的規則圈選。TPP素材提個性化商品推薦,例如首頁的商品推薦和猜你喜歡的商品推薦,TPP作為個性化推薦平臺,可以根據不同的演算法實現不同的推薦策略。

  投放配置層是開放給運營能力的彙總,包含活動配置、環境隔離、資料報表三種能力。活動配置是對一個資源位下所有投放行為的具體配置,如下圖所示

  每個資源位會投放多個活動,活動與活動之間需要進行排期,每個投放活動中包含人群和素材兩類資訊,人群用來確定該活動投放的物件,素材用來確定該活動投放的內容,同時在人群下支援AB的能力。環境隔離是為了能夠區分線上和線下業務,保證線上的投放環境線上下充分驗證後再進行上線。資料報表是對所有投放活動關鍵指標的資料彙總。

  業務流程層是閒魚投放系統的關鍵,主要負責投放活動的檢索,根據呼叫方傳入的使用者資訊和資源位資訊,返回該資源位下符合該使用者的活動。

  具體的檢索邏輯如上圖所示,首先在DB中查詢當前資源位下的所有線上活動,然後依次過濾每個活動下的人群資訊是否符合當前使用者,從符合該使用者的活動列表中選取一個活動,如果該活動下有AB測試,需要請求AB測試平臺獲取AB測試中配置的素材資訊,最後返回該活動下的素材內容,客戶端拿到活動素材後進行展示。

  應用層是對客戶端能力的彙總,包括獲取素材、素材樣式展示、資料埋點。素材展示是直接與使用者互動的部分,需要前端提供多種展示樣式,資料埋點是為了驗證AB策略和收集活動關鍵指標資料。

3. 技術方案設計

  在上文中我們提到閒魚投放面臨四個需要解決的問題,分別是環境隔離問題、活動檢索問題、人群管理問題、AB能力問題。下面將分別從這幾個問題出發介紹解決的方法。

3.1 人群管理問題

  人群管理使用的是集團內的奧格人群平臺,他為我們提供了人群圈選和人群驗證的能力,在很大程度上解放了閒魚投放的人群管理,下面簡單的介紹一下該平臺的實現原理。

  如上圖所示展示了奧格幾個核心功能點,實現原理是這樣的,首先平臺會提供給使用者可選擇的規則,然後利用規則引擎把所選的規則,生成SQL查詢語句和流計算規則,SQL查詢語句用來離線圈選使用者和流計算規則用來實時篩選新增使用者,通過離線規則和線上規則實現了奧格的人群圈選,在人群驗證階段,首先利用倒排檢索的思想,使用者和人群的關係利用倒排資料結構標識,該方法解決了單使用者與多人群關係驗證的效率問題,最後利用多級快取和熱點資料本地快取的方式解決人群檢索RT問題。

3.2 AB測試管理問題

  AB測試是用來驗證方案的常用方法,常用的AB測試方案大多是使用者唯一屬性取模的方式按比例劃分使用者,但是會面臨很多複雜的問題1.按照使用者的id進行取模計算,對於未登入使用者處理是一個常被忽略的問題。2.測試白名單管理,在AB測試時需要把特定人員劃分到特定測試桶裡。3.多個AB正交測試,如果有多個AB測試,此時需要正交測試時會出現更復雜的情況。在閒魚投放中使用了集團的一休AB平臺,一休提供基於使用者、裝置等多維度AB策略,同時支援白名單與正交AB測試的複雜場景,在AB基本能力的基礎上提供了資料分析的能力,實現了呼叫到資料管理的一體化。

3.3環境隔離問題

  解決環境隔離問題主要是為了方便測試,先線上下看效果,然後再把資料配置到線上。為了實現環境隔離迭代兩次技術方案。

  首先介紹第一個方案,依照總體功能設計我希望平臺中每個模組都可以靈活複用,可以利用已有模組,快速搭建出滿足業務要求的投放活動,所以從業務角度進行了抽象,把能拆分的模組儘可能的抽象出來,最終的實體關係如下圖所示。從業務邏輯角度共抽象了6個實體分別是資源位(Resource)、活動(Activity)、人群(Crowd)、素材(Data Source)、資源位和活動的關係(Resource Plan)、活動和人群素材的關係(Activity Plan)實體,每個模組之間可以按照下圖的關係進行自由組合成一個投放活動。

  在該方案中利用每個實體中的env欄位解決環境隔離問題,無論是在投放活動配置還是在檢索過程中,只可以利用相同env欄位的實體,該方法完全實現了環境隔離,但是在實際的應用中效果卻不是很好,因為利用一份資料表中的env欄位實現環境隔離,所以線上和線下對應的Resource Plan和Activity Plan關係表中關聯的實體ID不同,那麼將無法實現線下配置直接拷貝到線上,此時需要線上下和線上兩次配置,由於配置過於複雜增加錯誤風險。

  下面介紹第二個方案,第二個技術方案中對方案一中提出的問題進行優化。具體的設計如下圖所示:

  如上圖所示,實體物件由6個轉換為4個,下面一次介紹這些實體和如何解決環境隔離問題。

  首先介紹新引入的Data Schema實體,DataSchema是由開發同學負責,提供了一個配置好的JSON配置模板,他與Resource進行關聯,意味著當前Resource下的所有DataSource都將按照該DataSchema提供的JSON模板進行配置,同時在解析時也按照當前的DataSchema進行解析

  Resource不再區分線上和線下環境,因為Resource無論是線上和線下他總是存在的並且不會改變的,所以區分線上和線下是沒有必要的。

  DataSource不再用env欄位區分線上和線下環境,利用preData和onlineData進行區分線上和線下配置,由於引入了DataSchema模板,所以徹底解放了DataSource,他不再需要進行繁瑣的配置,只需按照DataSchema把所有的需要欄位都配置到對應的Schema中即可。這樣在線上和線下DataSource是一條資料主鍵不再改變。

  Activity實體是DataSource和Resource的關係實體,同時包括活動的人群、起止時間等屬性。由於DataSource和Resource實體線上和線下環境中主鍵ID都不會改變,那麼意味著Activity可以把線下的配置直接同步到線上,在同步過程中需要做的是如果線上沒有配置就插入一條如果存在就更新。那麼怎麼對映Activity線下和線上的關係呢,在Activity裡面引入了mapId欄位,線下的Activity實體在mapId中儲存線上Activity實體的主鍵Id,利用這種對映關係實現了線下和線上的對映。

  具體的如上圖所示,通過這種表和表之間對映關係,實現了環境隔離問題,同時簡化了業務中的實體,讓配置更簡單更易用。

3.4活動檢索問題

  在實際應用中,我們遇到了檢索能力的效能瓶頸,根據每次檢索時都需要拉出當前資源位下的全部活動,然後按照起止時間、人群作為過濾條件,篩選出滿足當前使用者的活動列表。以上過程中每次檢索都會發生與資料庫的IO操作。當資源位和訪問QPS增多時,資料庫IO操作將成倍數增長,此時會成為檢索的瓶頸,所以在以上的技術方案中,需要一個完備的快取方案支撐檢索的正常執行。按照常規的快取設計方案進行了如下的快取方案設計。

  所有的查詢都是先進行快取查詢,如果未命中再查詢資料庫,把查詢到的資料回寫到快取中。對於所有的更新操作,都是先更新資料庫,然後再失效快取,在更新活動時,需要在失效活動快取的同時,也要失效該活動對應資源位下活動列表的快取。

  但是在使用過程中遇到了一個問題,資源位下的活動列表儲存採用了kv結構,key為資源位ID,value為活動列表的JSON序列化,當資源位下的活動增多時value也會隨著膨脹最後超出閾值,所以把活動物件進行了簡化僅儲存活動Id和人群Id。優化後檢索過程將有所變化如下圖所示:

4.總結與展望

4.1總結

  通過以上的整體功能設計、技術方案設計、程式碼實現,介紹了一個投放平臺從設計到實現過程中遇到的問題點和解決方案。目前投放平臺已經在閒魚的使用者實時觸達、首頁feeds投放、淘寶閒魚小程式投放中使用,完美支援運營根據人群精準投放活動。

4.2展望

  閒魚素材投放平臺但仍有需要持續完善的地方,首先是精準人群的個性化,例如在首頁的投放中,針對圈選的人群透出的Banner圖片都是一樣的,目前我們的投放最小粒度是人群未來將會做到個人。然後是投放能力自優化,目前活動針對資源位的爭奪還是利用權重、人群、起止時間作為前置條件,未來將會通過投放資料迴流利用演算法計算其關鍵指標實現投放的自優化。同時閒魚素材投放將對接集團內部的更多優秀的素材提供源豐富閒魚的活動。

相關推薦

安排活動素材使用者投放

浪費了“黃金五年”的Java程式設計師,還有救嗎? >>>   

綜合微軟、AMiner兩大學術圖譜,清華大學唐傑博士如何將Open Academic Graph資料匹配

 AI 科技評論按:近日,清華大學副教授、Arnetminer 創始人唐傑博士在微博上公開了開放學術組織(Open Academic Society)釋出的億級學術圖譜——Open Academic Graph。據唐傑博士介紹,該圖譜目前集成了兩個最大的公開學術圖譜:微軟學術圖譜(MAG)

京東活動系統流量應對之術

作者:幹天星,2012年初加入京東,先後在京東審計、搭配購、jshop活動系統等專案從事系統研發和架構工作。目前主要負責jshop活動系統架構升級,以及jshop資料中心實現運算架構設計。對構建高併發web架構,以及高效能實時大資料運算,有一定的見解。入職前有過5年電信傳統行業開發、架構經驗。 背景

如何實現互聯網投放效果,應該找誰?

高級 表達 微信 客戶端 騰訊大數據 嵌入 移動 投進 wan 廣點通是根據騰訊各大交際網絡體系的作用廣告渠道,具有Y質流量資源,為廣告主供給QQ空間、QQ客戶端、QQ音樂等許多廣告。作為自動型作用廣告,廣點通能有用完成愈加智能的廣告匹配和高效的廣告資源使用。並使用專業數據

如何實現互聯網廣告投放

根據 整合營銷 我們 成熟度 qq音樂 全面 結合 企業 依據 眾所周知互聯網推廣是一個多元化的,那麽我們今天就從多個角度剖析互聯網廣告如何精準投放? 廣點通是根據騰訊各大交際網絡體系的作用廣告途徑,具有Y質流量資源,為廣告主供給QQ空間、QQ客戶端、QQ

遊戲買量屢試不爽的套路贏不了人心 投放上位成贏家

2018年上半年手遊市場廣告投放中,新入局者首次投放且新上線的手遊佔比高達56.8%,首次投放而非新上線者佔比28.6%,遊戲買量市場的競爭越來越激烈,MobData發現,單是2017年就有接近5000款遊戲產品買量,參與瓜分遊戲市場這塊流量蛋糕的越多,買量的競爭壓力就越大,

推廣流量仍能推薦?解讀核心算法的應用實踐

阿裏 算法 mlr 模型 阿裏媽媽,是一個想讓天下沒有難做的營銷的大數據平臺,它擁有阿裏巴巴集團的核心商業數據。在這裏,每天有超過50億的推廣流量完成超過3億件商品的推廣展現,覆蓋高達98%的網民,實現數字媒體(PC端+無線端+互聯網電視端)的一站式觸達。在這些鮮亮的數據背後,是什麽樣的核心算法在

如何利用Python分析14條數據資深程序員手把手教你

pre 這就是 標準 調整 處理 行數據 word 圖表 提升 挑戰 1-gram 的數據集在硬盤上可以展開成為 27 Gb 的數據,這在讀入 python 時是一個很大的數據量級。Python可以輕易地一次性地處理千兆的數據,但是當數據是損壞的和已加工的,速度就

滴滴出行千訊息佇列煉成記

本文整理自滴滴出行訊息佇列負責人 江海挺 在Apache RocketMQ開發者沙龍北京站的分享。通過本文,您將瞭解到滴滴出行: 1. 在訊息佇列技術選型方面的思考; 2. 為什麼選擇 RocketMQ 作為出行業務的訊息佇列解決方案; 3. 如何構建自己的訊息佇列服務; 4. 在

每分鐘訪問10w+,11種策略教你保持流量網站穩定性

穩定性在大型網站執行中至關重要,面對每分鐘 10 萬次的網路訪問,稍有不慎就會引起重大故障。今天這篇文章一起討論下億級流量網站在穩定性方面的一些做法,希望對您有幫助。 一、基礎策略 1.1、配置化 配置化就是把很多業務流程相關的資料統一放在一個配置平臺上,從程式碼中抽離

QQ 會員活動運營系統的設計之道

隨著 QQ 會員使用者的日益增漲,每週都要上線大量各種玩法的 H5 活動來滿足產品和運營的需求。傳統的開發流程為:需求評審->設計->重構->開發->測試->上線。這種傳統的開發流程和週期都比較長,上線一個活動至少要一個星期的時間,

京東10呼叫量背後的高可用網關係統架構實踐

作者介紹: 王棟 京東商城開放平臺高階架構師 擁有 10 多年的架構和團隊管理經驗,涉及資訊保安、網際網路、電商等領域。 2011 年底至今一直在京東商城就職,期間負責過商城、POP、京東開放生態、京東移動 APP、京東商戶 APP 等業務,熟悉電商核心的流程和移動網際網路。在這 4 年當中見證了

如何實現上資料的計數?

文章內容 背景 關係型資料庫在執行計數任務時,其執行效率會隨著資料量級的增長而降低;當資料量達到億級別時,計數任務的執行效率已經低到令人不忍直視。在閒魚團隊的關係系統中,我們採用了這樣一種方式來實現億級別資料的毫秒級計數。 挑戰 閒魚現有的業務場景中,使用者收藏寶貝、關注他人的資料量

企業級 RPC 框架開源了

org 輕量級 發的 image 一個 pri 認識 core fast 今天給大家介紹給一款性能卓越的 RPC 開源框架,其作者就是我推薦每個 Java 程序員都應該看的《Java 生態核心知識點整理》的原作者張玉龍。 說實話我第一次看到這個資料的時候,就感覺作者是一位真

【高併發】流量場景下如何為HTTP介面限流?看完我懂了

## 寫在前面 > 在網際網路應用中,高併發系統會面臨一個重大的挑戰,那就是大量流高併發訪問,比如:天貓的雙十一、京東618、秒殺、搶購促銷等,這些都是典型的大流量高併發場景。關於秒殺,小夥伴們可以參見我的另一篇文章《[【高併發】高併發秒殺系統架構解密,不是所有的秒殺都是秒殺!](https://mp

【高併發】流量場景下如何實現分散式限流?看完我徹底懂了(文末有福利)

## 寫在前面 > 在網際網路應用中,高併發系統會面臨一個重大的挑戰,那就是大量流高併發訪問,比如:天貓的雙十一、京東618、秒殺、搶購促銷等,這些都是典型的大流量高併發場景。關於秒殺,小夥伴們可以參見我的另一篇文章《[【高併發】高併發秒殺系統架構解密,不是所有的秒殺都是秒殺!](https://mp

視頻播放技術優化揭密

切換ip 安卓系統 https 移動客戶端 思考 智能 不出 獲取 cnblogs 本文為轉載文章,文章來自:王輝|十億級視頻播放技術優化揭密 QCon是由InfoQ主辦的全球頂級技術盛會,每年在倫敦、北京、東京、紐約、聖保羅、上海、舊金山召開。自 2007年

(轉)日交易額百交易系統的超輕量日誌實現

加載文件 all 觸發 lock Coding world ole span pub 逛園子的時候偶然發現了《日交易額百億級交易系統的超輕量日誌實現》,感覺博主的思路很強,可惜是一個JAVA版本,於是我將它翻譯為C#。 開發環境VS2

Nginx負載均衡與反向代理—《流量網站架構核心技術》

小時 維護 額外 nat gzip 網站架構 weight 2.7 熱點 當我們的應用單實例不能支撐用戶請求時,此時就需要擴容,從一臺服務器擴容到兩臺、幾十臺、幾百臺。然而,用戶訪問時是通過如http://www.XX.com的方式訪問,在請求時,瀏覽器首先會查詢DNS服務

關於流量網站架構一書緩存機制的探討

obj dpa array ride 定義 from 有客 build 遠程 在京東的億級流量網站架構一書,175頁介紹緩存有這樣一段話 僅就這段代碼來看,在高並發情況下,實際上並不能阻止大量線程調用loadSync函數 當然這個書裏的代碼是作者的簡寫,這裏探討只是針對書