O2O行業資料平臺實戰:從監控到診斷的資料產品搭建
如何挖掘資料潛力,更好對業務推進 360 度分析和問題定位? 如何對業務進行降本增效,提高整體業務的效率? 如何做一些對業務真正有推動的資料產品,真正發揮資料產品的價值?
O2O 行業業務管理痛點解析 資料產品的落地實踐:監控-分析-診斷
分享嘉賓|高遠 位元組跳動 資深資料產品
編輯整理|DataFun志願者
出品社群|DataFun
01
O2O 行業業務管理痛點解析
作為業務型資料產品,需要比“業務更加了解業務,讓產品更加落地”,資料產品屬於產品的一個分支,在做產品之前,首先要去看一下我們的使用者是誰。按業務場景來看,使用者分為兩類,一類是業務管理人員,比如區域負責人、部門 leader;另一類是業務一線人員,包括但不僅限於一線的運營與策略同學,以及一線業務等。
針對不同使用者群體,面臨的問題也是不一樣的。
① 對於管理人員,其訴求總結為三方面:
及時和靈活的資料包表供宏觀分析;
業務核心指標(GMV/完單量等)發生異動之後準確及時分析原因。如果能更快給到業務管理者一個方向,對整個業務而言價值是非常大的;
管理者需要一套更加科學的方法去提升人效和錢效。
② 我們再來看一下業務人員的訴求,總結出來有以下幾點:
每次業務自行分析都需要消耗大量時間,且方法比較粗獷,不利於精細化運營;
O2O 行業裡面會涉及到一些定價的方法,如何更好的去做一些定價的調控,如何去評估業務的難點,還有一些日常規的業務問題。
針對這些需求痛點,我們給予的解決方案是三步走的戰略:第一步是關於如何透過資料監控產品的形式解決上述各種人群遇到的問題;第二步是資料分析層面,比資料監控更高一層;第三步是資料診斷。
接下來將對“監控-分析-診斷”三步走戰略的資料產品落地實踐進行講解。
02
本章節分為以下幾部分:
如何提取核心資料指標體系,高效把控業務表現
以 B 端為例,透過運營、定價分析落地資料產品
資料驅動產品,資料診斷建設三步走
整體總結
1. 監控-如何提取核心資料指標體系,高效把控業務表現
首先介紹三步走中的“監控”。以資料監控產品為例,如何去提取一些比較核心的資料指標,構建指標體系,再進行高效的業務分析。針對不同的業務,在做監控產品時,大家可以透過以下方式進行:
摸底業務盈利模式:需要先判斷現在業務盈利模式是怎樣的;
指標分類:根據盈利模式再做一些指標的分類;
監控產品:最後去落地產品的最終形態,實現監控產品。
① 摸底業務盈利模式
說起盈利模式,在網際網路場景下,我們按照是否直接提供價值和是否省時間,可以把所有行業分為以下 4 個象限,分別為內容類業務(如抖音),工具類業務(如飛書),交易類業務(如天貓、美團),以及社交類業務(微博)。不同的行業象限,其盈利模式是不一樣的,今天重點介紹交易類業務。
交易類業務盈利模式案例:
由於今天重點分析 O2O,只講下交易類業務按佣金模式的盈利。佣金模式會涉及到自己的盈利公式,單純用“利潤=單筆的應收金額*單量”肯定是不夠的,因為透過佣金模式來為企業賺錢的話,需要排除掉一些分賬比例。比如外賣業務,可能一單客戶(C 端)的實付價 10 元,這 10 元不可能完全給到商家(B端),也不能完全給到外賣員(D 端),需要抽一些利潤作為企業本身的利潤,以此來作為盈利的收入,這樣得到一個整體的利潤公式。同時,還要減去一些補貼,因為訂外賣時會有一些補貼發放(神券、滿減券等),這些也在成本範圍,需要從利潤中剔除,最終得到利潤。
② 指標分類
再看 O2O 行業,因為它其實是一個撮合型業務,即撮合客戶(C 端)和商家(B 端),以這個目標為切入點,把利潤也分為 C 端和 B 端。
我們希望像天平一樣,兩端的量是均衡的,這樣平臺的受益才會更大,所以 C 端,會想如何提升他的訂單量,或者提升客單價。B 端可能如果單純從企業的角度出發,會想如何降低分賬比例與補貼等方式,來提高企業的利潤。在這樣的盈利模式下,我們其實可以構建交易類業務的資料指標體系。以利潤為出發點,是我們時時刻刻圍繞的目標,這個建設方式相對而言是比較有效的。
③ 監控產品
指標體系有了,最後一步是去做監控型產品。日常的監控產品形態,分為以下三類:
最經典的產品:Excel 報表
Excel 的靈活性、強大性,其它產品很難取代,但它也有一些侷限,比如一線的業務同學可能 Excel 的使用能力比較薄弱,一些比較難的公式,如補貼率,或是可能長達百行的財務類公式,對於運營同學而言,有一定的學習成本。而且隨著口徑的複雜,取數的準確性也比較難以保證。Excel 視覺化效果的連續性比較差,比如只能做一些切片(資料量少),定量地去看一週或一個月比較小段的資料連續性,如果看歷史多年資料趨勢,資料就會跑崩,效果會比較差。
通用報表:Tabular 等
通用的報表,國外的類似於 Tabular,國內的比如帆軟、神策等第三方資料整合平臺,比 Excel 要上升了一個層次,資料使用比較簡單,整合性也比較好。但其問題在於,因為它是做一些通用化解決方案,功能比較單一,並且是成套售賣,要去新增一些個性化查詢功能可能存在困難。
定製化看板
我比較推崇的是自建監控型的看板與產品。它的優點非常多:首先資料會比較全面,功能也會相對比較強大,因為都是按照業務本身的需求情況來實現的功能;可以自定義時間力度,比如按天、按周、按月,甚至按年,能很快的在一個產品內,把所有管理者或者是一線業務所需要的資料都展示出來,並且可以透過一些技術最佳化手段來保證資料的 SLA 與 DQC;最大的一個好處是保障資料安全性,因為我們可以做到按指標密級鑑權,或業務線組織節點管控資料許可權,比如GMV或者財務類這樣高密級指標,是比較敏感的,需要更靈活的管控。
定製化看板唯一的缺點也比較明顯,就是需要去做一些定製化的開發。
再來介紹第二個方面“分析”。
以 B 端運營為例,如何去落地相關資料產品?
在這個課題之下,我們分為兩個角度來看如何做分析:
從短中期視角,資料監控體系搭好後,如何去更加精細化分析,把運營方式沉澱到產品上;
長期視角,涉及到定價策略與佣金策略的調整。這些策略調整一般不頻繁,但對於業務影響是非常深遠的。
① 短中期運營-核心分析
以商家分析為例,核心分析為以下內容:
整體盤面
結構分析
流轉分析
整體盤面:之前已經做了資料監控產品,為什麼現在還要去看資料的趨勢?原因是我們現在面對的是更細分下鑽的運營場景,所表達出的一些指標可能會更細化,幫助我們的一線業務同學更好的去把控進度。所以不能單純看監控結果,整體大盤分析還是非常有必要的。
結構分析:在看完大盤的基礎上,我們可以去看一下結構,如 6 月 15 號這一天,有一個峰值,大家肯定會去關注 15 號這一天到底是哪一些人群為 GMV,為訂單提供更多的貢獻?比如可能是成熟類的商家,對於大盤貢獻更多。所以第二步解決的結構分析,主要是去分析誰為這樣的一些資料指標提供了貢獻。我們透過分層柱狀圖的形式對大盤去做拆解,看是誰的貢獻最多。這個問題解決後,我們對指標的變化情況其實心裡面已經有一個摸底了。
留存分析:我們再做一些關於流轉留存方面的分析。以 B 端商家人群為例(8 月),把商家人群分為不同的人群型別:高潛的商家,核心的商家,新商家。把 8 月的人群標籤固定,看 9 月份這些商家流轉是怎麼樣的,很可能會出現以下三種情況的變化,一種是從新商家人群轉移到成熟的商家,可能會有一個顯著的提頻,這是我們都願意看到的正向的走勢;還有一種是從 8 月到 9 月,整體人群的狀態沒有變,之前是成熟商家,現在還是成熟商家;還有一部分是降頻人群,即灰色區域,我們是需要非常關注的,因為降頻就意味著 GMV、訂單量會有一些損失,誰降頻了,為什麼降頻,是否需要把手頭的一些資源給到這些使用者,把他們引回來。
以上就是運營過程中比較典型的一個流轉留存運營場景,還有一種叫留存分析。關注商家粘性,粘性越強收益可能會越好。所以我們會固定 8 月第一週引入一批新商家,看 8 月後幾周留存情況,主要是哪些商家流失了,為什麼流失?我們可以透過這樣的一個產品形式,來一鍵幫助業務同學去定位到有問題的商家,幫助他們進行下一步的提頻、促活相關策略。
總結如下:
② 長期運營-定價分析
定價是一個很低頻的調整,比如說以季度以半年這樣的時間頻次去做一些調整。那麼綜合什麼樣的情況之下,才會做定價或者是佣金相關的一些調整?有以下 4 個方面:
市場環境:完全競爭的市場還是非完全競爭市場;
長期的週期性事件:季節更替,淡季和旺季等定價肯定是不太一樣的;
競爭對手:直接與間接競爭對手;
政策因素:政府政策頒佈
在 O2O 定價場景下,我們到底怎麼去調,為什麼要去調?分為以下幾個方面:
整體情況
實施調價
調價評估
整體情況:第一,整體定調。比如外賣一般是基於城市力度去調,北上廣深等一線城市與二線城市調的策略和力度是不一樣的,因為城市的體量、人均的收入、整體大環境等,引發了檔位不同。第二,從市場佔有率和競爭分析。如果是競爭態勢的急速擴張,以拉新為目的,定價相對而言會比較低。第三,供需核心指標,看這個城市到底是不是有這麼大需求,去綜合情況做定價結論。
實施調價:動態定價是在合適的時間找到合適的使用者,並且售賣。它是基於經濟學原理中,人們對激勵做出反應這樣的基本策略來去進行調的。
舉個簡單例子,下邊圖橫軸商品數量,縱軸商品價格。黃線是需求曲線,綠線是供給曲線。比如我現在要去買一個包子,定價越高,引入的商家也會越多,但是消費者的情況是相反的,越便宜消費者的數量會越多,因此要在兩者之間找到一個平衡點實現全域性最優。
調價評估:調完之後,要關注以下 3 個方面:
看目標:我們調前會有一個目標,調完之後是否實現了目標?比如完單變多了,還是毛利變多了?
看體驗:使用者 NPS,商家整體反饋。
看輿情:輿情對企業、對品牌至關重要,定價調的過高可能會損害消費者利益,就很容易上熱搜,使公司造成損傷,所以定價調的時候一定要慎重。
① 診斷的前提
接下來介紹診斷資料驅動產品是如何去做的。在建設診斷產品之前,要注意我們現在是否滿足了以下 3 個條件:
資料建設成熟:底層資料基建,各種明細表,輕度彙總表是否完善。
資料應用穩健:基礎的資料應用是否穩健,比如監控方面的資料是否穩定產出,或基本的一些資料分析應用是否搭建完善。
業務形態穩定:診斷建設的成本會比較高,上線之後改動起來靈活度會比較低,所以一定要注意業務形態是不是處於一個穩定期,已經找到商業模式。
② 指標洞察
先做整體診斷結論
原因分析
以 GMV 為例講解:
整體診斷結論:診斷類產品最先需要給出結論,有沒有問題?程度是否嚴重?
有沒有問題:和對比周期相比較,是否發生上漲或者下降
程度是否嚴重:上漲/下降的幅度是否超過閾值(例如 5%)
首先,需要給出結論是異常偏高的,還是正常的或偏低的。可能這個地方或區域破峰值了,這種情況對 GMV 要做相關的一些拆解,比如完成訂單數漲了,還是客單價單均漲了。
原因分析:從各個角度出發分析原因。O2O 行業會被天氣、節假日、政策以及輿情等外部動向影響,在內部表現上,去做維度拆解,可以分 B、C 端。以訂單為例,計算各個維度的貢獻度,分析貢獻高的一些地區和時段等維值,透過這些分析結果去支撐診斷的結論。
① 問題覆盤
我們回顧一下,不同使用者在使用資料時遇到的痛點,是否可以解決?
管理側:希望透過各種時間力度去監控業務發展的情況,這個肯定沒有問題,因為第一步資料監控,就是為管理層量身定做的。同時他需要知道一些關鍵指標的異動與原因,透過第三步診斷產品可以解決。
業務側:業務側更精細化的一些運營需求,可以透過第二步資料分析裡的核心分析,落地資料產品的方式,給到他們相關的一些經驗的傳承和落地。並且定價分析可以解決如何評估定價效果的問題。關於資料診斷,因為管理者會關注核心指標,所以有一些業務同學也是需要去看的。
② 提升總結
最後,關於提升的總結,有以下三點:
具體問題具體分析:前文介紹了整體業務型的資料產品建設的三層結構,分別是監控、分析和診斷,需要根據不同的業務發展情況、規模來判斷,一定要因地制宜,看一下現在業務發展是屬於新生還是中期,是高速增長期還是屬於平緩時期,每個時期的解決方法是不一樣的,可以有針對性的去解決。
核心問題重點考慮:在比較複雜的業務場景下,所涉及的業務鏈條非常多,如果我們想最大化業務型資料產品的價值,一定要在各個環節裡面抓重要核心,做一個業務型的資料產品,要比業務同學更加了解業務。
跨領域的思想遷移:除了 O2O 行業,我在傳統的工業資料化轉型都有過相關的一些經驗,所以上述的方法在各個領域都有嘗試去落地。大家可以思考下,如何運用本文講解的一套方法去落地到大家現在所處的各個行業。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024923/viewspace-2933038/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 從監控到診斷:資料的力量
- 2020實戰覆盤:如何從0到1搭建資料傳輸平臺產品DTS?
- OPPO大資料診斷平臺設計與實踐大資料
- 從GrowingIO產品到平臺的進化看資料分析的演變
- 從0到1搭建DeltaLake大資料平臺大資料
- 資料產品:CDP(客戶資料平臺)必備的產品能力
- 資料視覺化平臺搭建,警務實戰平臺大資料應用視覺化大資料
- 七牛大資料平臺的實時資料分析實戰大資料
- Zabbix監控平臺的搭建
- 產品解讀 | 資料服務平臺:KDP
- linux監控平臺搭建Linux
- 大快DKH大資料基礎資料平臺的監控引數說明大資料
- 五個篇章講明白如何從0到1搭建大資料平臺大資料
- 大資料治理——搭建大資料探索平臺大資料
- 資料分析平臺搭建指南
- 大資料平臺CDH搭建大資料
- Prometheus + Grafana 監控平臺搭建PrometheusGrafana
- CDGA|從平臺自治到規範化的資料治理
- 解決方案丨資料治理實戰:滴滴資料資產管理產品解決方案
- 大資料風控平臺需求大資料
- 企業為何需要搭建大資料平臺大資料
- DKHadoop大資料視覺化平臺監控功能深度解析Hadoop大資料視覺化
- 大資料開發-資料表監控-實現大資料
- linux下cacti監控平臺的搭建Linux
- 履約產品:產品體系&履約監控產品搭建
- 大資料開發實戰:實時資料平臺和流計算大資料
- GO實現資料夾監控Go
- 工業物聯網資料中臺實現多種資料監控與智慧管理
- 怎樣搭建大資料平臺大資料
- 新一代大資料計算引擎 Flink從入門到實戰 (14) -監控和調優大資料
- 實時工業大資料產品實踐——上汽集團資料湖大資料
- 使用SQL_TRACE進行資料庫診斷(轉)SQL資料庫
- 振弦式感測器資料採集到水庫大壩監測雲平臺進行監控和報警
- zanePerfor前端監控平臺效能優化之資料庫分表前端優化資料庫
- 大資料平臺是什麼?有哪些功能?如何搭建大資料平臺?大資料
- MySQL資料庫與Nacos搭建監控服務MySql資料庫
- 搭建前端監控,如何採集異常資料?前端
- 回顧·大資料平臺從0到1之後大資料