本文由36氪企服點評專家團喬一鴨原創。
喬一鴨：見證 1500+ 企業數字化轉型實踐，分享團隊智慧。
————正文————
在企業服務廠商在實際轉型與發展的過程中逐漸認識到：只有企業資料積累並掌控資料驅動力才能在商業環境中佔有先機。越來越多的企業面臨著從“資訊對稱”到“資料驅動”的跨越。
如果說“資訊對稱”是解決既有痛點，那麼“資料驅動”則是挖掘並滿足企業發展中的未知需求。本節內容圍繞資料驅動下的企業服務常見問題進行講解。
一、資料驅動能夠為企業服務做什麼？
我們知道，企業服務模式是一種全新的商業模式，不只是把軟體、服務搬到網上那麼簡單，它意味著我們和客戶之間的長期夥伴關係。企業服務的本質在於：瞭解客戶的真實業務訴求，併為其提供優質的產品與服務，幫助其走出複雜商業環境中的發展困境。深諳此本質的企業，會從客戶成功角度去重構整體業務。
圍繞以使用者為中心，企業服務資料分析的核心需求如下。
第一，如何以較低的成本獲取高質量的客戶？
第二，如何快速判斷線索跟進優先順序，有效提升銷售線索轉化率？
第三，如何診斷易流失客群和高價值客群，實現客戶全生命週期支援與管理？
第四，如何根據資料提供優質的客戶服務，增強客戶黏性，保障客戶續約率？
綜上，我總結成如下圖：
企業服務資料分析核心
二、企業服務資料驅動之路面臨的挑戰
企業服務資料驅動面臨著以下挑戰:
資料孤島——前端行為資料和線下、CRM、ERP等後端業務資料無法打通；
產品功能複雜，動輒上千個埋點，不知如何定義和管理資料模型；
跨部門、多業務線資料完全獨立，無法全域性分析。
三、一家移動CRM 資料驅動的真實案例
下面我以A 公司——一家提供移動CRM的 TO B 廠商為例。A 公司堅持以客戶為重，並一直有較強的資料驅動業績增長意識——對客戶獲取、潛客線索管理和最佳化以及客戶服務等業務流程進行持續最佳化，從而實現整體經營績效的提升。
他的資料驅動實踐經過了需求梳理、事件設計、資料接入等流程，我將詳細進行介紹。
（一）需求梳理階段
A 公司希望透過資料分析瞭解客戶和真實業務訴求，對客戶行為的深度洞察，併為其提供優質的產品與服務，為實現獲客渠道最佳化、銷售線索轉化率提升以及保障客戶續約率，最終驅動企業業績可持續增長。
透過以上分析，高效獲取客戶以及提高線索轉化率、使用者對於產品的使用情況等這些需求的著眼點是使用者，而對客戶整體情況以及健康度等的瞭解著眼點是企業。
第一， 針對使用者的需求梳理。希望能夠實現官網潛客使用者行為精細化分析；針對產品進行精細化分析；
第二， 針對企業的需求梳理。A 公司業務線豐富，希望能夠實現多條業務線的交叉分析，實現對企業的精細化運營。
（二）事件設計階段
根據企業的實際情況設計了以使用者為主體、以企業為主體的兩套不同的事件設計。
1.以使用者為主體的事件設計
針對官網潛客使用者行為精細化分析：
（1）WEB 瀏覽頁面
（2）WEB 元素點選
（3）註冊&登入等
針對產品精細化分析：
（1）WEB 瀏覽頁面
（2）功能模組操作事件
在CRM模組操作事件中，它會涉及 N 多功能點 N 多操作，那麼如何設計資料模型才能高效分析呢？一個功能點一個操作設計一個事件嗎？顯然不行，這樣會有 N 多事件。有沒有可能設計一個事件就能包含CRM模組的所有功能點和所有操作呢？
要做到這點，要先梳理 CRM模組所有的模組、子模組和所有的操作型別，最終確定包含的屬性有企業 ID 、模組名稱、子模組名稱、操作 ID 、業務型別等屬性，這樣就能透過這一個埋點事件，將使用者在 CRM 模組所有行為都捕捉到了。
2.以企業為主體的事件設計
A 公司一共有5條業務線，任何一個業務線的大多數操作請求都會觸發一條後端業務請求，這個過程會涉及3000 多個介面，在任何一個介面被呼叫，那麼需不需要設計 3000 多個埋點事件呢？
實際上A 公司完全可以設計一個事件透過屬性的擴充去覆蓋所有請求。
梳理所有的介面，如果介面設計的很規範的話，就能夠按照一定的清洗規則對介面進行切分，最後將 3000 個介面資料清洗轉化為一個埋點事件，它具有的屬性有員工ID、一級分類介面、二級分類介面、具體介面名、產品版本、Event_value、FullAction 等。再結合豐富的使用者屬性，如企業 ID、企業名稱、企業規模、企業分組、企業付費類別、企業一級行業、企業二級行業、註冊時間、開通時間、代理商 ID、企業開通賬號數、購買賬號數、獨立使用者 ID 等。透過事件屬性和使用者屬性的交叉分析，實現對企業的精細化運營。
（三）資料接入階段
A 公司因為要統計線上資料，任何一個介面被呼叫都要統計到，同時要保證傳送的資料不重不漏，另外考慮到自己後臺介面資料很規範，沒有必要再耗費大量人力透過程式碼埋點的方式重新埋點，所以最終採用如下兩種方式進行資料接入。
1.通過後端資料實時匯入的方式接入資料；
按照上述定義好的事件設計格式，通過後端資料實時匯入的方式匯入系統後，A 公司可能發現了另外一個問題：這些資料都高度聚合，那麼如何定位到具體的功能或功能模組呢？透過虛擬事件功能，業務人員自主定義自己想看的功能。如只有完成了某些核心功能的企業才能算作活躍的企業，那麼就可以配置活躍企業數這個指標。
2.業務模組操作行為資料前端採集或者將資料倉庫中的資料匯入系統中；
此種採集方式較上述呼叫後端介面事件而言，能採集到使用者一些更細粒度的操作行為資料，同時這些操作純屬於前端操作行為，不會返回給後臺介面的資料。
四、實現了哪些應用場景
以下是 A 公司的企業資料分析的應用實踐。
- 場景一：一個埋點事件支撐 5 條業務線 21 個團隊資料分析需求；
我們知道，企業服務類企業成功的關鍵是促使企業使用者活躍，提高企業客戶的留存，降低企業客戶的流失，所以 A 公司需要對企業的健康度做一個比較全面的分析，及時發現健康度不佳的企業。
A 公司一直關注活躍的企業數和員工數有多少，以及每天的變化趨勢；並進行企業質量的衡量，如平均一個企業中有多少個使用者使用，線上的員工佔企業開通員工的比例。
這個過程存在兩個難點，如何定義企業線上和企業活躍。所謂線上即產品任何一個功能點被使用則可被看做線上，那麼問題來了，既然是任何一個功能被使用，企業服務產品功能相對繁雜，那豈不是要埋上千個事件？透過事件分析模型將上千個事件整合為一個事件再配有詳細的屬性就可以解決了。每個業務線每個團隊的人員只需要按照自己業務線的需求靈活配置出自己想看的企業指標資料就可以了。
- 場景二：快速判斷線索跟進優先順序，有效提升銷售線索轉化率；
來自營銷渠道的線索量大，CRM 系統通常記錄客戶基本情況，如公司名稱、跟進狀態、聯絡方式及客戶所在地等；銷售團隊往往透過電話第一時間去判斷客戶需求、購買意願，至於每條銷售線索的處理優先順序、哪些需求緊急、客戶贏單的可能性大小，較難進行快速和客觀判斷。因此，將判斷銷售線索情況的關鍵資訊判斷優先順序，如 SaaS 公司產品 Demo 的註冊、使用等行為資料，引入企業 CRM 系統，輔助銷售進行快速判別。
圖：CRM 系統客戶基本情況
採用後端 API 採集的方式，將使用者行為資料整合到企業 CRM 系統，如圖。將採集計算好的使用者行為資料，傳到 CRM 上來跟蹤線索，主要整合以下兩個欄位：
一是，最近登入時間，即使用者最近一次登入產品的時間；
二是，總查詢次數，即潛在客戶在產品 Demo 上核心功能的使用查詢次數。
圖：後端 API 整合 Demo 試用行為資料至CRM 系統
可以透過虛擬事件定義核心功能使用次數，來計算“總查詢次數”。
對一款 SaaS 產品而言，其核心功能涉及的業務模組會很多，且每個業務模組下都有部分核心功能，任意一個核心功能的使用，都可以當作客戶觸達了產品的價值點，所以需要透過虛擬事件的方法，將分散的各個核心功能整合為一條事件，進行整體分析。
例如我們非常關注使用者在 Demo 上，“行為事件分析功能”、“漏斗分析功能”、“留存分析功能”、“回訪分析功能”、“概覽操作”等核心功能的使用情況，於是建立一條虛擬事件。建立好後，通過後端 API 採集的方式將該條事件的計算結果（總查詢次數）傳入 CRM ，從而輔助銷售團隊去檢視產品試用情況、快速判斷使用者需求和銷售切入點。
把CRM和資料分析平臺的結合，即可高效獲取大量詳細的銷售線索相關關鍵資訊，同時利用使用者的行為，做到有的放矢，及時調整了銷售跟進策略，對不同的客戶排出優先順序，提高整體銷售效率和有效線索轉化率。
第一，優先聯絡總查詢次數高的客戶；
如果客戶的核心功能使用次數或總查詢次數從申請試用後，一直保持一個比較高的趨勢的話，說明這個潛在客戶轉化的可能性比較高，銷售團隊會高優先順序聯絡這批客戶。
第二，根據最近登入時間判斷客戶的使用動態；
優先選擇最近登入時間比較靠前的客戶，對於沉寂的客戶，可以放低優先順序，如果某個客戶在沉寂一段時間後，某一天突然登入了，這時就可以及時跟進該客戶，儘早掌握客戶動態，確保最終的轉化。
從實際案例來看，銷售人員拿到有價值的資訊後，有針對性跟進，在策略實施一個月後，銷售線索的有效線索轉化率提高了 6%，間接提高了最終的贏單率。
- 場景三：提供優質的客戶服務，增強客戶黏性，保障客戶續約率；
業務不會揭示問題，使用者行為會揭示問題，哪些使用者是高活躍使用者，哪些是高風險使用者，需要從客戶活躍度的角度進行監控。
A 公司透過功能細分檢視不同功能的活躍度，發現大部分保持高活躍的企業使用者，主要使用的功能居然是考勤簽到功能，而這個功能可能是銷售人員迫於績效壓力，每天例行簽到的，簽完到就不使用產品了。
從這可以看出定義產品活躍度的指標是不合適的，需要做出調整，只有做過核心功能的企業使用者才算作活躍使用者。完成核心功能的企業數和員工數的變化趨勢才是客戶成功團隊關心的第一關鍵指標。如果只是瀏覽或點選某個功能是沒有用的，只有深入使用產品的核心功能，才能發現產品價值。
對於活躍度的定義更進一步，限定每個企業至少有 3 個員工線上，並且做了核心動作中至少一個才算作活躍企業。此時可以透過分佈分析來看出企業活躍度分佈。對活躍度低的企業，是一個重要的流失預警訊號，需要重點跟進，加強培訓。
- 場景四：對客戶分層管理，構建企業畫像，實現客戶全生命週期的支援與管理。
A 公司靈活根據其客戶使用不同產品功能的頻率、活躍天數、人均使用次數等資料指標，對客戶進行分層管理，詳細瞭解每一類客戶是如何使用產品的，然後會對他們採取不同的策略。幫助企業客戶成功團隊和銷售團隊，密切關注企業狀態，瞭解何時需要及時干預，實現客戶全生命週期的支援與管理。
1.高活躍度客戶：A 公司運營人員總結他們的使用經驗，將這些經驗固化下來，想辦法傳遞給更多的客戶，引導其它企業按照此方法使用，更好實現業務價值；
2.一般活躍客戶：使用率一般的客戶佔企業使用者群體大多數，A 公司運營人員常規地保持服務即可；
3.流失風險客戶：定義一個數據模型，找到這些有流失風險的客戶，對於這些客戶，A 公司客戶成功團隊重點跟進，透過溝通、培訓等方式來幫助他們；
4.已經流失客戶：也就是不再使用或者不續費的客戶，A 公司運營人員透過各種方式觸達他們，分析流失的原因，以便於後續改進企業的產品、運營和銷售。
www.36dianping.com
[免責宣告]
原文標題：《資料分析深度案例 | TO B 企業如何從零到一實現資料驅動？》
作者：喬一鴨
本文來源於36氪企服點評
