PPT 下載 | 神策資料曹犟：資料驅動從方法到實踐
本文根據神策資料聯合創始人& CTO 曹犟在神策 2018 資料驅動大會現場，發表題為《資料驅動從方法到實踐》演講整理所得。
溫馨提示：完整版 PPT 可點選文末下載。
主要內容包括：
資料驅動價值：驅動決策、驅動產品智慧
資料驅動閉環：資料採集—資料建模—資料分析—資料反饋
資料驅動各環節方法與實踐
一、資料驅動價值：驅動決策、驅動產品智慧
資料驅動能做什麼？我們認為主要包含驅動決策、驅動產品智慧兩方面的價值。
圖 1 資料驅動價值
驅動決策包括運營監控、產品迭代、營銷分析、商業決策。其中涉及的每一個場景在今年資料驅動大會都會有專門的講師來介紹。
驅動產品智慧，現在基本上已成為所有的電商類、資訊類產品的標配，如“產品推薦”、“猜你喜歡”等，企業要麼組建團隊實現智慧化的應用場景，要麼應用外部工具來解決問題，因為在流量紅利逐漸消失的今天，千篇一律的內容會讓你的“留存”數字非常難看。
我們曾為某一家很知名資訊類企業做 Feed 流的改版，神策來提供具體的推薦策略。通常，個性化推薦的評價指標是 CTR——展現了一千種內容，有多少人點選？在 2018 年，我們認為再評價一個演算法的好壞，用 CTR 非常不合適。神策從關注指標 CTR 轉為衡量“命中了策略的人”跟“命中熱門隨機內容”的兩大使用者群體，觀察他們在平均訪問深度、7 日留存、停留時長等更深層指標上的差異。
二、資料驅動閉環
資料採集——資料建模——資料分析——資料反饋，這是一個完整的資料驅動閉環。我們在很多場合提到此，這裡不再贅述。
圖 2 資料驅動閉環
有很多企業來找我做關於資料採集方面的分享，我用這張圖描述了典型的資料分析平臺，一個為資料驅動而構建的資料分析平臺，各位可以參考。
圖 3 一圖全面展示資料分析平臺架構
三、資料採集：一切資料應用的根基
（一）採集內容：資料型別、資料所有者、資料來源
資料採集是一切應用的根基，“大、全、細、時”由桑文鋒提出（詳情可戳此檢視桑文鋒談大資料分析的四個重要環節），是神策一貫堅持資料採集理念，具體到採集內容上，包括資料型別、資料所有者、資料來源。
資料型別包括使用者行為資料、使用者資料、業務執行資料、內容資料。
使用者行為資料，可以描述使用者在什麼時候、什麼地點、以什麼方式、用什麼樣的手機、通過哪種瀏覽器做了一件什麼事情；
使用者資料，描述使用者本身的屬性，比如某順風車給乘客打上各種各樣的標籤，這些標籤肯定會用於後續產品迭代；
業務執行資料，線上下業務比較重的場景同樣很多；
內容資料，包含使用者瀏覽的具體內容，也包括與使用者發生互動的物件。
從資料所有者上來講，神策採集第一方資料——也就是“我們自己的產品，我們自己的使用者，自己使用者在自己產品上發生了什麼。”這是第一方資料。第一方資料採集在完全可控環節下發生，不僅比較便捷。在隱私策略方面，我們完全符合最嚴格的 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 種全埋點，到時候有興趣的話可以看看。（白皮書 |《Android 全埋點技術白皮書》重磅推出！開源所有專案原始碼！）
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 戳此下載
更多幹貨和案例，可以關注“神策資料”和“使用者行為洞察研究院”公眾號瞭解~ 