數據建設工作該如何展開?

2 評論 10939 瀏覽 67 收藏 15 分鐘

數據建設工作并不是一件簡單的事,在做好數據建設是需要講方法的。

之前有個讀者給亮哥留個言,但亮哥無法回答,只有沉默了,想了想,今天還是寫一篇文章吧。

讀者問:

亮哥你好,看你的書很久了,但是有一個問題困擾了我很久。在做用戶數據分析的時候,我們常用的第三方類似Umeng這種統計工具,其相關數據是不互通的,也就是我沒辦法從用戶的活躍數據,反推到這部分用戶在功能使用上的情況。 另外多數公司在人力物力上的不足,以及時間成本的影響,都沒有條件自建數據統計工具,這種情況下,有沒有什么比較好的辦法,可以處理這樣的矛盾呢? 另外自建數據統計系統,有什么好的建議嗎?

1.數據的維度

「維度」這兩個字,很多人在做數據分析提需求的時候,都會碰到。

但也有很多人寫成「緯度」、「圍度」,其實亮哥不知道哪個是對的,但是從我的理解來說,「維度」比較合理。

在互聯網里工作,對數據這件事情,可以說,任何一個工種,都必須與之打交道,只不過關注的點可能并不一致而已。

對于做市場、PR、公關的同學來說,他們關心的是大而化之的數據,你會發現那些市場品牌宣傳稿、公關稿里談及數據,都很大,譬如:

某產品上線至今,擁有X萬/億注冊用戶,日活用戶超過Y萬/億,平均每5分鐘,產品就會被下載一次……每秒鐘同步處理Z筆交易……

諸如此類。

對于做產品的同學來說,他們關心的是用戶怎么使用產品,用戶從哪些入口進入,在哪些頁面或功能點上停留進行使用,多長時間或達成何種目標后離開。

對于做運營的同學來說,他們關心獲取一個新用戶需要多少錢,自己的活動有沒有好看的ROI,自己申請的預算是否帶來了預估的效果,下個月的KPI究竟是用戶活躍還是轉化付費。

所以,如果一家公司里,沒有人關心數據,或者說,該關心數據的人不關心數據,或者關心了錯誤的數據,那就是一場災難。

數據的維度非常廣泛,有時間維度(日、月、年、時、分、秒……),也有動作維度(注冊、激活、登錄、使用、轉化、付費、流失……),還有空間維度(訪問時長、頁面數……),以及各種率。

對于一家企業來說,想要好好的運營(我說大運營),對于數據的把控是十分重要的,這一點不必多說。

2.做產品最需要知道的一些數據

Web和App,大家關心的點是不一樣的。

大多數人會接觸的都是非常表層的數據。

譬如說,Web時代,講究UV、PV、訪問頁面數、停留時長,這些看起來是很通用的指標;App呢,就講究注冊用戶數、活躍用戶數、付費用戶數,這些看起來也是很通用的指標。

所以,你會發現,Web時代,Google、百度都會提供統計工具,實現方式也很簡單,申請個賬號,獲取一段代碼,把代碼放到每個頁面里,這是最粗的做法;App時代,也有人提供統計工具,友盟啊、諸葛io啊,之類的,有些只要你接入SDK,有些則需要你上線部署。

但是,我說的這些都是很粗的維度。

這些粗顆粒的數據,在粗放式運營時可能很管用,但是它們都只能體現最表層的數據,也就是說,你可以通過數據的走勢去判斷目前產品的健康程度和成長情況。

但是,一旦數據發生大波動,你想要找到原因,就難了,因為這些宏觀數據并不進入微觀領域。

你想要了解微觀,那么,Web時代,你要會配置路徑,所謂路徑,就是流量從進入到離開,經過的路線,和打游戲一樣,你要植入足夠的偵察力量,你才能拿回來一些情報用作監控,或者分析;App時代呢,你需要有自己的數據團隊,他們要能夠去通過埋點搭建出用戶的行為模型,在模型里,可以看到用戶的使用情況。

其實就這么簡單,因為這些都是基礎工作。

而在基礎工作中,提出需求和上線解決就很重要,這也就進入了這位讀者糾結的部分。

3.如何提出數據需求

這里,亮哥要和你聊聊怎么去提數據需求,以及從哪里去摸出數據需求的線索。

如果今天,開發團隊里有一個數據小組,你知道作為運營要如何去提數據需求嗎?

第一,你要非常了解業務。

什么是非常了解業務呢?我在訓練一個數據專員的時候,會要求他用2周時間,什么事兒都不干,去和每個業務Leader聊天,弄清楚目前涉及到各業務的產品中,整個業務流程是怎樣的,用戶的使用流程又是怎樣的,需要幾步動作,最后會反饋什么。然后回來和我說,能說清楚的,進入下一環,說不清楚的,重新去了解,直到能掌握業務的真實情況才算完成。

第二,要基于業務的未來去提埋點需求。

也就是說,要建立數據體系,不僅要知道業務的現狀,也要非常了解業務的未來,這個時候,就需要一張清單,目前業務涉及的產品,都做了什么,還有哪些是未來一段時間(譬如,3個月)會進行調整的,清單里要有功能、埋點狀況、計劃完成時間等一系列的狀況說明,然后備注需要通過這個埋點,了解什么。

譬如說,一個注冊流程。

注冊流程是否簡單,我們可以通過:注冊完成率、X步放棄率來看,那么就要統計進入人數、注冊用戶數、資料填寫的每一步的完成和放棄的絕對值與比例。

可能你會說,知道注冊完成率就好了,為什么要考慮X步放棄率。

很簡單,X步放棄率中的X步出現越多,就證明這一步存在問題,進而要去提出優化假設并通過數據驗證,是否讓X步放棄率降低。

第三,需求明確,且重點明晰。

我真的有見過,去問需要數據埋點嗎?需要。怎么個埋法,哪些位置需要埋?答曰:所有都要。

其實這種回答代表著,要么沒想清楚自己要什么,要么是根本不知道應該關注什么。

我們在數據建設中,有一個名詞叫做「經營分析關鍵指標項」,這個名詞的意思是:不管業務涉及多少數據,只要這個指標發生變化,數據就一定會對應的有變化,而且是大變化。

譬如,電商里有個公式,叫做:

銷售額=銷售單價x銷售量。

這里面,如果要銷售額增加,那么要么單價上升,要么銷量上升,所以,這兩個指標就是關鍵指標。

但是,如果商品本身的售價一直都很穩定,那么關鍵指標其實就是銷量。反過來,如果數據表明,這個商品本身價格是堅挺的,不存在隨意修改的可能,那么關鍵項就是拉動銷量增長,你可以不用關注單價變化,反之亦然。

所以,提數據需求一定要弄清楚核心數據和邊緣數據,關鍵數據與輔助數據,提出來的需求才有人愿意和你玩。

4.數據的分層次推進

如同提問者問的一樣,很多公司并沒有那么多的財力、物力,還要自己做數據平臺嗎?

我的回答必然是:要!

問題是,怎么做?

這里就要談到一個層層推進的問題了。

前面已經提到了,有些數據的顆粒度很粗,可以利用第三方去完成,而一旦進入業務支撐的數據分析,靠第三方就不太可能了。

那么,不管你是多小的公司,分層去推進數據建設這件事兒,永遠是成立的。

Step1:搞定核心業務的數據

埋點本身是費時費力的活兒,但是我相信,只要是能活下來,或者有希望活下來的公司,即便沒有找到商業模式,也應該意識到自己的核心業務是什么了。

那么,圍繞核心業務所需要的數據,先把這個業務的所有數據的埋點給做掉,就是最初要做的事情。

Step2:明確核心業務的數據呈現結構

有些業務是漏斗式的,用戶通過1、2、3的分步驟操作,來完成業務流程,那么,通過建立數據漏斗,就能看到用戶在整個業務流程里實際的使用情況。

譬如說,交易平臺,用戶的業務流程是:

瀏覽-下單-支付-收貨-評價

你其實會發現,漏斗在這里是明顯存在的,瀏覽-下單有下單轉化率;下單-支付有支付轉化率;支付內部有支付成功率;支付完成-收貨有個確認轉化率;收貨完成-評價,有個評價轉化率。

但對于核心業務流來說,前期只需要去搞定瀏覽-下單-支付,即可。

什么,人力還不夠?那么下單-支付總歸要做的。

等把核心業務流做完,再去向前和向后去延伸埋點布局。

同理,當核心業務的數據建設告一段落,就繼續去做其他的非核心業務的數據建設。一個一個來,雖然看起來工作量不小,但總有完成的一天。

Step3:埋點建設與報表輸出

第二步做完就趕緊先埋點。有能力,去做自動化報表,沒能力,用個簡易后臺提供查詢即可,再沒能力,數據同學提供查詢SQL,開發權限給相關的接口人員自行提供查詢。

Step4:如法炮制其他業務的數據建設

做法基本一致,只要能做一個,就能做第二個,并不難。

5.自動化不急于一時

很多時候,數據建設工作難,其實是難在怎么去做自動化。

自動化當然好處多多。

不用手工SQL,直接系統郵件日報表、周報表、月報表;
對關鍵指標項直接監控,有問題通過各種渠道報警相關人員;
……

但是,并不是一開始就要做自動化。

運營常常說,有工具要上,沒工具靠人肉也要做。

道理是一樣的。

關鍵是,對于數據建設這件事情的重要性,公司和老大們是否意識到了,是否愿意去給資源?

如果沒意識到,以上這些都是廢話,如果意識到了,我覺得作為運營人員,學會提需求,足矣。

一個很現實的問題是,大多數老板并不真的關心數據。

我記得在某公司的時候,數據老大和我聊天說漏嘴,他說,整個公司,你訪問數據的頻率是最高的,基本上每天都在看,但是我們老板,從來不看數據。

其實,做數據的人,最怕2件事兒:

  • 做了沒人用沒人看;
  • 看了沒人反饋提問題或者提需求。

所以,為了不讓數據同學付出的心血浪費,一旦公司決心要做數據建設,那么這條路就要堅持走下去,并且,提需求的記得一定要多多去看數據。

否則,一切都是扯淡。

#專欄作家#

張亮,微信公眾號:zhangleo1983,人人都是產品經理專欄作家。知乎大V,互聯網從業者;《從零開始做運營》作者。聊產品聊運營,偶爾深度。分享一切有益有趣的內容。

本文原創發布于人人都是產品經理,未經許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 亮哥很贊!

    來自廣東 回復
  2. 太有道理,我們是創業公司,看完這個感覺有方向了!

    來自廣東 回復