揭祕！閒魚拉新投放系統如何設計

做者：閒魚技術-長玖

背景

閒魚目前已是國內最大的閒置物品交易平臺。隨着閒魚體量的增加和用戶規模不斷擴大，閒魚App上的一個普通banner抑或是feeds中的一張普通的卡片，天天均可能被數以千萬計的人看到。

爲了更好地服務好廣大的用戶羣體，更加個性化的內容推薦和更加精細化的素材投放就顯得尤其必要了。今天咱們來聊一聊如何設計一個能夠精準觸達用戶、運營快速試錯、解放開發生產力的投放系統。

思路分析

投放是什麼？舉例來講，往城市廣場的一塊廣告牌上在不一樣時段不一樣場景下更換廣告畫就是一種投放，固然互聯網技術帶來了人的維度，不一樣用戶看到的廣告畫可能也是不同的。咱們來看下這樣一個系統應該包含哪些功能。

一、咱們把「城市廣場上的那塊廣告牌」叫資源位，那麼須要一個服務端接口來獲取須要透出的素材。
二、不一樣資源位須要透出的素材格式多是不同的，多是banner，多是feeds，多是運營自定義的手填數據，多是任何合理的數據結構。
三、同一個資源位，不一樣時段，針對不一樣平臺、不一樣人羣，透出的素材多是不同的，那麼就須要有一個服務來在一堆素材中篩選出適合資源位的內容。在資源位命中了多個素材的時候，還須要有一些機制來裁決出最終透出的那一個。

詳細設計

咱們設計的投放系統扮演的是前端實體資源位和後端多種數據源之間的橋樑的角色。它負責從各個業務數據源中根據必定規則篩選出在特定資源位上須要透出的數據，基本的數據流以下圖所示：

資源位

所謂資源位，在咱們這個體系內，是指前端頁面上的實體坑位。是技術同窗在產品開發中建立的。理所固然，資源位須要消費的數據結構是在開發階段就肯定了，好比banner、feeds或者結構很是靈活的手填數據等。

在咱們這個體系裏，咱們用一個 schema 描述資源位須要消費的數據結構。

這個 schema 是用 json 描述的。技術同窗在前端頁面上開發實體資源位後，須要在咱們的系統中建立對應的虛擬資源位，並經過一個圖形化的 json schema 編輯器來定義這個資源位須要消費的數據結構

投放物料

上述 schema 定義了一個資源位所須要消費的數據的格式。可是光有 schema 是不夠的，由於資源位要消費的數據，而不是數據結構自己。在咱們的系統中，咱們用一個動態表單模塊根據schema生成動態的表單，產品運營同窗經過動態表單生產的數據，咱們稱之爲投放物料。資源位消費的就是投放物料。

對於一些手填數據，表單直接產生的數據就是資源位可用的了。可是對於 Feeds 之類的，表單每每只能定義 Feeds 的一些諸如選品等特徵字段。對於這類特殊類型的數據源，服務端就不能簡單的直接返回數據了，須要根據這些特徵字段，作一些數據查詢和數據解析工做，再返回給前端一個完整規範的數據。

投放單元

前述文章說到，同一個banner，可能對新用戶投放的是紅包，對年輕男孩子投放的是手機數碼內容，對年輕女孩子投放的是美妝服飾。咱們把這個鏈接了資源位、投放物料與多個投放因子的橋樑叫作投放單元。

那麼投放單元須要有多少個投放因子呢？實際上是視業務而定的，咱們認爲基礎的投放由於應該包含 投放時段、投放人羣、投放平臺、投放AB配置等。

當資源位向投放系統發起請求拉取數據時，投放系統在這個資源位上掛載的全部投放單元中根據投放因子篩選出命中的投放單元，最後將命中的投放單元上掛載的投放物料返回給前端的投放資源位。當命中了多個投放單元時，須要有些方法來裁決出最終勝出的那一個。這個方法簡單點作，能夠在投放單元中配一個權重，篩選時最後選擇權重高的那個，也能夠引入算法決策，根據投放的 ctr 數據作排序。

投放計劃

投放計劃是產品運營對多個資源位管理形式。簡單來講，一個投放計劃下，能夠掛載多個關聯的資源位。試想一下，一次大促活動可能涉及到幾十個資源位的投放，將這些資源位組織到同一個投放計劃中進行管理，能夠更加方便操做以及查看投放效果。

端側接入

對於前端來講，咱們但願經過提供一個封裝的npm包，經過簡單調用，傳入resourceId(資源位ID) 便可獲取數據。

這種調用方式對業務調用方來講是比較優雅的，可是對頁面性能來講倒是不省心的。由於一個頁面每每由不少個資源位組成，每一個資源位單獨發起請求就會造成大量的併發請求，不只頁面性能會下降，還會對服務器產生比較大的qps壓力。

針對這種狀況，咱們作了一個小優化。服務端提供一個批量查詢的接口，前端SDK內部，每10ms 對模塊的請求調用作一次聚合，將單個資源位的數據獲取轉化成批量的查詢。負面影響是對部分資源位的數據加載形成最大10ms的延時，優勢是提高了頁面總體的性能，有效減少了服務端QPS壓力。

效果

上述投放系統在咱們的拉新業務實踐中run得很是好，已爲閒魚應用內的數百個資源位提供投放能力支持，天天服務數以千萬記的閒魚用戶。既實現了資源位的精細化投放，提升了單個資源位的利用率，又賦能運營更自由地進行各類拉新投放實驗，減少試錯成本，還減小了技術同窗頻繁參與運營實驗改造的開發工做量，解放了技術同窗的生產力。

總結

上述文章介紹了一個簡易的投放系統的設計思路，本質上是一個鏈接前端實體資源位和服務端多種數據源的橋樑的設計。

其中有不少能力是依賴了團隊內部其它同窗努力的成果，好比：
一、描述資源位數據結構的 json schema如何設計
二、根據json schema動態生成的表單怎麼實現
三、人羣校驗的服務和能力
四、AB測試的能力
五、feeds 的選品服務
四、個性化動態banner能力

還有不少能夠優化的點，好比數據迴流如何作得更好，怎樣引入算法能力對策略篩選進行優化。。。持續優化、持續爲業務創造價值是咱們一直堅持努力的方向。

原文連接​

本文爲雲棲社區原創內容，未經容許不得轉載。