以數據為核心的CRM進化產品：帶你了解CDP(客戶數據平台)開發過程與難點
最近客戶數據平台(CDP)受到了不少關注，但看了大多內容主要都是說概念，這篇文章會更關注實際產品、開發過程、部署難點。
邀請你至Blog閱讀全文：帶你了解CDP(客戶數據平台)開發過程與難點：以數據為核心的CR
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
文章最後有其他參考資料，有興趣的朋友可以延伸閱讀。參考資料中，GrowingIO發布的CDP白皮書是我看到說的最完整、最徹底的，約100頁(目錄如下圖)，如果對CDP有想更深入了解的朋友，十分推薦至GrowingIO官網輸入手機號碼下載。如果沒有大陸手機號碼的朋友，到<Rock Data>臉書粉絲頁，按讚追蹤，並發送訊息"cdp"獲取。
CRM的本質是什麼？
損失一個老客戶，恐怕要開發10個新客戶來彌補；但服務好一個老客戶，卻可以帶來10個新客戶
在說CDP前，我想先探討一下CRM本質。
我們在線下門市消費時，可能都會遇到收銀員問你要不要成為會員，錄入你的姓名、電話後給你一張會員卡，這張卡可以在消費時累積積分，積分累積到一定程度後，會有某種程度的優惠，例如屈臣氏會員可以用比較低的價格換購、便利店用積分換公仔。
在2B的產業，客戶對公司業績影響相對較大，因此CRM紀錄通常也會更詳細，例如產品需求、報價、合約、收款、跟進紀錄、服務紀錄等。這樣不論是該業務員離職、或是業務與客戶久沒聯絡，企業也可以很快的回顧客戶的歷史信息，提供更好的服務。
線上也是同理，當我們進到一個網站時，通常會要我們進行填寫資本資料註冊成為會員，我們可能在生日時，收到平台方寄來的生日郵件、或是生日優惠券。
不論是積分折抵、優惠券，乃至各種行銷活動，都是在強化與客戶之間的聯繫。因此，瞭解客戶、強化與客戶之間的關係，就是CRM的本質。
CRM為什麼不足夠了解用戶？CDP的產生
由於用戶觸點的破碎，系統之間的數據沒有打通，因此用戶數據可能是片面的、模糊的
隨著網發展，傳統企業跟用戶的連接從從線下商店、門市人員，客服人員，開始多了了Email、PC官網的接觸點；再由於4G發展，APP跟各種社群媒體，企業與用戶之間的聯繫變得越來越複雜，例如官方APP、臉書粉絲頁、IG粉絲頁、Line粉絲頁。
可以說，客戶的行為都在網上了，但反而更加破碎。
這對”了解客戶”會造成什麼問題呢？
比如以電信業為例，假設某低合約金額的用戶，最近一直在官網查看iphone等機型跟高資費方案，那麼他應該被判斷為高潛力升級用戶；但門市人員只能看到他當前資費及繳費記錄，而看不到在其他渠道的行為數據，故很容易會推薦他差不多資費的續約方案。
了解客戶是誰。這似乎很簡單，但客戶與業務互動渠道的激增，使這個簡單的目標變得極其複雜。CDP要解決的就是這個問題。
邀請你至Blog閱讀全文：帶你了解CDP(客戶數據平台)開發過程與難點：以數據為核心的CR
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
1. Hello All：主站遷移至👉https://andyrockdata.com/ ，請改至『ROCK DATA』Blog 閱讀新文章完整內容，如果喜歡我的文章，可以訂閱我的電子報(Medium站仍將張貼新文章訊息)2.立即追蹤👉ROCK DATA臉書粉絲頁跟ROCK DATA IG(@andyrockdata)3.【入門數據分析，掌握HiveSQL取數能力】在hahow上架啦，購買連結👉 http://hahow.in/cr/andyrockhive4. 半佛系鼓掌：原來只要滑鼠一直按著不放就可以一直鼓掌了。那請你按久一點：）有任何想法或感興趣的地方歡迎留言/討論，或者私訊我！5. 往期的數據相關文章可以參考以下link
了解客戶-大數據平台建設基本能力
了解客戶，第一步要做的即是將屬於同一人的多個標示連接再一起，進行唯一id識別，也就是ID Mapping。開發過程中可能涉及權重歸一、衰減、收斂等算法模型，比較複雜，這裡不做展開，有興趣的朋友可自行Google
因此只要涉及到“客戶”，都是我們要採集的數據。除了CRM的數據外，還有客服系統、ERP系統等的業務數據，官網/APP的行為數據(操作日誌/埋點數據)，社交媒體、廣告投放平台等第三方外部數據，以及不是客戶數據，但會和分析極度相關。比如庫存和產品價格。
要對多個數據源、多種Database的採集，我們可能需要部署Sqoop、Flume、Kafka等大數據採集工具，將數據抽取到Hive數據倉庫中。
數據要能定時更新，部署Ooize/Azkaban實現調度功能
接著，為了將這些數據進行有序、有結構的分類，以便在性能、成本、效率和質量之間取的最佳平衡，我們要進行數據倉庫建設。
最後別忘了，CPU、內存、磁盤等服務器硬體資源，是系統能否穩定的重要保障。
以上就是CDP基礎能力的搭建，包含服務器、hadoop集群搭建、數據的計算、調度能力、數據倉庫建設。總的來說，就是完成對數據的整合、處理和計算能力。
了解客戶-特徵標籤化構建用戶畫像
用戶數據沈澱至數據倉庫後，我們可以開始構建用戶畫像。
所謂的用戶畫像，就是將用戶特徵以一個一個標籤來描述，例如”男性/女性”、’’是否曾經有購買”、”是否有投訴過””…等等。
標籤開發就是這階段的目標，標籤可以非常多，我們熟知的RFM model，也只是用戶的其中一個標籤。關於用戶畫像與標籤，可以參閱我另一篇文章<用戶畫像很重要，那你知道是怎麼畫出來的嗎？>
已經透過ID mapping識別了唯一用戶，也對用戶打上多樣的標籤，那我們就可以進行各種維度的聚合、拆分等方式來分析用戶群。
可以在CDP平台上加入”客戶分析”看板，對指標進行不同維度的分析展示，這種方式走的是前後端聯調開發的模式；也可以考慮將CDP平台的數據再開放到其他產品，例如接入BI工具，供業務方自由搭建看板。
強化與客戶之間的關係-人群圈選與消息推送
強化與客戶之間的關係，目前最主流的應用就是精準行銷，也就是對不同客戶傳遞不同的訊息。例如電信公司想對對高消費男性用戶群，發送蘋果高端手機、對低消費女性的用戶群，發送小米中價位手機
“高消費男性”用戶群，可能由3個標籤組成：1.年齡=25–35、2.職業=IT、3.平均帳單金額=1千以上。
給業務方使用的流程為，業務人員自由選擇想要的多個標籤，透過”且”、”或”等邏輯規則，篩選出符合條件的用戶(即創建人群)，並對這群人命名為”對高消費男性”。
圈人之後，我們就可以針對不同人群，推送不同消息。
消息推送一般都會有預算限制、或是人數限制等，因此圈出人群後，最好能夠實時計算人群數量，選用Redis儲存或許比Mysql好(這邊要跟後端工程師討論)。
消息推送功能大致包含：
- 消息新增
- 消息編輯
- 消息發送的排期
- 選擇消息發送的渠道…等
這邊的設計以功能面為主，偏產品經理的範疇，就不再展開了。
鏈路簡化如下圖：
最後
越多越複雜的事務，越需要一套框架來管控，因此開發前要設計好標籤體系，包含標籤主題、標籤編碼、標籤名、標籤說明等。
而這麼多數據也會存在質量問題，如何做好質量監控？如何做標籤的上下線？
這整套的管理可以開發”標籤資產管理”，做系統化的管控。
另外，標籤的應用不止精準行銷，更多的場景還有賴我們挖掘。
純功能型產品需要有產品經理做出產品定位、產品功能，配合前後端工程師開發。但CDP這個產品，又多了數據的層面，難點至少有以下5點：
- 大數據架構設計、大數據環境部署
- 服務器等硬體資源投入
- 數據人才的缺乏、管理層對數據認知的缺乏
- 集團型企業存在多部門、子公司之間的利益，數據無法共享，產生的數據隔閡
- 開發環節多，導致項目管理難度大
參考資料
- <GrowingIO企业级CDP实操指南>白皮書
- 書籍：用戶畫像
- 神策數據-用戶畫像
- treasuredata官網
- 阿里/网易/美团/58用户画像中的ID体系建设
- OPPO 大数据平台运营研发实践分享
- CRM vs. CDP: What’s the difference between a CRM and a CDP?
- What’s the Difference Between a CRM and a CDP? And Why You Should Car
邀請你至Blog閱讀全文：帶你了解CDP(客戶數據平台)開發過程與難點：以數據為核心的CR
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
1. Hello All：主站遷移至👉https://andyrockdata.com/ ，請改至『ROCK DATA』Blog 閱讀新文章完整內容，如果喜歡我的文章，可以訂閱我的電子報(Medium站仍將張貼新文章訊息)2.立即追蹤👉ROCK DATA臉書粉絲頁跟ROCK DATA IG(@andyrockdata)3.【入門數據分析，掌握HiveSQL取數能力】在hahow上架啦，購買連結👉 http://hahow.in/cr/andyrockhive4. 半佛系鼓掌：原來只要滑鼠一直按著不放就可以一直鼓掌了。那請你按久一點：）有任何想法或感興趣的地方歡迎留言/討論，或者私訊我！5. 往期的數據相關文章可以參考以下link
- 數據分析系列1：談談數據分析的眾多Title
- 數據分析系列2：數據分析的一週工作日程
- 數據分析系列3：身為資料分析師，你該如何展現工作中的價值？
- 數據分析系列4：如何量化職場規劃？我這次的轉職規劃與Offer選擇
- 數據分析系列5：為什麼要關心資料來源？談談埋點數據的陷阱
- 數據分析系列6：精選幾個機器學習的學習資源
- 數據分析系列7：數位化決策轉型與企業文化的一些思考
- 數據分析系列8：中山大學經濟所職涯座談(ㄧ)：”了解自己”的重要＆我怎麼成為數據分析師
- 數據分析系列9：中山大學經濟所職涯座談(二)：想從事資料分析？你需要具備這8個能力
- 數據分析系列10：中山大學經濟所職涯座談(三) ：讓資料變商機 — 資料分析在我們生活中的應用
- 數據分析系列11：面試時，資料分析師該怎麼準備作品集？
- 數據分析系列12：2018年終工作總結(數據分析師)
- 數據分析系列13：數據化運營中玩過的分析項目：一個數據分析師的經驗總結
- 數據分析系列14：如何提升運營/產品的優化效率？或許數據指標體系的搭建可以幫到忙
- 數據分析系列15：用戶畫像很重要，那你知道是怎麼畫出來的嗎？
- 數據分析系列16：給剛入行的數據分析師：想產生價值，在試用期要做的三件事
- 數據分析系列17：2019 數據分析工作總結_關鍵詞：數倉構建、BI可視化看板、用戶畫像(標籤)與精準行銷
- 數據分析系列18：入門數據分析的第一個大門檻：SQL/Hive取數-聊聊自身學習SQL的經歷以及三個自學網站分享
- 數據分析系列19：身為數據分析師，我怎麼看hahow上”R語言和商業分析”這門課
- 數據分析系列20：直接用SQL來分析數據？怎麼沒用python/R？3個面向來考量分析工具的選擇
- 數據分析系列21：數據分析的”橫向”學習之路-珍藏的網上文章重新整理放上github
- 數據分析系列22：透過埋點，讓數據說話：埋點基本知識
- 數據分析系列23：以數據為核心的CRM進化產品：帶你了解CDP(客戶數據平台)開發過程與難點
- 數據分析系列24：SQL不難啊，為什麼不容易精通？自學與實務的4個落差
- 數據分析系列25：數據分析基本-相關分析與可視化(R語言)
- 數據分析系列26：刷完了Leetcode SQL Hard Level的28道題：歡迎領取參考答案
- 數據分析系列27：數據太髒了！3個步驟做好數據質量管理
- 數據分析系列28：跨部門溝通成本太高？數據人實現高效跨部門溝通的4個方式
- 數據分析系列29：數據分析師職場發展的另類出路
- 數據分析系列30：Databrick為何收購BI產品Redash？產品視角來看Redash的功能與價值
- 數據分析系列31：數據分析師要失業了？解讀<2022 Gartner BI魔力象限> BI產品趨勢
- 數據分析系列32：Google Data Catalog如何幫忙管理數據？ 產品介紹與體驗心得
- 數據分析系列33：復盤：數據產品從0到1的建設過程，我的9點感觸
- 數據分析系列34：Shopline-數據分析中心(Shoplytics)產品體驗
- 數據分析系列35：搞數據還是做產品？淺談『數據產品經理』
