營銷數據中台白皮書_ZenDei技術網路在線

要實現在不同業務群間做到數據的互聯互通，以及對數據價值的最大化挖掘，便需要對各業務群的數據進行整合以建立集團層面的「數據中台」，統一管理和應用數據。 ...

文章發佈於公號【數智物語】（ID：decision_engine），關註公號不錯過每一篇乾貨。

來源 | 秒針系統（公眾號ID：miaozhensystems）

編者按：2018年，DMP、CDP、CEM、Data Lake突然引起市場關註，「數據中台」更是成為大中型廣告主的數字營銷標配。

「數據中台」最早是由阿裡提出，對標國外「Data Lake」（數據湖）的概念。該概念提出的背景是因為阿裡生態系中淘寶、天貓、螞蟻金服、盒馬鮮生等業務板塊每天產生大量有價值的數據，要實現在不同業務群間做到數據的互聯互通，以及對數據價值的最大化挖掘，便需要對各業務群的數據進行整合以建立集團層面的「數據中台」，統一管理和應用數據。

對於大部分廣告主而言，「數據」仍是一個較為陌生的詞。儘管「數據驅動」代表了先進生產力，但在數據缺少的情況下，企業市場部也仍舊在正常運作，那花費大量成本搭建數據中台，對於廣告主有何價值呢？

01廣告主對營銷數據中台的期望是什麼？

「數據中台」作為營銷技術中最奢侈的投入，是只有大型廣告主才需要的資源，其價值在於：

● 賦予廣告主數字營銷的精細化操作能力，當市場部承接的數字營銷預算大到一定程度時，便無法僅憑藉營銷人員的個人經驗對營銷活動進行微觀操作。而在擁有數據中台後，便可依靠數據+技術，驅動整個營銷體系的精細化操作；

● 提升營銷執行的ROI：這是廣告主最常規的訴求，市場部絕大部分預算都分配在營銷執行層面。按照每年1億的營銷投入計算，如果能通過數據提升1%的精準度，就能為廣告主節省100萬的成本，這是能最直接看到的真金白銀；

● 戰略視角的營銷策略：在打通生產、銷售、電商、服務等數據後，市場部就能看到更加連貫的全局數據，可以站在更高維度審視營銷在公司戰略佈局中的定位和作用；

● 提升市場部內部運營的整合度：當市場部內部職能劃分過細，便需要通過數據來串接營銷運營過程中的市場研究->市場策略->營銷執行->效果考核，避免內部信息不對稱，提升運營效率；

● 加強市場部和其他部門間協作：當企業內部組織架構達到一定複雜度，市場部需要通過數據對接其他部門的運作，在企業統一的考核體系下，於企業內部證明自身價值，爭取更多資源；

● 支撐業務的數字化轉型：「數字營銷」已不再只是營銷辭彙，數據中台所擁有的資源（數據/IT設施/考核規則/運營人員），除了支持營銷場景，還可用於構建各種數字化轉型的業務場景，作為CMO和CEO/CGO/CDO對話的核心資本。有趣的是，今天討論建立營銷數據中台的，除了市場部和IT部門，很多需求是來自更高層的CEO、COO（首席運營官）、CGO（首席增長官），這些高層的訴求是通過「數據中台」來解決業務問題（例如產能過剩、人員效能、獲客），支持企業的創新業務（例如新零售、金融科技、數字化管理）。

02和傳統數據倉庫對比，數據中台有什麼差別？

國外著名咨詢公司Garnter把數據管理技術分為三大類：

● 數據倉庫——支持大多數已知的數據(結構化的、事務性的)和已知的問題(可重覆的、廣泛使用的)，以交付運行業務的共識。

● 數據湖——支持未知數據(缺乏組織、原始數據和/或外生數據)和未知問題(發現和數據科學導向)，以支持探索和創新。

● 數據中心-實現生產、消費系統和流程之中的可管理與可治理的數據共用。

與存儲「已知」結構化數據，解決「已知問題」的傳統數據倉庫（Data Warehouse）相比，數據中台存儲了大量「未知」的原始數據，利用數據科學（Data Science）可在應用層面進行更多探索，幫助企業解決更多「未知」的商業問題。

數字技術的革命，使得廣告主可收集的數據在量級上產生了爆發，因為數據的「量變」，催生了數據管理和應用的「質變」，這是「數據中台」出現的主要原因。如果說傳統的「數據倉庫」面對的是「小數據」，「數據中台」處理的則是真正的「大數據」。

回到5年前，廣告主能收集到的營銷數據大部分來自CRM，是基於消費者「人」的PII數據（Personal Identity information），這類傳統營銷數據是大致如下表一般：

這些數據源自廣告主的運營過程，數據量級相對較小，每年所能收集的數據很難超過TB級別。數據的使用層面也相對簡單，一個初級的數據分析師，可以依靠數據詞典輕易讀懂每條數據的含義，依靠傳統統計學和演算法工具就可以完成數據分析，支撐業務應用。

例如CMO想針對貢獻了80%收入，但過去2周沒有任何採購行為的高消費用戶群體做一次活動，不到10行SQL語句就能抽取這些目標消費者數據。

今天，廣告主收集了大量描述消費者行為的「大」數據（在後文會詳述數據中台的主要數據類型），這些數據是基於消費者「設備」的數字數據（Digital Data）：

消費者使用的數字設備（手機、電腦、Pad等），每天都產生百萬級的行為數據，廣告主能輕易在數周內收集到TB級的數據。但這些大數據的管理和應用也對數據中台提出了更高的要求，主要技術革新包括以下三點：

01數據中台的技術革新1：數據治理的難度增加

傳統營銷數據大部分是基於email地址、手機號和姓名對消費者進行識別，不同數據源的打通難度較小。但消費者行為大數據基於多種ID（手機號、設備ID、Cookie ID、Mac等，具體在後文介紹），僅依靠廣告主自有能力，很難實現ID的打通，打通的比率取決於廣告主的數據量大小，在廣告主的數據量沒有達到足夠海量前，需要依靠外部數據資源實現。

此外，消費者行為大數據中異常數據的比率遠高於傳統數據，例如廣告主收集了1000萬條瀏覽過自己主頁的設備ID，這裡面可能涉及到爬蟲、虛假流量、無效瀏覽等多種場景，真正有價值的消費者數據量甚至會少於異常數據，這時需要通過演算法或者外部數據資源對這些無意義的異常數據進行清洗。

02數據中台的技術革新2：數據分析的方式發生了根本變化

消費者行為大數據的解讀沒有以往這般「直接」，知道了消費者瀏覽的URL，知道了他們在每個頁面的停留時間，知道了他們經常出現的經緯度，這些大數據如何和業務關聯和使用呢？

如果把這些原始數據比喻成蔬菜，在端上飯桌實際應用前，需要經過一個「烹調」的過程，即把原始大數據簡化成業務側能讀懂的標簽，「烹調」的方式有2種：

a. 基於廣告主收集的ID，到外部直接採購現成標簽：例如廣告主收集到瀏覽過自己官網的設備ID，想知道這些設備ID背後的消費者畫像，可以對接外部數據源，對這些ID補充年齡、收入等標簽，這個過程被稱為Data Enrichment(數據擴充)。

b. 通過「知識圖譜」進行數據結構化處理後，建立自定義標簽：例如廣告主收集了某消費者一天1000條位置數據，如果手上有全國所有小區的經緯度位置，便能知道這個消費者晚上住在哪個小區。如果有每個小區房價，就能去猜測這個消費者的收入水平。如果有全國辦公樓經緯度位置，就能知道這個消費者的大致工作。如果有全國高爾夫球場經緯度，就能知道這個消費者是否有打高爾夫的習慣….

以上這些對於原始數據結構化的「詞典」，就被稱為「知識圖譜」（在後文會有單獨有一章節進行解釋），有趣的是，同樣的行為數據，在連接不同知識圖譜後，能獲得不同的洞察結果和客戶標簽體系。知識圖譜是廣告主解讀大數據、建立自己洞察體系的那把「鑰匙」。

03數據中台的技術革新3：數據輸出的實時要求

傳統從大型資料庫中提取數據需要花費數分鐘甚至數小時，而今很多大數據的應用場景都是毫秒級別，例如某廣告主想讓不同消費者瀏覽自己主頁時，看到不同的內容（千人千面），從技術上便需要實現毫秒級別完成以下動作：

消費者ID識別->消費者畫像提取->展示圖片匹配->圖片載入

當以上閉環無法在毫秒級完成，無法實現實時輸出，便會出現消費者數秒內打不開企業官網，從而失去耐心直接選擇關閉的情況。

03什麼是「知識圖譜」

在數據中台搭建過程中，最難的不是IT層面的數據管理，而是將海量大數據化繁為簡，變成業務側能看懂的標簽的「分析」過程。

上文提及了分析的兩種方式，現在絕大部分廣告主大走的都是第一條路線：對於數據收集主要集中在消費者ID，再基於這些ID到外部匹配可用標簽。

這種模式的好處是能快速落地，缺點是外部標簽成本高昂，而且由於外部供應商缺少行業理解，標簽缺乏精準度。從中長期來看，廣告主在使用外部標簽遇到瓶頸後，必定會轉向建立自身標簽體系的第二條路線。

和傳統基於統計學的分析不同，基於大數據的分析的第一步並不是「演算法」，而是藉助「知識圖譜」對於底層數據的進行結構化處理，下麵是一個例子：

某廣告主收集到了消費者的三條行為數據：

● 訪問了某URL，並停留了120秒（網站分析數據）

● 在微信某小程式中，點擊了某個對話框（小程式監測）

● 出現在某線下銷售門店中（智能探針數據）

通過「知識圖譜」，發現第一條數據的URL代表的是產品A的介紹；第二條數據，這個小程式的對話框是產品A的詢價；第三條數據，是專門銷售產品A的線下門店，從定性角度已經可以初步判斷這個消費者對於產品A的高度興趣，但是有這樣行為的消費者可能成千上萬，在頁面停留120秒，和線上下門店停留15分鐘，這樣的數據如何定量呢？

通過「演算法」，可以發現有這樣行為的消費者：在未來30天內進行購買A產品的可能性是70%。「A產品」+「70%」是業務側最終能讀懂的，並且橫向比較應用的標簽。

在今天的數字技術收集的大數據中，常規營銷用的「知識圖譜」包括

● 網頁URL的知識圖譜

● APP行為的知識圖譜

● 第三方平臺（例如微信公眾號）行為的知識圖譜

● 地理位置的知識圖譜

● 廣告主自身產品標簽化的知識圖譜

不同顆粒度的「知識圖譜」在解讀同一條行為數據時候，得到的洞察深度也會不同，例如：

● 這個消費者正在看我的競品

● 這個消費者正在看我的競品的產品A

● 這個消費者正在看我的競品的產品A，最新的促銷

● 這個消費者正在看我的競品的產品A，促銷價格比我的對標產品低15%

……

「知識圖譜」的建立過程，往往是基於消費者全量數據，用窮舉法去作分析得到的，考慮到數據的多樣性，高精度的「知識圖譜」必定是藉助AI實現的，例如掌握了消費者訪問的海量URL數據，需要運用爬蟲工具去獲取所有URL對應頁面上的文字，並通過「語義識別」技術，給每個URL貼上對應標簽。

04數據中台的系統架構

下圖是數據中台的大致模型，從IT層面有以下幾個模塊：

01多數據源對接

從各種數據源提取數據，放入數據中台，數據類型包括

● 第一方數據：廣告主自身系統上產生的數據，例如CRM、售後服務、會員系統等；

● 第二方數據：廣告主在外部系統上產生的數據，由外部系統通過API提供，例如電商數據、廣告監測數據、微信公眾號數據等；

● 第三方數據：廣告主直接購買的外部數據資源。需要強調的是，和業外人想象的不同，第三方數據交易並非一手交錢一手交數據。目前數據生態圈的法律合規要求，第三方數據交易不允許廣告主直接採購消費者的ID，數據服務商智能基於廣告主提供的消費者ID提供數據服務。

02數據治理

在獲取不同數據後，對數據的治理包括三個任務

● 數據標準化：例如不同數據源對於消費者性別的描述有「男-女」，「先生-女士」等多種寫法，在做數據整合的時候，需要統一不同數據源對於相同含義的描述值；

● ID打通：上文也描述過，不同數據源對於消費者的識別是基於不同ID的，數據源的拼合需要ID打通。對於大部分廣告主來說，無法擁有像BAT那樣的數據量，BAT每天能收集十億級別ID發生的千億級別的行為數據，他們的確能做到依靠自身數據打通不同數據源。大部分廣告主在沒有如此大量數據和消費者活躍度的情況下，ID打通需要依賴外部數據源；

● 異常數據甄別：和ID打通一樣，異常數據的甄別在廣告主自身數據不夠龐大的情況下，同樣依賴外部數據。例如某個ID每天會點擊2次某廣告主的廣告，這個行為相對正常。但是如果放到全行業，這個ID也許每天會點擊1萬次各個廣告主的廣告，這就很明顯是流量作弊了。

03數據存儲和運算

在數據完成治理後，統一放入資料庫進行管理和運算。由於數據量過大，在單一伺服器上無法完成存儲和運算，就涉及到大數據的分散式運算，雲計算等複雜IT層面的管理。

按照數據存儲和計算的地方，可分為營銷雲（數據存在第三方的雲平臺上），自有雲（廣告主自己的IT環境內），混合模式（非敏感數據存放在第三方雲，敏感數據在自有平臺），以上不同的方式有著不同的成本，數據安全和合規要求等。

04許可權管理

數據中台的目標是支撐市場部甚至全公司不同業務場景，這也意味著從公司高層到底層外包員工都需要從數據中台提取數據，為了防止數據泄露等問題的發生，需要對不同用戶、不同場景進行許可權分級管理。例如負責接聽電話的客服人員，在客服系統中就不可以看到消費者的全名和實際手機號。

05數據分析

上文也有描述，在使用「營銷大數據」前，需要對數據通過分析，生成業務側用戶能夠理解的標簽，分析的過程包括非實時的傳統數據挖掘，依靠AI人工智慧的實時分析等。在分析過程中，廣告主很難在短期內積累自身的知識圖譜和高質量的標簽，需要依賴外部的數據能力。

06數據可視化

雖然數據中台是由技術背景的團隊進行運維，但是實際使用的是對數據缺乏感知的業務側人員。對比成億條原始數據，業務側也許只需要一個餅圖就能得到商業結論，因此可視化是真正讓業務側使用數據中台的基本工具。

07數據輸出

數據中台的產出，除了數據可視化展現的洞察外，還會對接不同的業務系統，通過數據來驅動業務場景，例如程式化廣告、新零售、動態定價等諸多業務場景需要毫秒級的查詢和輸出，也是IT層面需要解決的技術問題。

05數據中台的數據源

今天廣告主常規的數據源包括四大類：

● 基於設備ID、cookie的網站分析和廣告監測數據：描述的是消費者對於互聯網廣告，以及廣告主官網、APP等自由平臺的瀏覽和點擊行為；

● 基於手機號的PII數據：包括會員系統、CRM數據等，描述的是消費者的會員信息，歷史採購記錄等；

● 基於Mac#和人臉識別的線下數據：通過智能探針技術、攝像頭+人像識別技術，收集到的消費者線下行為數據；

● 基於外部平臺ID的平臺數據：包括微信的Open ID、各個大數據方的自建Super ID等。

這些數據的打通雖然有很多技術途徑，例如在微信中建立SCRM會員體系，消費者在微信公眾號中進行手機的實名認證，就能打通手機號和微信Open ID；再例如一個消費者在手機和電腦上用同一個用戶名登錄了某個APP，就知道手機的設備ID和電腦瀏覽器的Cookie是同一個人等等。

考慮到一個消費者可能有多個終端、多個手機號，會經常換手機（設備ID變化），會借用別人終端登錄APP，還有網吧共用電腦等複雜形式的存在，當廣告主自身數據量不夠大的時候，很難依靠以上這些技術手段達到很好的數據打通效果。

06數據中台的三種形式Data Lake，CDP，DMP

今天營銷數據中台在技術上分為三種：

● Data Lake（數據湖）：技術難度最重的一種，定位是企業業務層面的數據大集市，會整合全公司各種數據源，支撐的不只是營銷場景，還包括企業個性化的業務場景，往往由企業的最高層直接領導，目標是幫助企業進行數字化轉型。由於在數據對接和數據處理層面需要處理大量定製化數據源，因此構建過程往往以年為時間單位；

● CDP（Customer Data Platform）：技術難度稍低的數據中台，定位是營銷層面的數據大集市，目標是支撐各種利用廣告主自有數據的營銷場景。因為CDP通常只對接標準化數據源（例如兩個廣告主用的是同一款標準化CRM，他們的底層數據結構都是一樣的），數據治理和數據管理相對容易，因此實施周期以月為單位；

● DMP（Data Management Platform）：定位是支撐以程式化廣告為主的實時營銷場景，和Data Lake，CDP的最大不同是毫秒級數據輸出。因為DMP主要用到的是廣告監測數據、網站分析數據和第三方大數據，數據格式相對固定，因此實施難度最低。

因為在程式化廣告的運營過程中，DMP的數據會暴露在公網上，被外部供應商和媒體調用，因此只能存放廣告投放使用的匿名數據（ID和標簽），不能存放其他敏感信息（姓名、手機號、地址、歷史購買等），投放的標簽也需要脫敏（例如某ID的標簽是A，實際代表著過去3周沒有購買的高消費客戶，但這個定義只有廣告主內部數據分析團隊知道）。

在數據存儲和運算中，DMP可以構建在廣告主自己的IT環境里（稱為第一方DMP），也可以放在第三方營銷雲上（稱為SAAS DMP，或者第三方DMP）。因為第三方DMP會預先對接媒體，自帶演算法、標簽和數據治理模塊，能把DMP的實施時間縮小到幾周，可以大大降低實施成本。

而由於Data Lake 和CDP上存儲了廣告主的敏感數據和商業機密（例如歷史採購信息），因此只能構建在廣告主自己的IT環境下，從技術角度而言更加複雜，成本也更高。

通過下表簡單列舉三種技術、四種形式的主要差別（第一方和第三方DMP分開敘述）