10月的第一場會員直播，我們邀請到了前滴滴高階資料產品@高遠老師，她將基於多年的資料產品經驗，深度解析O2O行業場景及痛點，從監控——分析——診斷三個層次拆解資料產品的構建思路。本文為直播內容整理，內容有刪改。
大家好，我叫高遠，之前就職於出行行業的一家頭部公司，擔任高階資料產品。近5年專注於出行行業、內容行業、工業方向的資料產品領域，掌握上述領域的體系化搭建方法，創新性地打造出資料產品獨有方法論，深度參與主流資料平臺（滴滴網約車和位元組內容方向）上述系統的規劃和設計；並對應用型資料產品有著深刻認知，在企業內部研發資料驅動、資料增長相關課程，累計學員超過1w人。
本次分享主要包括兩大部分：
第一部分
先給大家解析一下O2O行業業務管理的一些相關痛點；
第二部分
是關於資料產品整體落地的實踐，從level 1的資料監控，到level2的資料分析，再到到level3的資料診斷。
一、O2O行業業務管理痛點解析
先進入到第一個部分——O2O行業業務管理痛點解析。
作為業務型的資料產品，我用十四個字概括其核心要務就是：
比業務更懂業務，讓產品更加落地。
那大家就要考慮應該如何深入到業務中去，如何讓產品更好地落地。其實做資料產品也罷，做產品經理也罷，各種產品型別都萬變不離其宗，也就是要聚焦使用者。所以我們要很清楚我們的使用者到底是誰？我們服務於誰？
就上述問題我做了一個總結。大家可以看一下這個表格，我們服務於業務方，無非是面對兩類人群，第一類是區域負責人和部門leader等管理人員，第二類是運營、策略、市場等業務人員。
首先來看一下管理人員最關注什麼。管理人員需要第一時間產出相關資料，因為他需要透過這些資料去及時發現問題，並及時進行業務調整，所以資料監控對管理人員而言是非常重要的。另外，管理人員也想知道問題大概出在哪個環節。還有就是他們要做一些降本增效工作，所以需要知道如何去發揮人力最大的價值。
這些其實就是關於管理者的一些場景。那我們從需求層面來去抽象這些場景的話，可以概括為三點：
第一，需要多種時間粒度去監控業務的發展情況，更好地去發現業務問題。
第二，需要快速知道關鍵指標異動背後的原因，及時進行策略方向的調整。
第三，也是管理人員的終極目標，即如何透過一套科學的產品去提高人效和錢效。比如說以前可能需要五個人負責一個城市，現在可能透過資料的助力一個人就可以負責五個城市。
針對管理人員的這些需求，我們的解決方案裡包含了L1階段的資料監控，和L3階段的資料診斷。這部分後續再給大家詳細講解。
接下來就是關於業務人員。業務人員經常會面臨的場景可以總結為四類。
第一，每次進行業務分析都耗時耗力，尤其是對於一些分析理論掌握得不夠紮實的業務人員而言，他們的方法通常比較粗獷，沒有辦法很好地進行精細化運營。
第二，在O2O行業最重要的是供需，而長期供需是透過定價手段去調控的，那如何去證明這一次的調價策略是正確的，對城市是有益的，這需要業務去衡量。
第三，對於業務而言，如何分析和量化單點的、外部的、特殊的事件對整體業務的影響也是經常需要面對的工作，單點事件包括一些極端天氣、節假日等。
第四，對於常見的業務問題怎樣可以一站式解決，提升人效和錢效。
同樣地，根據這幾個場景，對應可以提煉出業務人員的主要需求：
一是
B&C端需要一套可行可落地的方法進行精心化運營。
二是
透過資料產品更好地去評估定價。
三是
將單點事件對業務的影響量化出來。
四是
追求一個更高的水平，就是把資料產品做得更加智慧化，能夠一站式解決常見的業務問題，不再需要一個一個環節去定位。
在解決方案上，業務人員最關注的是資料分析，也就是L2的產品；其次是L3資料診斷方面的產品；最後也還會關注L1資料監控，但畢竟是業務人員，他們更關注的還是如何解決問題，所以資料監控只是作為輔助。
那剛剛我們說到的L1、L2、L3對應的資料監控、資料分析、資料診斷，這些究竟是怎樣的概念？在整體的產品框架中起到怎樣的作用？
大家可以看一下這個圖。我們所有的產品都是在一些基礎平臺的模式上去建設的，具體可以分為對內和對外兩大部分。
這次就重點給大家分析資料產品的對內建設，即紅色虛線框內的內容。
首先
是關於L1資料監控方面是如何去落地到產品的；
其次
是分析層面的L2階段，比如核心分析、定價分析及事件分析如何落地這些產品、推動業務的；那
最高級別
，也就是L3診斷層的話，主要是關於如何透過指標的診斷一站式解決問題。
接下來我將會把之前實際落地操作過的一些產品拆解到每個小點裡給大家做詳細講述。此外，由於我之前做的是O2O的出行行業，所以會以出行行業為例給大家分享如何落地這三個方向的產品。
二、資料產品的落地實踐：監控——分析——診斷
接下來進入到第二個環節，也是本次課程的核心部分——資料產品的落地實踐：從監控到分析到診斷。
資料產品有三個層級。
第一層L1叫資料監控
，它可能是最基礎的一層，就是必須具備的。如果用一個詞去解釋的話就是需要去
“看數”
，從繁雜的資料中提煉出最核心的指標進行監控。
在這個基礎之上晉升一個層級到
L2的資料分析
，這個階段要能夠“
用數”
，專項問題專門解決，用統一的方法去解決專項問題，到這一步開始有一些思路和一些方向引導，去定位具體的問題。
第三層相對而言就比較難了，它是建立在L1和L2上的
資料診斷
產品，總結來說可以稱之為
“智數”
，也就是從發現問題到分析問題再到一站式解決問題，透過人機結合的方式幫助運營完成這個過程。
接下來我們就分別講解這三個層級該怎麼搭建。
1。 如何提取核心資料指標體系，高效把控業務表現
首先是資料監控這個環節。這個環節分四步走，
第一步
要去了解清楚盈利模式，
第二步
要根據盈利模式建構業務模型，
第三步
是在業務模型的基礎之上抽象出一些指標分類，那由指標分類以及現在業務的一些痛點訴求最終就可以進入
第四步
——監控產品的搭建。
在盈利模式這塊，拋開O2O這個行業來說，所有市面上的行業都可以用這一套理論去解決它的盈利模式。
這個模式分為兩個維度，維度一：是否省時間，維度二：是否直接提供價值。進而分為四個象限，其實每一種業務都可以對映到這個模式裡。
比如
第一象限的省時間且直接提供價值就可以對應工具類業務，
像拍照工具、支付工具等，這些都是可以以免費模式去提供給使用者的，當然可能會有一些增值服務去收取額外的一些費用，這部分其實就是這類業務的盈利模式。
然後
第二象限對應的就是內容類業務，
再細分的話可以分為兩種，第一種是自研模式，比如以售賣課程為主的業務；還有一種是流量模式，像短影片領域。
那
第三個象限的話是一些社交類業務，
比如聊天軟體等，這走的也是流量模式。
最後一個象限對應的是我們今天要重點講解的交易類業務。
就比如O2O行業，走的是佣金模式，因為O2O是融合線上線下的一個模型，這個模型本質是為了撮合B、C兩端的交易，我們就透過撮合這樣的交易從中獲取佣金，這就是O2O行業的盈利方式。
關於O2O行業使用的佣金模式，它的利潤公式是這樣的：利潤=單筆應收金額*（1-分賬比例）*單量
舉個簡單的例子，比如在出行行業，使用者今天上班打了一次車，然後我們收了一百塊錢，那這一百塊錢就是對應公式裡的“單筆應收金額”；“分賬比例”則是給司機的那一部分，剩下的就是給我們平臺中心；“單量”其實就是數量。
在實際過程中，除了分賬比例外有時候還需要扣除一些額外費用，比如補貼率，因為有些地方可能缺需求，那我們可能就會透過一些活動去補貼乘客；以及可能還有一些管理費用，所以要把所有成本都減掉。
出行行業的利潤是透過促成B&C端的交易來獲取的，那麼根據剛剛的利潤公式，要達到利潤最大化，無非就是提高單筆預售金額，降低分賬比例，提升單量。
當然，對於B端和C端又有不同的處理方式。假設我們平臺想透過提升單量來實現利潤最大化，需要思考的是如何幫助業務去刺激更多需求，也就是讓更多人去打車；而對於司機端，只有降低分賬比例才能提高我方利潤。這樣就會導致平臺和司機的利潤矛盾，所以你
需要去尋求平衡點——一個讓平臺和司機都相對滿意的最優值，
比如看看能不能讓司機獲得一些額外收入。
在剛剛的基礎上再做一些拆解，把相關指標分類提取出來，從而得到一張業務流程圖。
平臺的目標是提高利潤，那我們就透過流程拆解分析當前進度、差距以及挖掘增長窪地。
對於O2O平臺而言，萬變不離其宗，最重要的就是供需，關鍵就是去提升總量、調整結構。乘客端和司機端就像是翹翹板的兩端，需要平臺去平衡。
無論是是刺激乘客還是激勵司機，都需要透過一定的策略去實現，比如採取補貼活動。但是活動的效果有時候可能並不好，說我們補貼的一些活動，進而評估活動效果和ROI。
在這個基礎上繼續拆解得到這張圖，實際上就是將剛才的利潤公式進一步細化，並且分別對應B端和C端。
像應收金額=C端的需求訂單量*（B端的需求應答率*訂單完成率），因為一份訂單並不是直接就能達到完單的效果，還要看轉化率。
按照這樣把利潤公式裡的指標進行一層一層細拆下來的話，可以分為六類指標。
第一類是財務指標，
比如利潤、補貼等；
第二類是C端相關指標，
在O2O行業的話就是乘客相關指標，比如需求訂單量、C端補貼等；
第三類是B端相關指標，
包括需求應答率、訂單完成率、司機線上時長、B端補貼等。這三類屬於
縱向指標。
橫向指標
分類也包括三大類，
第一類是訂單相關指標，
比如訂單的轉化如何，是否存在漏洞，整體完成效果怎麼樣；
第二類是體驗相關指標，
比如司機的差評率，或者司機是否有投訴乘客等，雖然體驗這塊佔比會比較小，但對於平臺的傷害卻是比較大的，比如使用者打車覺得坐車環境比較差、有氣味兒之類的，可能下次就不會選這個司機了；
第三類是策略相關指標，
比如做活動花了多少錢等。
指標分類梳理清楚了之後就到了資料監控產品的落地環節。
有人就會說，做監控可以用excel 報表或者一些通用看板，為什麼要定製化看板，這樣不是更加耗時耗力嗎？
根據我之前的經驗，每一種方式都各有利弊。
首先是Excel報表的方式，
這種方式的優勢就是資料獲取靈活，自由度高，上手比較容易。但是缺點也多，比如自寫sql難度會比較高，因為寫sql的鏈路非常長；還有就是資料口徑難以保證、視覺化效果差等，所以這種方式其實不適用於長週期數據，比如在出行行業，當你拿到某條業務線全年的資料，這個Excel 報表可能得有幾百兆，根本打不開。
其次是通用報表，
很多企業會購買市面上一些比較成熟的報表比如Tableau、FineBI，這些通用報表其實也非常強大，資料非常全面，使用也比較簡單，都根據行業上一些標準方案去做的。同樣地，這種方式也存在一定的缺點，比如對於業務而言功能相對單一，查詢效能也比較有限，還無法添加個性化功能。就比如說我想快速看一下日均資料、周均資料，或者需要視覺化表達比較好的方式去展現同環比等，這類個性化功能比較難以實現，所以無法靈活地進行業務擴充套件。
因此，定製化開發的資料監控產品就應運而生了。
那它的優點還是比較多的，首先是資料全面；其次是功能強大、貼近業務，因為一切都是定製化的，你可以根據現在的業務特點去增加一些資料功能；另外，這種方式還可以支援多種時間粒度，就比如日均、周均、月均這些資料，各種豐富維度都可以實現；最後視覺化效果也比較好，最重要的是資料產出非常穩定。但唯一一個缺點就是需要進行定製開發。
總結而言，資料監控就是去解決管理者日常進行資料監控要面臨的場景，著重服務於管理者。
2。 以B端為例，透過運營、定價等分析落地資料產品
資料分析之核心分析
資料分析之定價分析
資料分析之事件分析
3。 資料驅動產品，資料診斷建設三步走
資料診斷之整體結論
資料診斷之原因分析
資料診斷之專屬策略
三、本月直播回顧
本次會員直播課程，高遠老師為大家詳細拆解了資料產品的構建思路，希望大家都能學以致用，以資料驅動業務發展！
每週三/四晚上8點，起點學院會員平臺都會邀請一線的網際網路產品、運營實戰派專家，與大家分享最新的產品行業動態、運營玩法和乾貨知識。
每個月的會員直播都有月度主題，每週直播圍繞月度主題展開。本月主題如下：
