導讀：從2020年開始，百度開始構建本身的商品推廣系統，目前系統應用在百家號和直播場景中，爲B端商家以及C端做者、主播提供了便捷帶貨流程，爲廣大用戶提供了直接簡單的購物體驗。本文按照業務概念、用戶界面、系統架構、核心實現的順序介紹商品推廣系統，旨在拋磚引玉，但願能給讀者帶來思考和幫助。前端

全文5874字，預計閱讀時間12分鐘。算法

1、推廣流程概述

上次談到的《百度交易中臺之訂單系統架構淺析》，講述了訂單系統的實現方式以及迭代流程，本期基於訂單系統，繼續介紹推廣系統的設計與實現。數據庫

商品推廣系統，是目前電商平臺帶貨場景業務下較爲常見的系統。*寶聯盟、*東聯盟、多*進寶等都是相似的商品推廣系統。在當今社會中，隨着知識付費、短視頻、直播業務的繁榮，大衆表達自個人門檻開始下降，愈來愈多的內容創造者（短視頻時代，大部分的內容創做者是做者或者主播）具備了強大的影響力。因而面向商家、做者（主播）的商品推廣系統就顯得十分重要，這個商品推廣系統鏈接了BC兩端，極大的解放了生產力。小程序

商品推廣系統圍繞着做者（主播）、商家、用戶爲核心，提供一個能夠同時服務三者的平臺。在推廣流程中，不一樣的角色有特殊的稱呼，做者（主播）稱爲流量主，商家稱爲廣告主。後端

（1）流量主

商品推廣流程的目標是最大限度的促成交易。推廣商品的通常手段是提升商品曝光量、增長商品點擊量，越多的人看到商品，促成交易的可能性就越高。商品推廣系統則是經過聯合有影響力的主播或者做者，一塊兒進行推廣，藉此來擴大影響面，就是一般人們口中說的「帶貨」。這個方案，主旨是經過影響有影響力的人，經過品牌效應、名人效應去達到宣傳商品的目標。參與推廣流程的做者或者主播，因爲能夠幫助訂單系統吸引流量，所以稱爲【流量主】，下文統稱參與商品推廣流程的主播和做者爲流量主。安全

（2）廣告主

在常見的商品推廣流程中，爲了吸引更多的流量主加盟參與推廣，會根據商品的類別，酌情爲每一筆訂單設計一個佣金比例，若是消費者經過流量主提供的入口進行商品購買，則流量主會得到必定比例的分傭返現。分傭返現的金額，由商家或者平臺提供，根據不一樣的場景會有不一樣的策略。網絡

對於須要推廣商品的商家來講，一個推廣流程，至關於進行了一次對商品的廣而告之，只不過這個廣告不必定來自某個廣告公司，也可能來自某個名不見經傳的普通人。這些商家角色，在推廣流程中，被形象的稱爲【廣告主】。架構

（3）CPS

隨着科技的發展，3G和4G網絡讓移動支付成爲了互聯網革命的「蒸汽機」，5G和大數據則讓信息立體化。商品推廣流程在兩者的基礎上，提供了讓更多人蔘與到交易當中的機會。常見的電商平臺基本都支持分傭推廣，在電商場景中，通常經過CPS方式實現分傭動做。負載均衡

CPS是Cost Per Sales的簡稱，是在商品推廣中常見的計費手段，經過實際的銷售量進行收費的，更適合購物類APP進行推廣，可是須要精確的流量進行數據統計轉換。框架

2、百度商品推廣流程業務特色

CPS推廣帶貨，一共須要面向3個不一樣維度的用戶提供服務，分別對應上文中的流量主（主播+做者）、廣告主（商家）、用戶（消費者），同時，整個CPS推廣系統的建設，也是從這三個點入手進行功能拆解。能夠將其拆分爲3個用戶界面服務以及5個內部核心服務。

（圖1：百度總體帶貨體系構建）

（1）三個用戶界面

從圖1中能夠看到，商品推廣系統，主要有三個用戶界面，分別是針對廣告主的小程序B端，針對流量主的商品選品界面，針對用戶的訂單購買界面。下面分別對三個界面進行說明。

廣告主界面部分，小程序B端服務做爲商家端，爲廣告主提供商品註冊服務，即，廣告主能夠在小程序後臺的界面，開通商品分傭帶貨，從而讓本身的商品獲得推廣。

（圖2：小程序B端帶貨開通界面）

（圖3：小程序B端用戶收益界面）

在實際帶貨流程中，開發者能夠本身做爲廣告主開通帶貨，這樣的方式帶有必定的開發成本（好比噹噹、亞馬遜等）；百度也提供了一套完整的開店服務，能夠經過很是低的成本參與到商品推廣流程之中（好比度小店）。

流量主界面部分，百家號、直播生態做爲選品服務做爲入口，爲主播以及做者提供方便快捷的商品引入，而且在這部分中，還能夠引入百度自有的體系商品。

（圖4：百家號編輯選品界面）

上圖是百家號的編輯界面，流量主經過編輯按鍵的添加商品，能夠從商品庫中選擇商品，而且將商品櫥窗嵌入文章之中。嵌入文章之中的商品連接，若是被普通用戶點擊而且成功下單，則會按照必定規則，將該筆訂單算做流量主的一次推廣。在百家號直播的界面，也能夠進行選品以及添加商品連接，這裏就再也不贅述。

（圖5：選品平臺選擇界面）

圖二，這是百家號的選品界面，能夠看到，在選品中，不只包括淘寶、京東、拼多多的分傭商品，還包括一些具備百度特點的選品庫，包括度小店、噹噹網、亞馬遜、電影票友等。

用戶界面部分，則和廣告主相似，商品、訂單的界面依賴於百度小程序進行展現，這樣的設計方便於在百度APP產品矩陣內進行共享，在技術實現上，廣告主的商品界面，只須要開發一次，便可在全部的百度生態內APP上進行展現以及推廣。

（圖6：用戶界面）

用戶界面主要就是面向廣大消費者，消費者在觀看直播，或者觀看做者的文章時候，若是這個直播或者文章中包含商品推廣的話，就能夠按照圖6中展現的流程進行商品購買。此時購買的商品就是來自於商品推廣系統。

（2）五個核心服務

經過梳理用戶界面，能夠將商品推廣系統按照功能點進行拆分，在本期的實現中，拆分爲5個核心服務。服務見下表：

在5個核心服務中，掛載服務、推廣服務是針對商品推廣場景從新設計以及開發的，交易系統、結算系統、資產系統是交易中臺已經有的能力。

（3）建設具備百度特點的推廣流程

2020年開始，百度着手創建集團內部的商品推廣系統，系統的構建過程當中，面臨不少技術挑戰，主要有如下幾個方面：

百度的業務多個APP造成的產品矩陣，如何提供統一的技術實現方案，讓流量主和廣告主雙方能享受最優質的產品服務
如何在繽紛多變的頁面中，有效的採集用戶的推廣行爲
如何整合現有的訂單和結算系統、輸出一套支付和結算的標準模型

上面只是列舉的一些大的問題點，放到細節之上，還有許多前臺看不到的，可是很影響體驗的問題，好比流量主命中有效推廣以後，是須要分配佣金的，這部分佣金的計算如何實現，分配後的佣金又如何能實實在在的變成流量主的收入？又好比做爲廣告主來講，如何定型定量的看到本身的推廣記錄？老是涉及到資金變更，任何人都想看的仔仔細細。

可是，拋開挑戰不說，從交易中臺開始構建CPS推廣體系，起步就是站在巨人的肩膀上的。依託於底層的交易能力，能夠快速創建一套CPS推廣實現，業務上充分複用已有的能力，包括下單、資金池、資產記帳、提現等均可以快速實現；技術上則能夠依託於交易的底層框架，快速的實現功能。

3、商品推廣服務實現

（圖7：掛載服務&&推廣服務架構圖）

掛載服務以及推廣服務雖然在複雜的商品推廣的體系中佔據了很是重要的做用，可是從設計角度，進行單獨拆分以後，其實各自的功能是比較單一的，這也符合系統之間高內聚低耦合的標準。

上圖將服務按照分層設計的方式，拆分紅爲4個層面，從上到下，分別以下：

業務層：這一層指代抽象的業務，是能夠擴展的多個服務方，不一樣的服務方站在不一樣的角度進行接入，包括廣告主、流量主、用戶多個角度的不一樣服務。

接入層：這一層主要指對業務層提供服務的服務網關層，主要的功能是流量轉發、服務鑑權、負載均衡等。除了常規網關的功能以外，接入層還針對BC兩側(B表明商家、C表明用戶)的不一樣流量進行了分離。其中交易統一網關主要承擔來自消費者的流量，該網關的特色是用戶請求量大，可是相對簡單，所以對於網關的設計，非功能需求方面，性能、安全是主要的考量點。其中電商開放平臺(trade.baidu.com)則做爲商家端的網關入口，這部分網關訪問量沒有那麼高，所以主要側重於業務的處理以及關聯。

服務層：這一層是核心的服務提供者，包括前臺後臺多個服務。

動態庫：商品推廣的核心前端組件，主要負責推廣數據的上報，而且須要保障安全性以及數據合法性；

註冊服務：這是一個後臺服務，提供廣告主流量主的註冊開通，而且聯攜下層的商品系統、結算系統提供商品導入、分傭比例設置的功能，是承上啓下，數據的註冊中心；

掛載服務：掛載服務提供在商品註冊以後，進行商品櫥窗連接生成、數據真實性校驗

推廣服務：商品推廣的核心後端組件，對外承接來自動態庫的推廣記錄上報，對內承接來自交易系統的訂單命推廣斷定。

組件層：這一層依賴於度長內部的各類中間件快速實現功能。

對於推廣記錄以及掛載服務來講，設計難點在於和總體系統的聯繫，自己業務較爲單一，在此值得介紹的包括兩部分，一部分是基於動態庫的推廣記錄上報，另外一部分是則是基於數據庫批寫的寫入優化。

（1）基於動態庫的推廣記錄上報

【動態庫】是百度小程序提供的框架組件，能夠旁路式的爲小程序提供底層的基礎能力，好比ECharts圖表、editor富文本編輯器等。商品動態庫則利用這種旁路的設計方式，嵌入到開發者的商品詳情頁面，而且能夠完整的獲取到商品頁面的擴展參數。（複製此處連接查看小程序動態庫官方文檔：https://smartprogram.baidu.com/docs/develop/framework/editor/）

（圖8：小程序動態庫示意圖）

小程序動態庫如上圖，最上層的是訂單的購買頁面，底層是小程序的運行容器，中間層的就是動態庫。動態庫是按需動態加載的基礎庫，由一些特定的小程序業務平臺方發佈（如大搜、鳳巢等），能夠提供該業務平臺的一些業務功能或約束，動態庫具有以下特徵：

動態庫會靜默更新，由動態庫發佈方決定更新，小程序開發者不能決定什麼時候更新。
動態庫能提供自定義組件或者JS 模塊給小程序使用。
動態庫發佈方如今只能是百度。
動態庫的使用，須要開發者明確的在頁面標識才能引用。

因爲動態庫自己由交易中臺進行開發和維護，推廣數據上報則經過動態庫進行上傳。基於動態庫的數據上報實現，具備明顯的優勢：

一、遵循開閉原則：避免下單頁面中硬編碼實現數據上報。徹底和訂單頁面解耦，不論開發者升級，或者上報邏輯更新，都不互相影響。

二、一處改多處用：小程序動態庫能夠無縫的應用在各個矩陣APP上，後續還能夠開源應用到外部的宿主APP之上，擴展性和兼容性很是好。

三、可維護性優秀：因爲推廣上報徹底脫離了訂單頁面，開發方面不用考慮業務實現以及問題，具有良好的可擴展性。

可是因爲動態庫是比較底層的實現，俗話說能力越大責任越大，動態庫在實際的開發中，對於性能和安全性具備很是高的要求，不能由於動態庫的加載，而拖慢開發的提單頁面。

對於數據協議方面，動態庫雖然能夠獨立於訂單頁面運行，可是如何爲動態庫設計一套普遍通用的數據協議，而且讓其具有良好的可擴展性，這是一個問題。在實踐中，咱們經過對掛載連接功能進行改造，實現了服務端生成連接+動態庫解析鏈接的閉環。

參見下圖中；

（圖9：帶貨連接動態庫閉環）

掛載服務爲選品界面提供連接生成的能力，對於不一樣的商品，會生成該專屬流量主的特定連接，而且攜帶一些擴展參數。這些參數會隨着商品頁面一塊兒加載。這些參數雖然對商品頁面不構成影響，但倒是動態庫加載的必須參數。這些參數包含自驗證機制，若是被隨便修改的話，上報驗證就會發現。對於不一樣的商家和商品，經過在掛載連接中設置不一樣的參數實現個性化的推廣數據上報能力，好比針對不一樣類型的服務，命中推廣連接，在商品詳情頁面的停留時長能夠有必定區別。

統一格式的數據協議，對於後續判斷推廣是否命中也有好處，好比能夠統一的使用時間窗口策略斷定用戶針對流量主的推廣是否命中，對於某些商家，還能夠跳出商品的範疇，直接斷定此時用戶是否命中商家的其餘有效推廣。

（2）基於數據庫批寫的寫入優化

推廣數據上報具備請求量大，業務比較簡單的特色，再加上推廣數據實時查詢的需求沒有那麼強烈，在實際的開發中，咱們針對推廣服務採用了數據庫異步批量寫入的機制來提升性能。

（圖10：批量寫寫入優化）

如今配合上圖說明一下優化流程，改進前的單次寫入，其實就是直截了當的單次寫入，每次數據上報，走一次流程，數據通過控制層、服務層、數據持久層進行寫入。這樣的好處是邏輯簡單，寫入實時性好，適合通常的OLTP服務。可是對於數據上報服務（相似的服務還有打點服務、日誌上報等）來講，並無實時查詢的需求，因此在服務資源有限的前提之下，能夠採用批量寫入的方式來充分利用資源，提升服務的吞吐量。

圖中右邊的部分就是優化後的批量寫入，批量寫入本質上是一個生產者消費者的模型，目標是下降數據庫的TPS。圖中的每次收到上報記錄，就會加入到內存的阻塞隊列中，將同步寫入變動爲異步寫入。隊列每一個必定時間執行一次寫入，這樣一來，數據庫的寫入QPS實際上是大大下降了。

交易中臺中，通常採用橫向分表的db設計，推廣記錄的設計也是同樣，數據表根據分表字段路由存儲到不一樣的數據表中，而且對於不一樣的表，還能夠分離到不一樣的數據庫實例當中，進一步進行水平擴容。下圖是《百度交易中臺之訂單系統架構淺析》中的數據分表規則。推廣記錄的分表方式大同小異。

（圖11：分表規則）

對於這種數據庫結果，在數據庫批量寫入中，還能夠再進行一次優化，即將同一個實例、分表記錄進行聚合，而後統一執行。這樣能夠進一步提升數據庫的寫入效率。

4、總結

商品推廣系統的構建，難點在於業務複雜，構建路徑長，須要跨團隊以及跨部門合做。

業務梳理清晰以後，對於技術側的實現，除了動態庫以外，其餘的部分實現複雜度都不是過高。關鍵在於對邊界條件的控制，對細節的把控是否周全。推廣系統以及交易中臺，有幸站在巨人的肩膀上，踏浪潮頭，天然事半功倍。

從古到今，軟件開發工程多半按照工做領域，劃分爲系統工程師、算法工程師和業務工程師。不管是哪一類工程師，要想不負使命，都須要在廣度和細節之上進行積累，厚積方能薄發。

招聘信息

百度移動生態事業部MEG，用戶中心招聘研發崗位（PHP/GO/C++），咱們主要負責公司Passport、用戶資產、屬性、百度APP會員等核心業務方向，致力於打造高效、便捷、安全的用戶體系。若是你對Passport、百萬級QPS服務、分佈式設計&治理感興趣歡迎加入咱們。

關注同名公衆號百度Geek說，點擊菜單欄「內推」便可加入搜索架構部，咱們期待你的加入！

百度交易中臺之商品推廣流程構建以及實現