本文根據神策數據聯合創始人& CTO 曹犟在神策 2018 數據驅動大會現場，發表題為《數據驅動從方法到實踐》演講整理所得。
溫馨提示：神策數據
主要內容包括：
- 數據驅動價值：驅動決策、驅動產品智能
- 數據驅動閉環：數據採集—數據建模—數據分析—數據反饋
- 數據驅動各環節方法與實踐
一、數據驅動價值：驅動決策、驅動產品智能
數據驅動能做什麼？我們認為主要包含驅動決策、驅動產品智能兩方面的價值。
圖 1 數據驅動價值
驅動決策包括運營監控、產品迭代、營銷分析、商業決策。其中涉及的每一個場景在今年數據驅動大會都會有專門的講師來介紹。
驅動產品智能，現在基本上已成為所有的電商類、資訊類產品的標配，如“產品推薦”、“猜你喜歡”等，企業要麼組建團隊實現智能化的應用場景，要麼應用外部工具來解決問題，因為在流量紅利逐漸消失的今天，千篇一律的內容會讓你的“留存”數字非常難看。
我們曾為某一家很知名資訊類企業做 Feed 流的改版，神策來提供具體的推薦策略。通常，個性化推薦的評價指標是 CTR——展現了一千種內容，有多少人點擊？在 2018 年，我們認為再評價一個算法的好壞，用 CTR 非常不合適。神策從關注指標 CTR 轉為衡量“命中了策略的人”跟“命中熱門隨機內容”的兩大用戶群體，觀察他們在平均訪問深度、7 日留存、停留時長等更深層指標上的差異。
二、數據驅動閉環
數據採集——數據建模——數據分析——數據反饋，這是一個完整的數據驅動閉環。我們在很多場合提到此，這裡不再贅述。
圖 2 數據驅動閉環
有很多企業來找我做關於數據採集方面的分享，我用這張圖描述了典型的數據分析平臺，一個為數據驅動而構建的數據分析平臺，各位可以參考。
三、數據採集：一切數據應用的根基
（一）採集內容：數據類型、數據所有者、數據來源
數據採集是一切應用的根基，“大、全、細、時”由桑文鋒提出，是神策一貫堅持數據採集理念，具體到採集內容上，包括數據類型、數據所有者、數據來源。數據類型包括用戶行為數據、用戶數據、業務運行數據、內容數據。
用戶行為數據，可以描述用戶在什麼時候、什麼地點、以什麼方式、用什麼樣的手機、通過哪種瀏覽器做了一件什麼事情；
用戶數據，描述用戶本身的屬性，比如某順風車給乘客打上各種各樣的標籤，這些標籤肯定會用於後續產品迭代；
業務運行數據，在線下業務比較重的場景同樣很多；
內容數據，包含用戶瀏覽的具體內容，也包括與用戶發生交互的對象。
從數據所有者上來講，神策採集第一方數據——也就是“我們自己的產品，我們自己的用戶，自己用戶在自己產品上發生了什麼。”這是第一方數據。第一方數據採集在完全可控環節下發生，不僅比較便捷。在隱私策略方面，我們完全符合最嚴格的 GDPR 標準。目前神策採集第一方數據為主；而第三方數據，市面上一些免費的 SaaS 工具可以做採集和統計，並做一些處理、脫敏，用這些數據作為第三方數據，提供給客戶。這是有悖神策價值觀的，我們絕不涉及。
從數據來源上來講，新零售的火熱，線下數據採集還是非常火的。不管是攝像頭、藍牙探針等，是線下場景很好的補充。不過從目前實踐經驗來看，攝像頭、ID 識別的準確度非常低，基本不太可用。對這一部分，神策保持持續關注，一些神策客戶會將通過二維碼、店員主動拿 Pad 做展現等方式，將用戶從線下行為引到線上，從而保證用戶數據的可採集、可衡量。
（二）根據需求採取合適的採集方案
神策一貫的觀點，是數據採集沒有萬能靈藥，要根據需求選擇合適的採集方案，這一點我在不同場合講很多次，這裡不再展開。
圖 4 根據需求採取合適的採集方案
（三）數據採集的接入
這是宏觀上對於不同內容，不同來源數據的採集統一架構。
圖 5 一個典型的用戶行為相關數據採集
這是一種典型的用戶行為採集方案。客戶端採集輕交互的內容；服務器日誌採集 Nginx、UI、Server 瀏覽、檢索、理財產品等內容。而對於一些業務操作，例如客戶跟客服之間的交互，或者內部的客戶運營，主要是在業務採集上搞定的。
（四）客戶端採集
我來介紹下目前被提及最多的客戶端採集。客戶端是直接跟用戶發生交互關係的一端，可以是 APP、小程序、網頁、H5、公眾號等，客戶端採集數據操作，包括點擊按鈕、瀏覽頁面、下拉框選擇、提交表單、上傳照片、切換導航條等。這些操作是輕交互的，它的採集在通常意義上被稱為埋點，我個人覺得埋點更多指客戶端採集。
1、客戶端採集的基本原理
客戶端採集的基本原理有三點：
第一，提供 SDK 與使用者的應用“編譯”到一起。
客戶端採集有各種各樣的模式，但本質上都是提供 SDK 和使用者的應用編譯在一起。拋開埋點方式，完成這樣的事情，很多容易被忽視的，基礎屬性要覆蓋我們能想到的所有內容，包括簡單的用戶行為相關、操作系統版本、物理分辨率等，還有很多客戶通過 SDK 提供部分風控數據的採集。比如說 iphone 手機有沒有越獄，瀏覽的時候是橫屏還是豎屏，以及電量等等。（之所以要用 SDK 採集當前的電量，是因為如果用戶用模擬器訪問，那麼它的電量變化跟真正的手機有非常大的不同。）所以基礎屬性雖然看起來比較簡單，但是很多時候可以發揮很大的作用。
第二，SDK 完成匿名 ID 生成、基礎屬性採集、數據打包壓縮加密、本地緩存、網絡傳輸等工作。
數據打包和加密，不僅可以在本地打包，還可以在必要的時候刪掉，神策現在服務很多銀行證券客戶，對加密要求的非常高，比如給某一個字段要用什麼加密等，這些都是 SDK 要完成的。本地緩存在 IOS 與安卓中特別重要，因為為避免影響用戶體驗，當發生一次點擊，對應的數據不會立刻傳到後端，所以都是緩存到本地等待最佳網絡時機。本地緩存、網絡緩存這些都是SDK 來做的。
第三，一般使用 HTTP(S) 協議通過公網傳輸數據。
有人問，所謂的代碼埋點、全埋點、可視化埋點有什麼不一樣？我們可以這樣理解：SDK 完成基礎數據的採集、數據儲存打包、傳輸等，同時向上埋點應用層提供 API，所謂的代碼埋點就是直接利用 API，告訴採集了什麼數據。全埋點則是在用戶完成某個操作的時候，自動的調用 SDK。所以說 SDK 完成一些基礎工作，代碼埋點開發者直接調用 API；而全埋點開發者不用直接調用，可以比較自動的完成。
說到這裡會打一個廣告，我們會馬上出版一本書，專門講安卓 8 種全埋點，到時候有興趣的話可以看看。
2、ID-Mapping 構建多設備用戶管理體系
多設備下的用戶關聯是今年新的進展，新的趨勢。ID-Mapping 解決的是不同用戶多設備的使用情況
圖 6 構建多設備用戶管理體系
大家可以看下如圖的例子。我們做了一些工作，後臺架構有很大改進，可以實現將第二個設備，跟同一個用戶綁定，只要用戶登錄，神策就可以把不同情況下登錄的數據完全打通，這是非常典型的 ID-Mapping 的場景。
同樣非常典型的場景是用戶行為多端關聯機制。用戶產品本身可以多端使用，可以在網頁上使用，例如說發了營銷 H5，用戶在微信內置瀏覽器 H5 完成註冊，跳到 Appstore 完成激活。如果不能將營銷 H5 的用戶行為，與登錄激活之前的行為貫通，那麼也沒有辦法詳細分析 H5 的營銷效果。
再如，小程序突然火起來了，客戶有需求，為此我們專門做了小程序採集，包括預置採集的事件，以及小程序相關的屬性，同時一樣帶動了代碼與自動化採集兩種方式，小程序可以充分得到微信裡面的社交信息，對小程序分享傳播的屬性採集是非常重要的。
圖 7 小程序的採集
小程序最複雜的事情，它有不同的匿名 ID 或者設備 ID。一個人在設備上，又使用小程序，又使用一個 APP，又換了一個小程序，但是兩個小程序之間登錄帳號打通，最終我們實現可以把兩個 LoginID 與 OpenID 設備貫通起來。
（五）服務器日誌採集
圖 8 服務器日誌採集
我現在畫了很簡單服務器日誌採集架構圖，看似技術上沒什麼問題。從實際經驗上來說，想高質量搭建日誌採集非常難，設置日誌用哪些內容，一次性工作很難。更難的還體現在產品迭代上，比如產品兩週發一個版本，程序員會說產品功能都測不完，沒法搞日誌。
要搭建一個高質量的日誌採集，要貫穿在整個開發流程，從最早期一直到運維上線，到覆盤整個迭代項的時候，每一步都要有意識。這也是為什麼很多SaaS 產品都沒有采集日誌的能力。
圖 9 用戶行為數據應用案例
這是我們在中國銀聯典型的案例，包括設備指紋採集、加密傳輸等，當然這個圖畫出來體現對用戶行為數據不同的應用，除了做日常行為之外，還有一些其他的應用。最後是業務數據的採集，包括 CRM 系統等。
四、數據建模
數據建模最重要的是數據模型的選擇，以及對應的儲存。數據模型選擇為什麼重要？因為數據模型抽象好了，後面的分析模型可以做的更好。如果數據模型抽象的太複雜，整體過程非常複雜。
神策現在的數據模型是 Item 實體、Event 事件、User 用戶，我們不會把模型搞得太複雜，現在模型下面，數據採集到建模所要做的工作是比較少的，基本可以通用化、產品化。神策已經有了標準的數據模型，同時通過不同的採集方案採到了很多數據，所要做的工作主要是把採集到的數據映射，這裡面非常多的工作不再具體展開。
不同的數據模型選不同的儲存方案，儲存方案的選擇主要根據數據本身的特點，例如是否可追加、可修改、訪問是以什麼樣的訪問為主，是否會需要刪除等。
五、數據分析
有了標準模型，有非常合適的儲存結構，後面是對數據怎麼分析。
（一）數據統計與分析的兩種方法論
數據統計與分析有兩種方法論，通常情況下，是圖片左邊方法論，PM 給 RD 提，老闆要看這些報表，給 RD 提要求，RD 寫一些東西併發郵件出來，改程序後又有新的需求。老闆可能問你 PV 為什麼是這麼多？你可能要把整個計算過程完整講一遍……在這種情況下，RD 為了不想太頻繁操作和改變，總是會給 PM 設置各種限制。
圖 10 數據統計與分析的兩種方法論
右邊的方法論，抽象的模型覆蓋指標體系以及大部分分析需求，通過友好的交互讓需要數據的人自主獲取數據。這種方法論是神策產品提供的，我們不需要問你看什麼指標，因為你看的指標可能在整個行業都有通用性，我們會把需求抽象下來，接下來就是模型抽象。
如此，你的工作就變成你自己用分析模型，通過拖拖拽拽，把你要的條件選出來，就能完成一次分析。
這兩種方法論區別是，是否讓需要數據的人直接使用數據，造成的工作效率相差非常大，這就是為什麼現在神策產品能夠賣出去，並不是我們造了一個這樣的需求，而是真正有這樣的需求。接下來這個圖是神策實現的自助式分析。
圖 11 自助式數據分析
（二）針對不同角色的數據分析：決策者、營銷、產品、運營
通過不同角色分析四個不同的場景。
1、決策者
老闆關心的是第一關鍵指標是什麼。第一關鍵指標該如何選擇？不同階段關鍵指標不相同，每個發展階段都有最關注的數據，集中注意力，提升第一指標。
有了第一關鍵指標，如何構建指標體系？有了第一關鍵指標，我們要繪製整個用戶旅程。
以電商產品為例，我們關心總營收額，如何得到？先繪製用戶旅程：用戶首先要訪問網站，之後要註冊賬號，實現首購之後會重複性購買，只有這樣的用戶旅程最終會帶來總銷售額的增長。接下來就要根據用戶旅程來組建增長模型。
圖 12 繪製用戶旅程
拆解的好處，不同團隊提不同的項目，你可以調整項目的優先
圖 13 組裝增長模型
2、營銷
市場營銷希望實現流量拉新，渠道投放評估。市場營銷團隊，他們最關心兩個事，一是老闆給了多少預算，二是怎樣花出去最有用。如何衡量？像電視廣告、樓宇廣告，一定程度上是不可追蹤的，但是像抖音、頭條都是可以追蹤。同一個用戶在媒體上點廣告，跟進入到產品之後，只要把這個行為打通起來，整個投放效果就是可追蹤的。現在我們可支持二三十種大大小小的渠道。
我們把用戶在點擊廣告前後的行為串通起來，剩下的工作就是分析，比如我們在頭條花了10000 塊錢買了 1000 個點擊，其中 50 個用戶使用產品，我們可以設置從哪些角度來衡量這些人的效果，來衡量用戶的轉化率、留存、復購等；也可以對比不同的渠道，對比不同渠道下不同的投放關鍵詞帶來效果等，來對比與衡量用戶真正的價值。
圖 14 數據驅動市場營銷案例
圖 15 數據驅動市場營銷案例
這個是很典型的數據驅動市場營銷的例子，某家理財產品投放廣告，剛開始假設關注 P2P 理財產品都是資質相對較好的白領，因此在核心商圈的寫字樓電梯間投放廣告，但是經過轉化分析後，發現進件轉化率很低，因此對借款人畫像分析，確定目標人群特徵：24-30 歲，工作時間短，收入一般，身處非核心高檔區域。得到這種結論後，將投放渠道放到了抖音和快手這類短視頻平臺，轉化率得到明顯提升。
3、產品
圖 16 數據驅動產品優化
這個是我之前一個產品同事發給我的，他說這些是產品關心的指標。因為我是工程師出身，我根本不懂這些東西，但是我知道怎麼改進產品：我們把這些指標全部算出來，進行監控，一旦發現某一個指標異常，立刻分析原因，並解決這些原因；如果指標沒有異常，可以和別人家進行對比，你的轉化率是多少，我的轉化率是多少，看我們有多少提升空間，來提升指標。所以，整個邏輯很簡單，先設置關心的問題，實際算出來，並關注是否異常，找到異常原因，分析解決異常，看數據有沒有真正得到上升。
場景 1:內容產品的“Aha Moment”
通過用戶行為將用戶群體劃分成四類：路人、打醬油、參與（點贊、轉發）、深度參與，如何提升這四類人的用戶留存？很簡單，首先我觀察四類人的留存率，很明顯，行為深度越深，用戶留存肯定越高。那該怎麼操作？擴大“參與行為”使用者面積，門檻太高，落地性較差；擴大“圍觀行為”使用者面積？這個方法更可行，在產品信息流頁露出“熱評”，可以提升留存，來驗證新增“熱評”之後效果如何。
場景 2：電商，收藏按鈕位置改版
某電商的首頁存在兩個“收藏”，一開始設置有點問題，一個點擊率極高，一個點擊率極低。顯而易見，浪費了非常重要的位置。後來將點擊率低的收藏按鈕位置換成了“服務”的按鈕，經過驗證，點擊進入量沒有明顯下降，同時“服務”點擊量提升。
經過 SA 中的數據對比發現，BEST 分類的點擊流量並沒有預想中高，甚至跟 MEN 分類的訪問量差不多。猜想可能用戶不習慣往左滑動頁面，習慣往右滑動界面。同時，該電商還進行了首頁 BEST 分類按鈕位置調整，將 BEST 類目放到 FUN 類目右邊。效果：經過調整後，50% 以上的首頁用戶會進入 BEST 類目，比原來調整之前相對提高了 78% 。
場景 3：小程序的產品迭代案例
這是一個純女性短視頻社區案例，他們一直致力將數據分析融入到運營乃至產品迭代的最細節處。這是他們的工作方式。
圖 17 把數據分析融入到運營至產品迭代的最細節處
該企業的小程序更新發版很快。用戶分享之後裂變，有一個完整的看板讓大家來評估的自己的影響。日裂變作為關鍵指標，某版本上線後發現裂變指數（uv 數 x 內部調整因子）迅速下跌。
圖 18 某版本上線後發現裂變指數迅速下跌
通過回溯過去 7 日的分析看到，“分享”按鈕的點擊數據出現連續下滑，“下載”按鈕的數據在出現大幅度提升。
圖 19 回溯 7 日數據快速篩查可能原因
通過用戶實際回訪，確認“保存按鈕”其實弱化了“分享意願”，造成分享減少。次日晨完成新版本上線後，指標變得正常。
4、運營
除了數據驅動產品迭代，下一個案例是用數據驅動運營，數據驅動運營同樣是發現問題，分析原因，來驗證效果。
圖 20 基於數據的驅動閉環，驅動業務決策
六、反饋
最後給大家介紹幾個重要閉環。
（一）用戶運營的閉環反饋
神策推出了自動化運營的新產品，我們發現大家對產品運營自動化越來越高。神策自動化運營是基於分群標籤的全流程運營閉環分析系統，通過用戶精準分群、靈活創建並管理營銷活動計劃，比如知道用戶數據、業務數據，最終精準的刻畫了用戶畫像。基於用戶畫像採用不同的觸達方式，比如優惠券等。做完之後，我可以分析衡量觸達效果怎麼樣，從而評價營銷效果。有了第一次營銷效果之後，可以針對性的改進，做第二次營銷效果。真正形成自動化、精細化的運營閉環。
圖 21 用戶運營閉環反饋
（二）產品智能閉環反饋
這是個性化推薦的全流程，包括採集各種不同的數據，構建相應的興趣模型，特定的場景推薦下做推薦，不同緯度、不同指標做測量。
圖 22 產品智能閉環反饋
東方明珠是神策數據的客戶，以百視通 IPTV 某駐地為例，日活數百萬用戶通過 IPTV 機頂盒付費觀看授權內容，部分精品內容需額外充值觀看;在接入神策推薦之前，主要依賴人工推薦，以熱門、付費和內容相關性為主要推薦參考。為提升用戶的觀影體驗、提高用戶留存以及充值付費營收，東方明珠利用神策推薦解決方案，完成採集點擊日誌、展示日誌、播放日誌等所需用戶行為數據，基於行為數據構建深度學習召回算法策略，採用 GBDT+LR 排序模型訓練數據。推薦算法上線兩週後，神策推薦的效果，對比人工推薦，僅 CTR 一個指標即提升了 6 倍，對推薦內容的人均瀏覽次數提升了 1.9 倍。這就是我講的內容，基本圍繞數據驅動閉環。希望對你有所幫助！
溫馨提示：完整版PPT可以在【神策數據】公眾號，回覆關鍵詞【數據驅動從方法到實踐】下載
更多最新數據驅動乾貨、案例和活動，可從【神策數據】公眾號瞭解~
閱讀更多 神策數據 的文章
