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

一、推廣流程概述

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

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

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

（1）流量主

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

（2）廣告主

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

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

（3）CPS

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

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

二、百度商品推廣流程業務特點

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 年開始，百度着手建立集團內部的商品推廣系統，系統的構建過程中，面臨很多技術挑戰，主要有以下幾個方面：

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

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

三、商品推廣服務實現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

由於動態庫本身由交易中臺進行開發和維護，推廣數據上報則通過動態庫進行上傳。基於動態庫的數據上報實現，具有明顯的優點：

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

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

3、可維護性優秀：由於推廣上報完全脫離了訂單頁面，開發方面不用考慮業務實現以及問題，具備良好的可擴展性。

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

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

參見下圖中；

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

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

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

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

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

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

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

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

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

（圖 11：分表規則）

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

四、總結

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

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

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

作者：百度交易團隊

來源：百度 Geek 說

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/h4TRz-8W2ov8hHSF5JKXGQ

猜你喜歡