數據運營：數據建設是需要講方法的
分享
評論
贊0
數據建設工作并不是一件簡單的事，在做好數據建設是需要講方法的。
之前有個讀者給亮哥留個言，但亮哥無法回答，只有沉默了，想了想，今天還是寫一篇文章吧。
讀者問：
亮哥你好，看你的書很久了，但是有一個問題困擾了我很久。在做用戶數據分析的時候，我們常用的第三方類似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件事兒：
做了沒人用沒人看；
看了沒人反饋提問題或者提需求。
所以，為了不讓數據同學付出的心血浪費，一旦公司決心要做數據建設，那么這條路就要堅持走下去，并且，提需求的記得一定要多多去看數據。
否則，一切都是扯淡。
猜你喜歡
評論(0人參與，0條評論)
發布評論
最新評論