作者|馬立銘（波影）
出品|阿里巴巴新零售淘系技術部

在過去的近一年時間裡，圍繞淘系營銷導購的投放能力建設，在“一個淘系、一套體系”的原則下，通過整合原天貓、淘寶、聚划算等的投放系統，使得技術層面可以站在更高的角度，面向新零售進行投放域的支撐與保障，在各個垂直能力建設上做深做強，並服務於集團更為廣泛的業務方。

定向投放（後文簡稱“定投”）的能力建設，在大的投放技術體系內，“一心一役”與各核心應用深度融合與協同，完成了較大的技術升級，服務了淘系（淘寶、天貓、大聚划算）、天貓進出口、天貓超市、AE等業務，幫助業務實現了更多的可能性。

業務形態與技術匹配

在介紹具體的技術架構之前，我覺得應當先對技術所服務的業務進行簡要的介紹，會場業務形態是營銷活動的重要陣地，應該說伴隨著大促一路成長，經歷了從粗放式會場組織到精細化運營的演進。

以雙11為例，我們看到，拉新進入會場的人群有特殊的貨品承接、互動向會場導流後有專門的任務模塊引導消費者完成會場瀏覽、平臺與商家之間通過特定版頭與樓層在會場完成了商業化的資源置換、越來越多的商品或服務基於地理位置的匹配觸達到了消費者，這一切背後的思考脈絡都圍繞著會場效率的提升。

回到操作面上，個人總結了一個會場業務的本質公式：頁面 = 樓層結構 + 數據。

樓層結構是整個頁面的架子，排期召回的數據則填充了頁面的內容。運營同學的主要抓手就是樓層結構的規劃和樓層內商品、店鋪或權益的數據投放策略。

定投能力的建設，技術層面通過梳理業務的共性訴求，集成了“區域”、“人群”、“時間”、“請求標識”四個領域的規則判斷能力，並圍繞“頁面”、“樓層”、“排期”三個業務關鍵詞，構建與業務相匹配的三個技術支撐維度（即頁面級定投、樓層級定投和排期級定投），形成了覆蓋領域及支撐維度日趨完備的“四縱三橫”定投技術架構。

縱向領域能力集成

以定投規則所依賴領域能力的編排作為基礎，從設置端到消費者鏈路完成規則創建、更新與預熱的管理，以及規則的判定執行。

▐ 規則編排

不管做哪個維度的定投，基礎都是對不同請求的識別能力，我們分析得出業務的定投需求主要集中在“區域”、“人群”、“時間”、“請求標識”四個領域。我們將各個能力封裝為對應的判定處理器 Processor，並提出了結構化的定投規則 DSL 規範（支持兩層“與或非”的組合邏輯關係），以支持 Processor 的邏輯編排，依據該規範完成對定投規則的描述與解析執行。

▐ 規則創建、更新與預熱

規則的創建與更新過程涉及DSL描述的持久化，存儲包括 DB 和 OSS 兩部分，其中 DB 用於設置端的增刪改查，OSS 則對所有定投規則的當前及歷史各版本進行存儲，依託阿里雲的 OSS 傳輸加速（通過網絡協議優化，加速 Bucket 遠距離訪問）和 CDN 全球加速能力，使得部署在任何機房的定投 SDK 都可以快速獲取所需的定投規則描述。

與此同時，為應對消費者側業務（特別是大促會場）對服務端接口響應的 RT 的嚴格要求，定投二方包內部基於 Guava 還有一層本地緩存，使得投放應用集群能夠大概率在本地讀取到熱點定投規則。

針對雙11大促等重保場景，我們還加入了規則預熱的功能，二方包在接收到指令後，會主動向 CDN 拉取指定的定投規則，完成0點前的提前預熱。

▐ 規則判定執行

定投規則的執行分為兩步：預處理和並行判定。往往一次請求對應多個定投規則需要進行判定，預處理主要針對有遠程調用的判定，以區域判定為例，在將請求中攜帶的IP、經緯度等信息提取出來後，預先請求相關服務獲取用戶的地理位置，後續每條定投規則的判定過程，就可以直接拿預處理獲取的地理位置做判斷，而不用重複請求地理服務。

橫向投放體系協同

前面介紹的縱向領域能力集成，從規則的描述與編排到創建、更新與預熱，主要圍繞定投規則展開。在完成了縱向能力建設之後，定投應用於實際投放場景還要回答一個關鍵的問題：如何與現有投放體系融合？這就引出了橫向投放系統協同的話題。

經過多年的發展，技術和業務有其“變與不變”，就像 頁面 = 樓層結構 + 數據 這個公式，它似乎是不變的，但公式背後的技術迭代早已滄海桑田。

近年來，電商通過個性化技術服務消費者成為了提升用戶體驗的有效途徑，不過這也對傳統的投放技術架構產生了較大的衝擊。在以往大促中一直佔據核心地位的 CDN 純靜態頁面，無法支持動態化內容組織的業務需求（包括樓層的定向投放）。

面對這一挑戰，我們將靜態的頁面模板與動態的頁面結構渲染（以及數據請求）進行了分離，並且以頁面為視角建設了邏輯網關層，負責組織頁面結構並向資源位投放系統請求所需的數據。因此，定投 SDK 需要與邏輯網關和數據投放系統進行對接，以滿足頁面、樓層、排期三個維度的定投需求。

▐ 邏輯網關

邏輯網關面向前端提供了服務端 JavaScript 運行容器，並支持對外部數據源進行統一封裝，可以作為一種 BFF 中間層，用以完成頁面結構和數據的合併請求，與終端性能秒開方案相結合，使前端在實現複雜業務需求的同時，依然可以保證頁面/接口的加載速度。

基於JavaScript運行容器，邏輯網關實現了一套Handler插件機制，Handler開發者可以獲取到用戶請求對應的頁面結構，以及經過網關統一數據源封裝的數據，通過編寫JavaScript代碼完成業務邏輯。網關通過將定投二方包作為其數據源接入完成定投能力的對接，同時網關向內部 JavaScript 容器提供了重載新頁面結構的方法，以支持頁面定投的需求。

頁面和樓層的定投規則經由搭建系統寫入頁面模板，邏輯網關收到請求後，首先會獲取到頁面結構，後續的Handler邏輯流程都可以對頁面結構進行修改。樓層定投就是對頁面結構的局部修改，而頁面定投則是完全用另一個頁面的頁面結構覆蓋當前的頁面結構（重載）。

▐ 資源位投放系統

為了靈活支持業務的擴展，資源位投放系統負責根據業務場景對數據召回、排序、補全、去重進行業務串聯，我們將定投能力集成到排期召回環節，以實現排期數據定投。

業務案例

▐ 頁面定投

以2019年雙11為例，頁面定投主要承擔了國內雙11主會場向天貓海外主會場的分流，由於在邏輯網關中實現了頁面重載，海外用戶在通過https://1111.tmall.com訪問主會場時，會被毫無感知地（沒有白屏二跳的糟糕用戶體驗）分流到對應的海外地區主會場。

▐ 樓層定投

樓層定投在大促活動中支持了互動流量的承接、會場效率提升、平臺與商家的資源置換等場景，這裡先舉幾個case。

CASE 1：雙11合夥人互動玩法每天會向主會場及各行業會場導流，從互動引導進會場的用戶會看到額外的“爆款必買好貨”樓層，該樓層有專門圈選的商品做承接，並通過倒計時獲得喵幣引導用戶在會場“逛起來”。該樓層利用“請求標識”進行定投。

CASE 2：有價券在淘寶營銷活動中的核銷率較高，有價券模塊出現在此次雙11淘寶嘉年華活動的主會場、各行業分會場與神券會場，通過一天多個時間點定時上架開售的玩法吸引用戶保持對會場的關注。為提升會場效率，有價券樓層只會在特定的心智時間進行展示，其餘時間將空間留給下面的樓層。因此通過週期性時間定投控制展示節奏。

以上兩個 case，樓層的顯隱除了利用定投來控制之外，還可以由前端模塊自行處理相關的邏輯，那麼為什麼要使用定投呢？主要有以下幾點考慮：

在邏輯網關 Handler 層控制樓層定投，可以提前阻斷樓層關聯的資源位數據排期召回，減少無用的數據請求，降低 RT。

如果由前端處理隱藏樓層，那麼該樓層中的商品雖然沒有實際曝光，但依然將參與去重，這會導致這部分商品始終無法展示給消費者，而使用定投則可以解決這一問題。

可以使前端模塊更具通用性，專注業務邏輯。

▐ 排期定投

隨著本地化的業務策略持續推進，雙11造勢期天貓在不同城市推出“新車團購節”，在線上會場的版頭位置，需要根據訪問用戶的區域，定向展示當地線下活動的日期和地址，如下圖所示該需求利用排期數據定投的方式實現。

展望

定向投放作為一種會場的運營抓手，能夠幫助業務實現投放的意志。我們也發現運營同學越來越注重數據對投放策略的指導作用，No Data No BB，再反觀一次營銷活動，從造勢到預熱再到正式售賣，特別是618、雙11這樣的S級大促，拉的戰線是比較長的，在這類長線營銷活動週期中，運營更希望在活動前期試驗各種想法，通過獲取數據支撐，幫助其在正式售賣階段達成更好的效果。因此在定投之外，運營對於AB實驗的需求也較為旺盛。

長遠來看，如何將多種運營策略的技術工具進一步融合，封裝成真正的運營策略產品賦能業務，是需要我們進一步思考的。

We are hiring

我們是淘系技術部營銷中臺團隊，作為新零售的主引擎支撐了包括618、雙11、雙12等大促業務，聚划算、天天特賣、百億補貼等營銷業務，服務了全球百萬級商家、數億級消費者。在這裡可以感受到新零售業務發展的浪潮、複雜多樣化的商業模式、雙11最核心的商業策略；技術上可以接觸到複雜營銷業務模式下的領域建模、高併發高穩定性的極限挑戰、大數據精準高效的供需匹配。我們有豐富的商業場景，更有不斷創新的工程師文化，通過平臺能力的沉澱和創新，賦能業務和客戶，驅動新零售營銷業務的升級，是你施展能力的舞臺。作為淘系營銷的核心技術力量，我們期待更多的同學加入我們一起同行，為阿里經濟體建設更高效的營銷中臺！

請投遞簡歷到郵箱：[email protected]

關注「淘系技術」微信公眾號，一個有溫度有內容的技術社區~