一、公司介紹

神策數據是國內一家專業做大數據分析和營銷科技的數據服務商。公司成立七年，現有規模 1200 人，七年累計服務2000 多家的客戶，積累了許多行業經驗，并與信通院聯合發布了消費者行為分析標準。

二、營銷場景的數據中臺建設思路

在介紹營銷數據中臺的建設之前，先來討論一下營銷業務對數據的需求。我們期望幫助企業構建一個基于數據驅動的用戶旅程。

比如一個企業的用戶，可以通過線上或者線下途徑來了解這個企業及其品牌。其中線上包括APP、網站、小程序、公眾號等。用戶也可能會去到線下的門店，購買商品、體驗，或是成為公司的會員。對于企業來說，線上的行為數據，線下的交易數據、業務數據，共同構成了企業對用戶認知的基礎。

企業通過數據集成、ID關聯，再加上數據分洗、標簽加工等等方式，將數據打通，從而構建起用戶檔案，在用戶檔案的基礎上使用例如RFM、 AIPL 等模型，即可推斷出一些用戶的潛在價值，或者在用戶生命周期內的定位。

當我們希望去提升用戶留存或用戶復購的時候，在達成業務目標的通路中就可以基于數據制定一些營銷策略，比如給用戶發送一些定制化或者個性化的權益，通過短信、微信或電話等方式將權益通知給客戶。無論采樣何種方式，我們最終希望的是將所有的數據都打通，讓用戶得到更好的體驗，并且最終沉淀成企業的數據資產。為企業長期的數字化經營提供科學依據，打造數據基礎。

上圖也體現了神策一直強調的 SDAF 數據營銷閉環的理念（Sense 感知，Decision 決策，Action 行動，Feedback 反饋）。這個過程里，數據是貫穿始終的。

企業想要構建一個高效的數據驅動的用戶旅程，一定是要建立在數據基礎之上。很多企業中都已經有一些數據分析系統，或者是數據營銷系統，我們期望數據中臺能夠起到承上啟下的作用，避免煙囪式的系統建設，將數據在系統之間進行打通并可以聯動。

神策的營銷數據中臺也是基于此目標，通過將數據集成、數據建模、數據加工和數據應用這四大關鍵環節能力的提升，來為企業打造個性化用戶旅程和更多營銷場景提供更好的數據支持。這也是我們認為營銷數據中臺應該解決的四個主要問題。

首先是數據集成，要接入完整的行為數據和業務數據。由于交互方式多種多樣，所以需要具備靈活配置任務、可視化管理任務的能力，并提供完整的任務監控。

第二個是數據建模，要對數據進行有效的整理，企業每天的數據紛繁又龐雜，業務又靈活多變，最終數據的目標是讓業務人員能夠看懂數據，并且能夠使用數據，這就是數據建模要集中解決的問題。

第三是數據加工，顧名思義，就是對數據做一些處理，這里主要指的是業務上的處理，比如一些客戶的標簽、業務指標，以及相關的一些數據分群等。

最后是數據應用部分，主要是將數據中臺所持有的數據提供給分析系統、報表系統、營銷系統等，并且承擔多種系統之間的串聯，以及數據的互聯互通等職責。

接下來分別展開介紹這四部分。

1、介紹數據集成

與所有數據中臺相同，我們首先要做的就是將數據接入。

通常最主要的數據源有四類。第一類最典型的是線上或者線下產生的用戶行為數據，來自于 APP 或小程序等；第二類是業務數據，來自各類的業務系統，比如訂單系統、會員系統或是商品管理系統等；第三類是一些第三方數據，比如來自于廣告平臺的廣告投放數據；最后一類是企業自建的數據倉庫或數據湖，其中沉淀了眾多業務集市數據。

面對多種數據來源，神策的產品中做了一個數據統一的可視化的數據接收框架。針對用戶行為數據，是神策相對來說最擅長的，有神策的 SDK 可以支持此部分的數據接入，其他數據的接入也提供了對應的批量或者是實時的導入工具。

在整個數據接收框架中，最新的產品中最重要的改進有兩部分，一是數據對接的任務開發的成本優化，讓各種數據源的數據能夠輕松地接入到數據中臺中。最簡單的方式是數據工程師在界面上寫SQL即可將數據接入，做一些簡單的清洗和格式轉換。稍復雜一些的是通過SeaTunnel這個框架做一些定制任務的開發，可以做一些較復雜的數據格式轉換。在未來我們希望能做到對接一些行業標準的 CRM系統或ERP系統，通過一些套件做到一鍵接入。

在數據對接任務開發之后，后續是一些可視化的管理功能，比如任務的啟停、故障和運行日志等等，主要是為了問題定位。其中比較關鍵的是數據血緣，意義在于當出現故障時可以及時通知下游或是做數據回溯，可以有效地降低系統故障對業務造成的影響。

2、數據建模

企業運營過程中，業務方可能會提一些營銷活動的需求，要基于一些規則圈選出一些客群，通過對客群的分析，對人群做一些層次的劃分，比如高頻高價值、低頻低價值等。再對這些不同層次的客戶做一些個性化的營銷策略來完成整個活動。后續還要對營銷活動的效果做一些回溯，做一些復盤數據分析進行展示的。

數據部門在接收到這樣的需求后，首先可能要從幾百上千張表中找到對應字段，還可能需要在多張表中對其指標口徑，接著做開發、測試、調試、上線，再經過幾輪迭代，整個過程可能要數日甚至數月，就可能錯過了營銷的最佳時機。

為了提升整體的實效性，我們認為中臺最終的目標不是把數據接進來就行了，而是要讓業務部門能夠高效、便捷地使用數據，實現業務目標。

神策提出的 EUI 模型（Event-User-Item）在用戶行為分析領域發揮了非常大的價值，也幫助了非常多的客戶。但隨著營銷業務落地場景越來越豐富，此模型也遇到了不少挑戰，所以在最新的產品中對模型做了更多的擴展。在營銷場景中，使用到的肯定不止是 C 端用戶維度的一些數據。有的企業比如 B2C 企業既關注 B 端企業，也關注 C 端用戶；零售企業關注消費者、員工、商品、供應商、門店等。這些不同實體的數據在整個營銷場景中都會被不同程度的交叉使用。

因此，我們的最新產品中提供了多實體模型，除了用戶以外，我們還可以將門店、員工、導購商品等所有產生數據的主體定義為實體，每個實體都可以有自己的屬性標簽和事件，形成自己的數據體系。在整個產品體系中，每個實體的業務能力應該是等價的。例如，用戶和門店都可以有標簽，通過員工事件還可以分析員工的服務質量。

在某些復雜的營銷場景中，例如零售企業，在總部下發營銷指令后，門店通過渠道觸達自己維護的用戶，并根據用戶的過往習慣推薦最新上架的商品。在這樣的場景中，涉及到員工、消費者、門店、商品等多個實體，以及它們之間的關聯關系。對于業務來說，這些實體之間的關系比較好理解，但是對于傳統的大數據系統架構來說，處理這些關聯關系是比較困難的。因此，我們認為多實體是一種業務比較容易理解的數據組織方式，適用于NO SQL架構，更好地解決了大數據系統架構的問題。

另一方面，我們面臨著業務數據和行為數據的打通和融合的挑戰。例如訂單數據，它通常具有訂單ID和狀態，如下單、待支付、未發貨、已完成、已發貨等。如果用用戶行為事件來表達這些狀態，那么一條數據會被拆成多條，存在大量數據冗余。此外，業務人員也難以理解其含義。因此，在我們最新的系統中，引入了明細數據類型。例如在金融場景中，有理財持倉明細等數據。每條記錄包括用戶ID、理財編號、當前凈值、盈虧情況等。明細數據和行為數據最大的區別在于明細數據有狀態，而事件數據是歷史快照，不可變更。結合起來，我們才能更好地支撐營銷數據體系。例如，在持倉明細中，我們可以判斷用戶是否有理財產品即將過期，并推薦類似理財產品，從而提升續存率。

3、數據加工與應用

在數據建模完成后，我們提供了從總體到細節的數據查看能力。系統提供了數據資產視圖，可以總覽數據總量、標簽數量、分群數量、ID數量等信息，還可以進行不同程度的下鉆，例如進入到某一分層用戶列表或單個用戶的360度畫像。

標簽和分群是營銷場景中非常重要的處理方式。在這些方面，相對于以往的產品，我們做了很多增強。

首先是標簽方面，神策的產品一直以來都是以行為數據為主進行建設的，包括用戶行為和行為標簽的建設，同時也會進行事件的聚合統計等等，如用戶行為偏好等方面的標簽。在引入了業務明細數據后，我們對標簽規則進行了很多改進，可以將業務數據融入整個標簽計算規則中，并提供函數表達式等方式，除了進行聚合計算外，還可以進行加減乘除函數等計算。除了行為標簽外，還可以做一些業務標簽。并且為了支持更復雜的場景，在規則方面，我們還支持插件化能力，例如企業已經有了內建的算法平臺，可能會產生一些算法標簽，我們也可以支持這些標簽的管理工作。因此，在我們的產品中也支持插件化，將定制規則的標簽納入進來進行管理，并進行可視化配置。對于一些行業屬性特別明顯的企業，如銀行、證券或汽車，我們也可以將一些具有行業特征的標簽制作成內置的插件，提升業務人員使用的便捷度。

在分群方面，一般有兩大類場景，一類是公司級的客群的大的分層，如新用戶、潛在客戶、活躍用戶、忠誠客戶等等；另一類則是對于一些臨時性或者單次營銷活動，進行的單次的臨時分群。

我們為不同業務場景、不同角色提供了不同的數據加工能力。比如業務人員可以通過文件導入，從外部系統導入，來創建客群。另一種形式是通過我們數據中臺部門維護好的標簽，包括業務標簽或行為標簽，將標簽組合起來做人群的圈選。比如廣東地區，30 歲到 40 歲的男性會員作為一個客群。這兩種是業務人員非常方便使用的，比如一線的業務人員可能維護200 到 2000 個客戶，可以對這些人做一些臨時性或是周期性的營銷策略。

復雜度稍高一些的是界面規則，是一種規則模板，業務人員通過學習也可以掌握，適應更多的場景。

更為復雜的是神策最新定義EQL查詢語言，即Entity Query Language。EQL與SQL具有相同能力，但是EQL對于業務人員來說更好理解、更容易掌握，它是一種更貼近自然語言的表達方式。

以上多種處理方式，可以滿足從最簡單、最日常的場景，到最復雜、最靈活的場景的各種需求。

最后來講一下平臺能力。作為平臺來說，開放能力是很重要。所謂數據中臺，是一個數據底座，需要支持各種業務系統，因此我們提供了各種Open API，可以進行很多的能力擴展。一方面，在系統中可以做更好的數據輸出，另一方面也可以進行二次開發和定制開發。數據輸出方面，我們支持了流式輸出、訂閱，也支持高并發的查詢能力，從而能夠更好地支持各種在線營銷場景。

三、Q&A

Q1：營銷平臺是如何接入業務明細數據的？神策能夠通過 API 直接查詢業務數據庫嗎？這塊從技術上是如何抽象和實現的？

A1：業務數據庫通常是比如MySQL、Oracle 或者 PG等數據庫，由于要支持業務應用因此負載也不會低，如果把大數據直接加上去是不太現實的。所以接入業務數據庫的一般的方式是通過一些CDC，比如binlog 訂閱的方式，將數據源表直接導入，通過replica 的方式接入，接入后對數據做一些簡單的變形、做一些簡單的清洗或者格式變換，比如加一些數據字典，做一些數據類型的變換，就可以放到大數據系統中來。

Q2：NO SQL 的存儲如何支持多級索引的查詢？比如查詢門店下的導購的信息，可以支持直接關聯查詢嗎？還是業務方使用自己的查詢？

A2：是通過數據建模來做的，此部分無法做到像數據庫那樣的強關聯，但是我們在這個數據模型里面還是做了不少的事情，本質上來說是一些 join 的計算。舉個例子，比如前面提到的理財持倉數據跟客戶的數據是通過客戶 ID 進行關聯的。具體的計算框架，在系統中也做了許多優化將時效性和計算性能提升到最高。