營銷業務場景化支撐

營銷平台業務場景化支撐

一、平台業務發展

營銷平台發展至今，目前支援的業務已達40+，從最早的聚劃算，到後來接入淘搶購，outlets（以前叫淘清倉）組成的營銷矩陣，再到2017年來陸陸續續接入了30多個業務，覆寫了自營營銷，會員線，品牌營銷，新零售等多條業務線，業務成果有目可睹。

但是一個強大的平台并不是一蹴而就的，平台在産品和系統上也經過了漫長的磨練，才能達成現在這種效果，能在1~2周内完成一個新業務接入，部分業務可在1~2天内傳遞業務進行試用，而産品和開發人員并沒有太大的變動。

總結起來，發展曆程可以大概劃分為三個主要階段：

• 2010~2015年，聚劃算，單站的團購營銷系統
• 2015~2016年，營銷矩陣，接入了搶購和outlets，這個時候平台能力初現雛形，平台化能力并不完善
• 2017年~至今，營銷平台，這段時間内各業務系統完成了平台化改造，資料權限隔離，并将業務接入産品化，極大節約了開發效率，加快了業務的支撐速度

二、現狀及問題

但是随着業務的指數式爆炸增長，帶給平台的壓力不隻是業務接入的支撐上了，因為在業務接入産品化改造完後，業務的支撐速度很快。但是由于各系統的功能是全面鋪開給各業務使用的，系統能力也耦合在一起，這對于很多新小業務來說，是個很沉重的負擔，痛點集中在如下幾個方面

業務隔離：

對于所有業務呈現同樣的功能，對于簡單業務來說功能多且雜；一個功能上線影響全部業務，很多業務同學會經常來問這些功能是幹嘛的，答疑成本很高，給業務同學帶來的困擾也很大

接入成本：

由于接入業務的時候，各個需求開發的能力都能沉澱下來，但是最終形成的結果是平台功能及規則太多，活動配置項近200項，新業務快速試錯成本太高，每一項的解釋成本很高，建一個活動花費時間很長

能力複用

上一點也說到了，業務需求可以讓系統能力沉澱更多，但是沉澱的能力多的情況下會失控；而且同一個能力想複用到不同的業務線上，必定存在着差異性的規則配置，這份規則配置如何管理成了一個很大的問題，很可能會存到一個開發的臨時存儲，比如diamond，switch，甚至代碼注釋裡，時間一長，職位一變動誰也不知道了當年怎麼回事了。

但是如果想把這個配置項通過産品形式表達給業務，又擔心開發成本提升和增加業務的負擔。

能力表達

• 系統黑盒執行，邏輯複雜導緻系統運作與業務訴求不一緻
• 系統能力無法表達，需要翻代碼或SOP文檔支撐

三、怎麼解決

平台業務的分析

分析一下現在的現狀，擺在我們面前需要解決的最大的問題是，如何實作同一組産品體系，向業務方場景化表達

• 第一是面對不同的業務需求，業務方隻需要關心他們相關配置項
• 第二大層面上的能力組合按照業務需求自由組合

最終達到如下圖的效果：

業務模型的抽象和拆解

想要做到能力的組合，那麼我們首先要做的能力的拆分解耦以及能力的通用化表達

按照目前平台支撐的業務，我們可以分兩個次元來解讀

垂直次元

這裡的垂直次元我們定義為業務次元，比如聚劃算，淘搶購，淘寶直播等等，萬幸的是這些業務之間并沒有太多的耦合；

垂直次元對應我們系統裡面的領域模型就是站點對象；

橫向次元：

橫向次元的分層就稍微複雜點，我們簡單的分為三層：

• 能力域：對于營銷平台的最粗粒度劃分，基于業務産品來劃分，大概劃分為店鋪招商域，收費域，貨品招商域，素材招商域，門店招商域等等，各大能力之間也盡量保持獨立。
• 能力：能力是最基本的一個動作，比如貨品招商域裡，打标，寫UMP優惠，觸發營銷工具生效都算是一種能力；能力之間大部分情況也可以獨立存在，比如可以隻打标，不寫優惠，也可以隻寫優惠不打标，也可以同時進行。能力分為兩類，一種是面向業務同學（非技術人員）的業務能力，一種是面向執行系統的系統能力，後面再講能力執行的時候會詳細講這個點；
• 能力擴充點：擴充點是對能力的擴充屬性，比如拿商品域的打标能力來說，要不要打标是能力次元，打什麼标就是能力的擴充點了。

業務分析

下圖是比較典型的幾條業務線所使用的能力，其實也能看到不同的業務對能力的訴求基本是随機組合的。

業務組裝

有了業務模型的抽象定義（橫向和縱向），我們可以對這些解耦能模型進行組裝（主要是橫向的能力組裝）

主要分這幾部分

• 能力的定義：這裡我們主要說的業務能力的定義
• 能力的組織：以産品的形式提供給業務同學進行能力的組織，比如活動建立和管理
• 能力的執行：對于業務人員和系統來言，他們所需要的能力描述就不一定是一一對應的，比如營運同學在活動組織的時候勾選了上主團露出，其實對于系統來說有兩個能力，一個是露出費用的收取，一個商品在投放端的露出。是以先需要将業務組織的能力訴求，轉換成系統可了解的系統能力訴求，然後各執行系統在執行流程的上下文中，拉取資料，渲染執行邏輯；

大概的系統架構示意圖如下

四、技術實作方案

邏輯實作

上一小節我們有了大概的想法，這個部分我們來摳細節

其實對于每個業務能力點來說，其實對于系統來說就是一份資料，隻不過這份資料的定義和來源不同，如果這個點是業務想要關系并且想控制的，那麼就開放配置給業務同學來配置，如果不想關心甚至不想看到，那麼就在業務接入的時候按照業務特性來配置掉，預設隐藏掉就好了，在日常使用中，不需要暴露給業務方，技術同學關心下就好了。

這麼一來，我們可以給每個規則配置點定義幾個關鍵的屬性

• 唯一辨別key
• 描述
• 是否可見
• 是否有預設值
• 是否可允許業務修改

結合這個邏輯，再結合上一張圖，我們可以細化下邏輯，如下圖所示

技術實作

要涉及到技術細節了話，首先我們得分析下我們的營銷組織的關鍵核心資料模型，如下圖所示：在活動組織招商準備的時候，招商活動其實一個核心的資料模型，因為對于業務同學和商家來說，他們面對的最直接的資料就是活動，業務建立奔着一個營銷目的，建立一個營銷活動，以活動入口為通道和商家達成合作；

這麼看來，那麼以活動為載體承載營銷的相關的規則最合适不過了，實際上各業務執行系統來說，也是直接依賴活動資料作為執行的判斷依據。

是以說如果想達到能力的場景化，如果想簡單實作的話，就是把活動表達場景化。

資料存儲和業務輸入的場景化

如下圖是整個場景化的驅動核心邏輯，themis_element是基本的業務元素metadata，業務需求通過輸入到themis_template中，影響到該模闆下所有活動的元素的顯示隐藏，預設值和是否可修改。

在這裡得益于@月飛 團隊的前端元件化架構nrails，我們設計一套通用化的前後端對接機制，由背景邏輯輸出hide,readonly,defaultValue來控制頁面view層的場景化。

系統執行的場景化

上一步中說的場景化下建立的活動，活動本身就一份規則執行資料，我們隻要把活動上的業務資料轉義成系統的執行資料分發到各業務執行系統，就可以實作商品/素材在不同的活動下不同的表現形式，活動本身帶有場景屬性，那就意味着實作了各業務子系統的場景化了。

然後營銷流程的支撐，是由各系統執行支撐，系統完成了場景化，上層表現也就可以做到核心邏輯的場景化了。

中間的流程轉換層也扮演了一個非常重要的角色，一個是業務訴求到系統訴求的轉換，一個是解決了業務層适配不同系統能力實作的适配；比如商品流程系統cargo有一套能力的掃描注冊機制，那麼轉換層可以按照cargo的規範來适配進行資料轉換；如果商家報名流程的話，同理也可以自定義适配；如果以後各系統執行層統一按照TMF的标準來實作了，那麼隻要實作業務能力對TMF的能力表達進行适配就ok了。

五、思考和總結

其實做業務支撐，像很多背景系統一樣，不會面臨像面向C端的高并發之類的技術挑戰，我們面臨的挑戰大部分是複雜業務邏輯的處理，如果隻是簡單實作了業務需求，是遠遠展現不了我們的價值的。如何實作業務系統的高可用，高擴充性才是我們最大的挑戰。

阿裡是一家商業公司，我們的工作都是奔着商業目的去的，隻不過是間接或者直接的關系了；業務支撐的目标是提效，賦能，通過為公司節省營運成本，提高資産的複用率，來實作自身的業務價值。

而平台和業務之間的關系也是相輔相成，平台賦能業務，業務成就平台。希望我們以後能做得更好

這一套體系其實比較龐大複雜，需要很強的系統架構領域模組化的理論支撐進行梳理總結，非一人之力所能及，在這裡也感謝枯木，良湛的意見，感謝産品，開發，和測試團隊小夥伴群策群力，結合業務系統實際探讨業務架構之路，也再次感謝月飛，落更團隊給予的nrails前端元件支。

和TMF的差別（更新）

文章釋出後，有部分同學私下和我交流中，大家看到業務能力的表達以及域模型定義管理，就會想起tmf2.0；

其實最簡單的區分方式就是，這套場景化面向的使用者是營運業務同學，tmf的業務方仍然是各上層系統，場景化解決的是如何以場景化的方式幫助營運組合各底層營銷工具的能力，以最小成本服務營運，賦能業務。TMF和星環一套很棒的思路和産品，後續我們在底層系統的改造中，也會思考如何借助集團的這些能力，幫我們把底層系統建設得更好。

六、展望

目前隻是完成了第一步的快速落地，借助本次的活動的場景化改造，提升了平台的業務支撐能力；但這還遠遠不夠，我們能力的産品化表達還沒完成，由于平台支撐了如此多的業務，這個也是可以利用起來的有生力量，業務之間的隔離讓我們的支撐能力更強，但同時業務之間的關聯協同對于商家和業務同學來說都是可以深挖的一筆财富。

最後：平台業務文檔，歡迎業務合作和技術交流：

https://lark.alipay.com/marketplatform/overview