數據分析團隊如何給自己找活干?

請教下,當業務部門沒有提出分析想法,各方面數據看板已經做得很完善的情況下。數據分析團隊如何給自己找活干,面對那麼多業務部門,如何從一個部門下手再貫穿所有部門。

ps:想要的是一套思路打法。


謝邀。

我看下問題日誌,要不題主你考慮來我們公司?保證活多得你干不完。考慮一下?

根據我的了解,題主的工作內容是偏數據工程師一點的,不過題目是問的是數據分析團隊,所以就我有限的見識,拋磚引玉討論一下數據分析團隊如何給自己找活兒干。

為方便說明,這裡以知乎為假想例子(也就是說都是我瞎掰的)。

比如說以用戶註冊過程為例,主要包括潛在用戶通過某種方式到達知乎註冊頁面(比如說搜索,或者朋友圈分享的答案、文章),開始註冊流程(郵箱註冊?電話註冊?),註冊成功之後的一系列動作,比如關注了哪些話題、是否更新個人資料,是否有進一點互動(比如說點贊或者答題)等。

1. 數據報表 (dashboard report)

題主提到「各方面數據看板已經做得很完善」,那麼可以試著從以下幾個方面入手?

a. 不同維度的完善

比如說現在報表包括了註冊整個過程的數據,那麼是否有按用戶性別、年齡等,地點(國家),使用設備(Andriod, iOS 等),來源(搜索引擎?朋友圈分享?微博分享?),註冊方法(手機號?郵箱?)等來做分類呢?

b. 數據的時間精度

我們知道微信公眾號是提供每天的數據追蹤的,如果能夠有更精細一點的數據,比如說按小時的,是否會提供更多的信息呢?以上面知乎註冊數據為例,有每天的數據當然很好,但是假設現在半夜 12 點突然因為某些原因不能通過手機號註冊了,而且只是在頁面端有這個問題。如果沒有時間精度更高的數據,而只能看每天的話,那類似這樣的問題可能就沒法發現或者需要過一兩天才能發現了。

類似的,比如知乎日報想看每天幾點推送效果更好,可以嘗試在不同的時間段推送,然後看每天的閱讀量、互動等,但是如果能夠實時看推送之後的效果,自然比看每天的數據更有說服力。

c. 數據的完善度

理論上來說數據永遠只能部分代表實際情況的,不可能把所有情況都一一記錄下來。比如說在記錄用戶註冊的過程中,是否記錄了用戶註冊失敗的情況?比如說用戶名已經存在?用戶名已經存在的情況下,是用戶忘了密碼呢?還是本來應該點登錄的,結果點成註冊導致失敗了?註冊失敗之後下一步動作是什麼?假如有這些數據,可以帶來什麼分析結果?

d. 數據的可靠性

數據並不總是 100% 可靠的,那麼如何提高這個可靠性?如果建立一個大家都可以用、都可以信任的數據系統?當然這更多是屬於數據工程師的活兒,跟數據分析有點差別。但是另一方面來說,數據分析過程中也是可以發現一些數據存在的問題,提供反饋進一步改進的。

2. 開拓性數據分析

有完善的數據報表是一件很好的事情,但是絕不能止步於此。

a. 給業務團隊提供方向

業務團隊應該有自己的想法接下來應該做什麼,或者說至少有個大致的想法,同時數據分析在這裡也能起到很重要的作用,有時候是確定哪些項目比較重要,影響力比較大,有時候是找到新的方向。

比如通過數據發現,註冊錯誤里有一部分是因為用了海外的手機號,導致無法收到確認碼,那麼就可以考慮如果解決這個問題了。還有一部分是因為用的郵箱收不到確認郵件導致註冊失敗。假設現在工程團隊資源有限,只能幹其中一個,如何確定優先順序?

再比如說數據分析發現很多文章瀏覽量來源於微信朋友圈,那麼添加通過微信登陸的功能,有什麼好處,又有什麼壞處?

b. 了解用戶

數據分析可以改進產品,很多時候可以通過分析用戶的行為來得到一些想法。比如說對比一下文章和答案的贊數和評論數會發現,有一些文章和答案的評論數/贊數非常高,說明在評論里有很多互動,但是贊同文章的人卻很少。再進一步分析可能發現,有時候是因為讀者強烈反對文章或者答案,所以評論區很熱鬧,有時候是因為大家在評論區里聊天,如此種種。那麼這些信號是否能夠用在知乎時間線的排序上?是否有必要給文章也增加「反對」的按紐?是否有必要給評論也排序而非單純的按照時間來?

c. 設定目標

跑過馬拉松的人可能都了解領跑者的重要性(我沒跑過,別問我怎麼知道的),因為有人在前面帶節奏,跟著合適的目標按照適合自己的節奏跑就可以了,不至太快跟不上,也不至於太慢而沒有發揮自己的潛力。

數據分析也可以起到類似的作用,給團隊設定一個合適的目標,而不是腦袋一拍,能不能完成天知道的。有時候目標設得太高,團隊拼死拼活也完不成,有時候又目標太低,不能發揮團隊的潛力。

3. 數據基礎架構 (data infrastructure)

這方面可能也更多的是數據工程師的職責,不過數據分析團隊也是可以在其中發揮一定的作用的。

a. 方便團隊做測試

比如說是否有系統能讓工程師們方便的做測試,不需要專門的人來做 A/B 測試的數據分析?

b. 方便團隊使用數據

比如說產品經理要看這周和上周的對比,一些常用的數據是否可以直接有報表呈現。如果有某個特定的方面需要進一點查看的,是否有好用的 UI 點幾下就可以?如果產品出現什麼問題(比如說註冊頁面掛了),是否有系統能夠及時報警,並且能夠快速查明原因?

c. 自動化分析

比如說寫個程序把一些常用的分析過程給自動化了?

這個回答下的思路就很好:

工作被效率更高的機器搶了是什麼體驗? - 知乎用戶的回答 - 知乎

暫時就想到這些,不過我還是想不通,俗話說得好,產品經理動動嘴,數據分析跑斷腿(開玩笑的,產品經理不要打我)。

貴司的數據分析團隊怎麼會輕鬆沒活兒干呢。。。要不來我司試試看?


謝邀。

看到這個問題,我想起上個月我們 GrowingIO 在上海舉辦的數據驅動增長大會,其中有一位演講嘉賓是途家網的 BI 總監。他在大會上,非常詳細地講了數據團隊的搭建過程以及每個部門所做的事情。我們的內容團隊將這個演講編輯整理成了一篇文章,在這裡貼出來,希望對你有幫助。

更多優質文章,也可以前往 GrowingIO 官方博客 閱讀。

途家網 BI 總監 | 數據分析團隊的搭建和思考

本文作者:秦涌,途家網 BI 總監

本文根據「 2017 GrowingIO 據驅動增長大會」演講內容整理編輯,首發於 GrowingIO 微信公眾平台及博客,授權轉載。

大家早上好,非常高興能來參加這次上海站的數據驅動增長大會。

以前說到數據驅動業務增長,我們第一個想到的可能是數據分析的方法。但就目前來看,數據驅動業務的增長已經成為一個不僅僅是分析方法和模型,而是包括了數據人才培養、數據架構的設計,甚至整個公司組織架構設計的企業治理問題。所以今天我想從途家數據團隊的發展、部門的構成及職責這兩個方面去跟大家分享一下途家網的一些實踐。

如果對一個公司的業務沒有足夠的了解,是沒有辦法去做分析的,今天演講中闡述的不管是組織架構的設計還是分析案例,都是緊緊圍繞途家網的商業模型展開,所以我先大概介紹一下途家的業務:途家網是一家已經進入「獨角獸」俱樂部的全球公寓民宿預訂平台,於2011年12月1日正式上線。我們提供服務公寓、度假公寓、別墅、客棧、民宿等各類度假租賃產品的在線搜索、查詢和交易服務。

Part 1 | 數據分析團隊發展的5個階段

我們途家網成立五年以來,整個數據團隊的成長也是經歷了五個階段。

第一階段:從 2011 年底途家網正式上線到 2013 年 2 月,這個階段我們沒有專業的數據分析師。

在公司剛剛成立的階段,沒有招專業數據分析師的必要,但是這個時候仍然需要做數據分析。途家網的創始人具備深厚的計算機背景,所以這個階段基本上是創始人自己在做分析。通過數據分析,創始人對公司的業務發展能有很清晰的認識,非常有利於去快速做一些重要的決策。

第二階段:從 2013 年 2 月到 2014 年 2 月,我們有了專職的數據分析人員。

這個時候創始人已經沒有足夠的時間去看大量的數據了,所以我們有了第一個專職的數據分析人員。全公司第一個專職的數據分析人員非常關鍵,因為這個人在很大程度上決定了整個公司之後在數據方面的如何發展。

第三階段:從 2014 年 2 月到 2015 年 4 月,我們成立了專門的BI團隊。

這個時候,途家網基本上進入了一個快速發展的階段,業務部門也非常的多。在這個階段我們除了基礎的數據分析,會把更多的精力放在原始數據的收集、數據工具的優化上面。

第四階段:從 2015 年 4 月到 2017 年 1 月,這是一個業務井噴的階段。

這時 BI 部門的一個最基礎的責任就是,務必讓每一個業務的負責方及時地看到自己的數據,進而及時發現問題。所以這個時候我們會做一些數據可視化的工作。

第五階段:從 2017 年 1 月份到現在,我們開始做一些自助式的分析。

因為這個時候我們發現,整個 BI 團隊 12 個人,需要去支撐整個公司上千人的團隊已經很困難。我們只能把數據分析的職能下放,做到去中心化。也就是 BI 團隊負責制定標準的數據,讓業務的人去自己去做分析。

總的來說,數據團隊發展路線,其實和業務增長的路線是一致的。這個過程我們用了 5 年多的時間,這個發展速度和途家網整個商業模式是相關的。有可能在交易頻次更高的一個公司里,完成這些步驟只需要一年多的時間,但是不論時間長短,這5個步驟是大部分公司都會經歷的。

Part 2 | BI 團隊組成

BI 團隊有兩個比較重要的責任,第一個是務必能夠保證用數據講清楚每一個業務的狀況;第二個責任是要輔助公司做決策,用數據去告訴大家未來怎麼樣做更有效率,如何去達到公司最大的目標。

為了承擔這兩個責任,我們成立了四個團隊。商業分析團隊,BI報表團隊,數據倉庫團隊,和市場競爭分析團隊。

一、商業分析團隊

這個團隊的兩個非常重要的職能,一個是分析一些非固定的專項問題;另一個是當企業大了之後,負責一些分析工具的培訓。

接下來我會用3個實踐案例去講這個部門具體做的事情。

案例1,首位數據分析人員的培養

在初創的企業做數據分析是一件非常讓人頭疼的事情,大家請看圖片就能說明這個崗位的繁忙程度,負責數據分析的這個人基本什麼都得干。

更重要的是,他會碰到很多很多的問題:

  1. 初創企業沒有標準的數據,也沒有足夠多的數據;
  2. 業務與業務之間的數據邏輯關係需要大量時間梳理;
  3. 沒有足夠的技術人員幫忙寫代碼;
  4. 不熟悉業務的情況下很難用簡短的語言概括分析結果。

這時候公司可能會考慮選擇去招一個大公司背景的專業的數據分析師,但是實際情況是,在發展已經成熟的公司里,一個數據分析師背後是有成千上百人的數據產品和數據技術團隊支撐的,成熟的分析師在商業分析上更擅長,但在整合數據的生產流程上未必非常清楚。所以我覺得,初創型的公司除了招聘一名成熟的數據分析師,還有更高效率的解決方案。

我們途家網的解決方案是,讓一個熟悉業務的老員工轉崗去做數據分析;或者說讓一個熟悉技術,又懂業務的人去轉崗,避免溝通上的低效。同時使用成熟的數據分析工具,避免在數據質量、以及重複性工作上浪費大量的時間精力。

通過這樣的方式,這個人會很快地把整個數據分析的框架搭建起來。最後你會發現,在公司成立四年到五年之後,這個人就是整個公司通過數據去驅動業務增長的靈魂。

案例 2,業務和財務的互動

一個企業無法脫離的目標是盈利。現在國內的市場競爭日趨激烈,大家都在拚命去搶市場,但是在這個過程中可能會階段性忽略盈利這個指標。途家網一直非常注重財務結合業務的分析,我們的業務分析人員和財務分析人員,每周都會固定地去看一下,業務上的動作在財務報表上的表現。這對管理層來說是一件非常讓人放心的事,因為能非常清楚地知道資金和人的精力花在了什麼地方,有什麼樣的效果。

為什麼要做這件事情?因為通常來講,從業務前端到最後財務數字的整個鏈條里,業務分析人員很難掌握財務收入的確認規則,財務人員又需要更多時間去學習掌握不停變化的業務邏輯。通過財務分析人員和業務分析人員深度的互補和互動,能夠做到驅動一個企業儘快地盈利。至少這個過程會讓我們知道,盈利的來源是什麼,哪怕目前是虧損,你也能知道為什麼是虧的,以及怎麼能做到止損。

案例3,大膽假設,小心求證的分析思維

以上兩個案例是比較宏觀一些的商業分析人員需要解決的問題,以下這個案例則是日常工作中經常發生的:當業務人員來找分析師要一個數據的時候,負責任的數據分析師需要幫業務人員梳理分析的邏輯。

比如業務人員問你要一個APP訂單變化的數據,但其實他想看的東西,或者應該看的東西,遠不止這些。

這時候再回過頭去問他,你到底要幹什麼?這個時候你會發現,有可能是老闆發現昨天的訂單比前天的訂單突然增長了50%,超出了他的預期,但是他又不知道為什麼發生了這些增長。業務人員在做分析的時候,經常提出來的是一個點。但是對於一個數據分析師來說,你需要幫業務人員具體理這些分析的框架,最終找到數據變化的原因。

不管是你在初創型的公司還是中型公司,在做數據分析的時候一定不要忘記這三個步驟。

1、定義問題

首先你想清楚,你在數據分析的時候你到底要分析什麼題目?

2、大膽假設

思考出現這個數據變化所有可能的原因。

3、小心求證

在小心求證完之後,才能得到比較客觀的結論。

對於比較初級的分析師來講,可能適應這個思維會花一定的時間;但是一個商業敏感度非常高的分析師,可能只需要幾分鐘就能夠完成以上4個步驟並給出客觀的分析結論。

接下來我們從一個具體的案例去驗證以上的分析邏輯:假設今天我們的訂單突然增長50%,為什麼?

我們可以通過多維度分析的方式去考察,第一個是城市的維度,第二個是渠道維度。

第一個場景,從城市的維度上看,每個城市大概增長了5%,都是等比的增長。從渠道上看,APP增長了80%左右,但是其它的渠道並沒有帶來這麼多的增長。所以這個時候我們可以得出一個結論,這種數據現象有可能是我們在APP 端投放的啟動量導致的增長。

第二個場景,北京這個城市增長的非常多,但是其他城市基本上沒什麼增長;APP也同樣是80%左右的增長。結合這兩個圖,我們就會得出,有可能是一個北京的 KA 用戶,在 APP 下了訂單導致的增長。

這兩個數據的圖形看起來非常的相近,但是得出來的結論很不一樣,最後導致的企業的決策也會很不一樣。

二、BI 報表團隊

BI 報表團隊的 3 個重要職責是,將業務方常規需要查看的數據沉澱為 BI 報表;幫助業務人員實現可視化的自助式數據分析;分析師自己沉澱一些主動分析的數據結果給大家看。

接下來我還是用 3 個具體的實踐案例去講這個團隊在做的事情。

案例 1,可視化

這個報表說明的是,我們每周在每一個渠道上面的表現。當然我們做的實際報表會比這個更長一些,會看到每一個渠道吸引過來的註冊,以及這些註冊用戶在未來的一段時間內的留存率以及價值轉化。

這個報表在每一個公司都非常常見,但是它的核心的目的是什麼呢?是讓我們的業務人員清楚地知道投放的效果,以此來決定未來的投放資源如何去調整,進而提升投放的 ROI。這個目的需要通過報表的製作以及一些額外的可視化來實現,報表負責展示數據,可視化負責讓業務人員花更少的時間去獲取數據之上的關鍵信息:假設我們根據過去的業務情況得出,ROI 低於 10 是不能接受的,做一些簡單的可視化工作就能夠突顯這個信息。

案例 2,可視化基礎上的自助式分析

在業務線和業務部門越來越多之後,我們希望業務人員能夠自主地在報表上完成一些初步的分析。所以這個 BI 報表實際上就是在可視化的基礎上,做了更多的自助設計分析。讓業務人員能夠通過一些拖拉拽的鑽取操作,快速的看到問題的所在,找到問題的原因。

這個報表其實是可以支持下鑽的,如果某個渠道的 ROI 過低,可以點擊下鑽到每個訂單的其他屬性,例如什麼會員級別、什麼落地頁、什麼優惠措施、買的產品是哪些,提供產品的商戶的服務質量怎麼樣。這個報表對我們分析師團隊來說,也大幅度地提升了工作效率。現在我們可以在 10分鐘內知道整個公司一周的業務變化。

案例 3,商業分析師的報表沉澱

傳統的報表製作流程是,需求方把需求提出來,然後工程師來負責把報表做出來。但是我們會更強調商業分析師的主動性,這個主動性是什麼?

第一個主動性的要求是因為商業分析師在看過海量的數據之後需要產生自己的一些想法。從不同的維度上去分析數據,可能會對業務有額外的幫助。

第二個是因為,對於一個業務人員來講,每天只看自己業務範圍內的數據即可,但是跨業務之間的數據產生的價值大部分時候是被忽略的。所以商業分析師需要主動的去思考跨業務之間的邏輯,然後固化在報表上面,給業務人員提供更多的價值。

下面我提供一個途家網自己的案例:

我們是一個在三亞起家的住宿型公司。我們通過數據會發現,在夏天的時候是西南地區的人去三亞比較多;而冬天東北地區的用戶會大量的去三亞過冬。因為冬天東北非常冷,有很多老年人在這樣的天氣里會很不舒服。我們通過用戶季節性的分析,發現一些規律。這樣的規律對線上線下的活動投放非常有幫助,尤其是在冬天投放線下戶外廣告的時候,我們會把更多的精力放在北方區域。

我們還做了其他的實踐去體現數據分析的價值。比如分析師會去挖掘,這個商圈到底是 300 塊錢的房子更好賣,還是 400 塊錢的房子更好賣?懷柔區可能兩室一廳的房子更好賣,但 CBD 就有可能是一室一廳的房子更好賣,把這些分析的結果去指導銷售人員去獲取房源,一個量化的結果就是新簽房屋的動銷率提升了 20 個百分點。

目前我們已經沉澱了 300 多個報表,有84%的報表在一周之內被打開過,這些報表平均每天被100多個人訪問,每天大概被訪問 300 多次。這樣的做法會讓 BI 團隊的人感到自己非常有價值,而且這麼多的報表經常被打開,說明整個公司的數據價值沒有被浪費掉,也說明數據驅動業務增長的理念是深入到公司大部分的人心裡的。

三、數據倉庫團隊

在更大的公司,或者說在 BAT ,數據倉庫應該是被放在技術部,而不是 BI 部門。我們為什麼要放在 BI 部門呢?因為這樣能讓分析師知道每一個指標,在資料庫里是怎麼被算出來的。數據的標準性和嚴謹性會有很大程度上的提升。

數據倉庫的主要 4 個職能

1、負責整個原始數據的收集和清洗

對任何一個初創型的公司來講,這個工作都是要花費大量人力的,所以我們選擇使用 GrowingIO 的產品,可以獲取實時全量的用戶行為數據。

2、負責數據報表的抽取

因為公司的數據結構越來越複雜,數據報表越來越多。讓數據倉庫團隊做一些數據指標的抽取工作,就可以讓分析師直接去分析已經抽取過的統計表,大量地節省分析師在原始代碼上的精力。

3、負責各個系統之間的數據規整

各個系統都會展示一些數據,但是每個系統展示的數據可能都不太一樣。為了解決這個問題,我們會讓數據倉庫的工程師去做統一數據的輸出,務必保證每一個人在每一個平台上看到的數據都是一致的。

4、負責一部分分析的職能

以上 3 個最基礎的工作完成之後,數據倉庫的人員也會承擔一些分析的職能。

四、市場競爭分析團隊

整個互聯網公司市場競爭會越來越激烈,涉及到的是企業內部每個細節的競爭。我們在BI 團隊設置了一個這樣的職能,是因為BI團隊對企業內部各個環節的數據都非常的清楚,此時他在研究外部競爭對手的時候,就會非常透徹。而整個企業內部的數據和企業外部的信息,才能組成一個企業數據完整的圖譜,這樣才能在一個完整的生態中找到企業增長之道。

Part 3 | 經驗和思考

一、6 個經驗

以上的分析零散地介紹了數據團隊日常的一些案例,以及為什麼設置這些職能、這些職能在驅動業務增長的過程中起到什麼作用。總結一下,有 6 個經驗:

  1. 分析師一定要足夠地了解業務。對於一個分析師來講,商業敏感度是第一位的。
  2. 分析師一定要主動地梳理業務問題框架,而不是被動地接受業務方提上來的每一個小問題。
  3. BI 報表團隊要保證每個人都有數據可看,而且務必要通過一些可視化的手段提升業務人員閱讀數據的效率,讓他們能迅速地提取關鍵的信息。
  4. 在企業從小到大的過程中,推動一些自助式的分析,因為自助式的分析能夠解決分析師的瓶頸問題。
  5. 善用工具。尤其是企業成立初期,大量的數據沒有規則,也沒有經過任何整理,工具能夠很大程度上提升分析的效率。
  6. 數據分析視野問題,內部的數據一定要分析的非常透徹。但是每一個分析師的眼界不僅僅如此,更要有整個行業的宏觀數據,這樣才能找到企業的增長之道。

以上這些經驗都僅僅局限於途家網。每一個公司的行業特徵、人才配置、碰到的問題都不一樣,所以經驗的適用程度也不一樣,除了這 6 個經驗,還有一些通用的思考是想和各位數據從業人員,尤其是管理人員交流的。

二、6 個思考

1、我們對數據的要求是講清楚業務,還是通過數據變現?

這其實是一個數據從業者或者說整個公司的數據負責人應該去想的一個很大的問題。途家網的商業模型決定了目前對數據的應用是這樣的,但是放在別的公司,我們對數據的要求又是什麼?

2、在什麼階段應該成立 BI 團隊?

途家網是在運營兩到三年後成立了 BI 團隊。但是對於交易頻次更高的公司,有可能半年左右就需要快速地成立 BI 團隊,這樣整個公司的數據才夠紮實。

3、數據分析師是不是有足夠的權威?

分析師提出的意見在業務改進,或者驅動業務成長過程中到底能起到多大的作用,這也是我們每一個數據管理者應該去思考的問題。

4、在特定的階段,是研發一個工具,還是採買一個工具?

這是一個效率提升的問題,要綜合考慮公司目前的數據、人員等等情況。

5、業務方是否會主動看數據?

BI 團隊會把數據梳理清楚,但是我們有沒有做好日常的驅動工作,讓每一個業務人員去看這些數據?

6、集中式分析還是自助式分析?

集中式分析的好處是,一個人能夠把公司的數據情況說得非常的清楚;但在業務發生井噴的情況下,12 個人,或者 20 個人,甚至 50 個人的數據團隊,也是沒辦法應付公司所有的業務分析需求的。所以在不同的階段,需要推動不同的分析方式。

以上就是我的演講,謝謝各位的聆聽。

GrowingIO 是新一代基於用戶行為的數據分析產品,數據採集無需埋點,用戶行為數據分析更專業。登陸 GrowingIO 官網立即註冊免費試用,或者關注微信公眾號(ID:GrowingIO)GrowingIO 官方博客獲取更多數據分析乾貨。


@鄒昕大牛的回答非常好,我再補充一些我的看法。

一個成熟的數據分析團隊的工作應該是從描述性分析(Descriptive Analysis)開始預測性分析(Prediction Analysis),再到指導性分析(Prescriptive Analysis)的過程,這三個階段是相互影響與相互促進的關係。

描述性分析(Descriptive Analysis)是最簡單也是最基礎的分析,其目的是總結過去。通常情況下,人是很難從原始數據中直接獲取信息,因此,需要通過描述性分析,將大塊的原始數據清洗、提煉、總結成小塊的信息,用數字、圖表等形式展示出來。從題主描述來看,這是你們團隊目前主要的工作內容。

預測性分析(Prediction Analysis)則是利用機器學習、數據挖掘、統計等方法利用歷史數據對未來進行預測。指導性分析(Prescriptive Analysis)是進階版的預測性分析,在指導性分析中,不僅僅要對未來進行預測,更重要的是能夠對預測結果進行解釋,分析其背後的緣由,並對業務決策提供指導,分析每種決策可能產生的影響,這是數據驅動型公司的核心之一。

題主的團隊看起來在預測性分析及指導性分析上做的工作很少,是不是可以考慮下一步做點這個?

另一個很重要的方向是基礎設施建設,主要包括這麼幾個方面:

  • 數據建設。數據的質量決定了分析的上限,因此,數據的建設應該是貫穿始終的。數據的建設包含了(1)提升數據的準確度、可靠度;(2)增加數據的維度,引入更多的數據;(3)降低數據的粒度,讓數據的細化程度更高。
  • 分析流程建設。通常情況下,一個數據分析項目的流程是:數據收集 --&> 數據清理--&> 特徵工程--&> 數據建模--&> 模型評估 --&> 模型變現(提供決策支持或是進入產品)。一個優秀的數據分析團隊應該將上述流程規範化、自動化。
  • 產品化建設。如果分析的結果需要進入產品,那麼與工程團隊進行銜接,模型產品的測試都是需要解決的問題。如果分析的結果是提供決策支持,那麼如何將分析結果更好、更清晰、更易懂的展示給其他決策層及其他團隊就是急需解決的事情了


作為一個愛YY的人,經常幻想自己如果處在某個崗位如何做才能更出色至脫穎而出,也時常咸吃蘿蔔淡操心得給周圍的小夥伴支招做怎麼樣的項目產生更大影響力。而又因為偏愛數據分析,所以在這個問題相關方面的假設性思考比較多,因此下面列舉一下我平時YY的結果:把自己假設成為一個不受待見的數據分析師,經常像機器貓一樣拿出新東西給到產品技術團隊,希望博君一笑。

其實也不算YY,當初做諮詢的時候,有一個項目是幫助某國際手機品牌在中國做新渠道模式的試點及鋪開。因為我們團隊沒有任何實操經驗,一開始的過程就是幫人跑跑數據和寫寫報告,頗不受待見。後來因為我搞出了一套周報自動生成器,才贏得客戶團隊的超級認可,順利過關。

回歸正題,改變一個人的習慣是很難的,而改變認知比改變習慣更要難上一個或幾個數量級。因此可以把我想做的事情分為如下幾類,從易到難。

滿足缺失需求而不改變習慣,提升效率

這裡有很多例子,數據工程師或者分析師一旦做出來之後,業務方完全沒有拒絕的理由。比如大公司往往因為業務眾多而BI系統分散,這時候為團隊一個整合的BI平台,絕對是加分項。同時大部分的BI平台都是基於PC的,這時候為團隊開發一個查看BI的App或者小程序或者兼顧移動端閱讀體驗的定時郵件(要知道這個年代,許多高層都不用PC了),絕對是人見人愛。另外,業務團隊在工作中有著各種各樣的手動導數據和分析數據的流程,如果開發出一套完整的自動化程序,肯定是花見花開。

上述的例子都有一個共同的特點,數據團隊為業務團隊提供的服務或者產品,完全沒有改變業務團隊的工作流,無非是補足其缺失的需求,讓其查看數據、清理數據和分析數據大為簡單方便,所以接受起來人畜無害而毫無難度。最重要的是,對業務團隊沒有替代關係,同時也不指責業務團隊之前做的不好。

改變工作流程,提升效率

業務人員、運維人員、運營人員及產品人員平時會花費大量時間閱讀數據、理解數據、建立建設、證明證偽假設和形成結論。數據工程師或者分析師完全可以在這些方面為業務方提供增值和提升其效率。

找規律找異常。這其中,觀察數據趨勢以及尋找異常,是非常重要的部分。傳統的做法:人腦形成經驗,肉眼觀察和肉腦判斷;或者設定閾值,超過一定範圍自動報警(常見於運維);或者簡單的四則運算判斷,根據各種環比、同比或者平滑移動平均等等。一句話總結就是low爆了。然而數據分析團隊其實是應該可以利用傅里葉分析將周期性的變動和異動大部分區隔出來的,讓這種分析和查找異常的過程升級,更精準的同時也提升效率。

做分類提方案。業務團隊時常需要針對業務情況做各種分類,然後對症下藥提供解決方案。這在銷售團隊里尤其常見,尤其是互聯網公司的銷售業務,每個城市的產出是銷售業績,有各種中間的過程變數:銷售數量、銷售人效、銷售出勤率及成單率、銷售流失率、當地流量(UV)數量、流量(UV)質量、商戶續費率、新增商戶數等等。在傳統操作中,都是依靠運營人員或者BI人員根據人肉經驗或者常用而簡單的分析框架,對各城市的銷售情況進行分類,找問題出方案。其實數據分析人員完全可以利用更高階的機器學習(當然初始數據輸入有賴於運營和銷售們的存量知識),針對業務情況進行更多維度和更實時的分類,然後將業務情況與方案進行匹配。較之傳統方案,以上方案存在如下優勢:高維會創造更精細的分類,有可能捕捉到以前被忽略的業務問題;高頻(機器的高效率按天分析數據)會創造更實時的反饋,

AI寫報告。BI部門每月或者每周都要撰寫報告發給管理層閱讀,因為管理層是不怎麼看原始數據或者數據面板的,報告的形式多為PPT。然而定期的報告其實是非常模版化的,即使分析框架有迭代也是蝸牛的速度,但BI人員仍要花費大量的時間更新數據、圖表和結論,然而這個工作完全是可以開發一套AI系統來自動完成的。在這個AI橫行到可以幫著體育記者和財經記者寫稿的年代,這個想法並不瘋狂。

以上幾個想法都是在略微改變業務人員工作流程的情況下,為其帶來更高效和更精準的結果,可以說是給業務人員賦能,簡化其重複性勞動,幫助其成功。但一方面因為稍微替代了其人腦的價值,招當事人反感;另一方面在初期的磨合過程中,機器肯定有不少犯錯的機會招人類嫌棄,所以初期的磨合階段可能會略有阻力。

提供新思路,看到新世界

數據分析人員還可以利用新技術、新演算法或者新數據,幫助業務方找到剖析問題的新角度並證明其行之有效,也會對業務部門大有幫助,只不過因為其需要改變傳統的思維習慣,更需要普及教育甚至是耐心。比如之前寫過的幾篇關於投資圈的文章(知乎專欄和知乎專欄)就試圖利用SDA(Social Network Analysis)的方式來分析各個基金的影響力以及它們之間的關係。

其實這也是寫作數據冰山這個專欄的初衷,不在於拉粉,而在於不斷找到新思路來分析生活和商業現象,希望稱為數據分析師之友和開腦洞的地方。

…更多文章請到數據冰山 - 知乎專欄

…更多回答請看何明科


把自己下沉到業務部門三個月,和業務小夥伴一起做做報表、搞搞活動、打打電話、背背KPI就好了呀。想要貫穿部門,就把所有部門的KPI都算自己頭上嘛。

什麼?你們每天做報表要兩個小時?因為依舊要加工數據?

什麼?你們90%的數據工作都是用Excel完成的?

什麼?你們每天打客戶電話都是盲打?沒有篩選優質客戶的依據?

什麼?你們只能獲得天維度的數據,做的運營效果得T+1後才能看到?

什麼?你們推廣的活動連效果都不監控?

什麼?你們選擇的那些文案、創意,其實自己也不知道靠譜與否?

什麼?產品怎麼又改功能了?這個功能根本沒什麼留存啊。

業務部門和數據部門不在同一個維度的,很多數據部門覺得很正常的東西,業務部門並無感知。

也許業務部門生來就覺得拎出一堆Excel做vlookup然後數據透視很正常,但是在數據部門眼中,這是可以用ETL+DW+BI自動化完成的工作。

也許業務部門覺得客戶本來就應該一個個電話銷售啊,但是在數據部門眼中,應該根據歷史數據建模預測響應。

也許業務部門認為文案一直就是這樣寫的啊,還能玩出什麼花,但是在數據部門眼中,應該統計點擊率打開率,並且AB測試不同文案。

數據不太懂業務,業務不太懂數據,這也是很多團隊的弊病吧。試問,你會向一個不了解其能力的人尋求幫助么?反過來,數據部門不了解業務的場景,也就不會做各種優化和分析了。

可以按以下幾個建議試試看:

1.培訓業務部門,告訴他們數據驅動提升效果的邊界;

2.拎出一兩個可以明顯優化的點,落地執行;

3.只要項目成功兩三次,數據和業務間會建立信任和默契了。信任感很重要。很多業務部門的領導,尋求數據部門出一兩個分析,發現結果也就那麼回事,以後就不太會找數據部門了。

我之前同時帶過業務和數據兩個小團隊,想要讓兩者融合,坐同一張辦公桌是一個不錯的想法,哈哈。理想的情況,不是數據部門追著業務要活,或者業務追著要數據,而是雙方間的默契配合,這就要靠不斷的磨合,互相了解且信任了。


簡要概括一下我們組的經驗。按大致的時間順序分為下面幾個部分:

第一部分,臨時需求。

  1. 初始階段,處理各部門踢過來的臨時需求,並以各種形式的報表反饋回去。
  2. 效率提升期,通過數據分析庫的建設、自動化及半自動化開發,提升數據獲取效率;通過數據需求規範建設,提升業務組數據意識和需求質量,提升溝通效率;通過站會+看板方式加強協作,提升全流程效率。關鍵指標是響應速度,如90%臨時需求在24小時內完成。
  3. 穩定期,臨時需求量短期隨業務波動,長期穩定。例如我們穩定期是每季度處理300左右的臨時需求,每人每月4.5-5.5個臨時需求。開始出現主動型臨時需求,即數據組主動提出的臨時需求。
  4. 衰減期,隨數據自動化程度變高,業務逐漸穩定,商業模式逐漸清晰,臨時需求開始衰減,但永遠不會消失。

臨時需求是了解業務,收集反饋,優化數據產品的最佳途徑。一般來說,臨時需求越做越少,往往是沒有建立有效的反饋機制,只關注了完成度,沒有關注是否解決了業務組問題。可以通過看板中增加「反饋」泳道來解決,一般有30%左右的臨時需求,會在反饋階段產生新的1-3個臨時需求。

第二部分,自動化報表。

  1. 架構階段,搭建自動化報表的基本框架,包括數據字典、數據管道、Email、Dashboard、數據中間層等基礎建設。
  2. 報表增長期,針對周期性查看的報表建立自動化展示。此階段主要看報表覆蓋率,一般來說不同的職能不同業務方向,都會有3-5支報表。報表數量也能反映此階段的發展情況。
  3. 分析系統建設,針對分析型需求,往往是各個維度細分查看,每次查看的維度都有差異,不適合做自動報表,適合建模之後做成分析系統,業務組成員或分析師,可以通過不同維度不同變數的篩選來完成分析需求。關鍵指標是分析系統訪問量。
  4. 報表整合期。接入一切可能的數據源,例如:接入worktile數據可以看團隊開發節奏、接入sonar數據可以監控代碼質量、接入jira可以監控bug數據、接入內網知識庫可以看知識沉澱速度和個人影響力、接入後台錄入數據可以極大補充數據靈活性。
  5. 報表設計期。用產品思想重新設計報表,定義角色、場景、需求,精簡報表內容,定義展現設計規範並美化,下線無用報表,迭代高頻報表,將自動化報表平台當作創業項目來建設,持續提升人均訪問量和訪問頻次。

自動化報表可以在臨時需求的效率提升期啟動,如果自建分析系統困難,可以考慮第三方分析平台,盡量選定製化程度高的,數據整合容易的,新興的幾家分析平台。報表設計需要招聘具有產品思維的人,甚至就是產品經理。

第三部分,數據建模。

  1. 讓事與事之間具有數據上的可比性。這是數據驅動和增長實驗的基礎了,否則每次運營活動目標都不一樣,又沒法比,增長也就無從談起。評估指標是模型覆蓋度,我們的大致順序為產品功能建模、產品迭代建模、運營日常工作建模、運營活動建模、內容發布建模、傳播建模、技術迭代管理建模、技術代碼質量建模、技術響應速度建模、技術穩定性建模。
  2. 投入、產出關聯。建立成本意識,在評估效果之外還需要評估成本。不是說拉新5000人的活動就比1000人的好,不是優化80%載入速度的技術改進就比20%載入速度好,一旦建立成本意識,數據驅動才算起步,吵架也有了客觀依據。
  3. 工作與核心指標關聯。要從商業模式的核心指標,逐漸分解到各個工作中去。針對工作中為核心指標貢獻的項目,建立從局部指標到核心指標的關聯關係,確定相關度,可大致評估貢獻度,並讓工作價值可評估。

建模最考驗的是對業務的理解、抽象分類能力,還考驗如何權衡利弊。可以說各家公司最終建模都不一樣。適合在第二部分第3階段啟動。

第四部分,分析報告。

  1. 初始階段,定義分析報告類型、格式,定義什麼才叫Insight,通過反覆迭代打磨,做出第一份理想的分析報告。
  2. 穩定產出期,分析師可持續產出分析報告,並且分析報告被業務組頻繁引用。
  3. 數據探索期,主動發掘數據價值,為業務中遇到的Why和How的問題提供數據支持、建議。

分析報告適合跟數據建模同步啟動,數據建模之前很難寫出有價值的分析報告。Insight決定了一份分析報告的價值,目前還未找到有效的複製模式,只能多練。

第五部分,數學建模。

  1. 預測問題建模,最早可以從自動化的數據監控切入,根據預測數據正常值設定異常區間。後續逐漸會用到各種回歸模型,為管理計劃的定義和分解、產品決策、渠道監控、技術預警等提供數學模型。
  2. 歸因問題建模,針對影響核心數據的變數,找出相關度,計算權重係數。為各種開放式問題提供原因解答。

一旦第四部分,即分析報告進入穩定產出期,就逐漸會碰到數學建模的問題。需要招聘具有一定數學背景的成員加入。

第六部分,沒了,再往後不知道了,還沒發展到後面的階段。


分App端和PC端兩種。

一、App端數據分析實操指南:

介紹如何使用GA工具埋點功能,提升App留存率

(一)點擊內容

用戶閱讀文章,比如用類似今日頭條的一個APP,首先「點擊內容」是第一個埋點,我們給用戶提供的內容,如果他一個都不看,那也白搭,這是轉化的第一步,也是最重要的一個。

(二)分享

分享也十分重要,分享意味著拉新。我們做過計算,如果你的內容比較吸引人,每一次分享大概能帶來10到20次的點擊,通常來說有可能展示量是上百的。這個價值非常大,所以分享也是一個很重要的埋點。

這是一個真實的的案例,我曾經為一個新聞App做數據分析,發現他們的新聞分享出去之後點擊率很高,是獲取新用戶的好辦法。那麼如何提升分享率呢?當時我們想到建立一個叫做「轉瘋了」的頻道,裡面專門放熱門轉發的內容。開發完成上線之後,我們利用GA的高級細分功能進行了數據分析。

帶有「轉瘋了」頻道的新版本App比舊版本分享率高,並且在新版本里,進入過該頻道的用戶分享率高於沒進過該頻道的。

點擊、分享(還包括H5分享到朋友圈)的埋點數據都是給運營看的,運營會知道哪種類型的內容熱門用戶願意點擊,進而多做類似的內容,提升點擊率和分享率。

(三)搜索

搜索是能最直接表達用戶需求的。搜索有兩種情況,一種是搜完了有結果,那就看用戶願意點什麼樣的內容;還有是搜索沒有結果,這個通常都會單拿出來做一張報告,比如哪一天突然有一個新詞出來了,在我們App上沒有搜索出結果,那就得馬上去補充這個內容,搜索也是一個用戶需求的風向標。

(四)下拉刷新

下拉刷新的用戶習慣應該是今日頭條培養出來的,每下拉一下,就推薦一些偏好的內容。

為什麼要統計這個?用戶每次下拉刷新都意味著一次推薦內容的展示,下拉刷新之後緊接著有多大的概率用戶點擊了內容,能體現出推薦演算法的優劣,這就和上頭埋點那個點擊內容連上了。

這是兩個行為之間的比較,一百次下拉刷新只有三次的閱讀行為,那顯然這個轉化率很差。如果一百次下拉刷新能有80次內容點擊那轉化率就很好。推薦演算法做的是不斷地提升下拉之後的點擊率。

(五)載入下一頁

PC時代大家是點下一頁,現在都是下拉載入下一頁,下拉一次載入20條,看完之後再繼續往下拉,不斷地重複這樣做,它同時也體現了用戶能接受的信息條數。比如一個用戶載入了三次,那就是載入出了60條內容,再加上它本身這一頁的20條,可能他就掃過了80條內容。

做這個埋點的意義在於可以指導運營每天更新多少內容合適。如果運營每天更新兩百條,但絕大部分用戶在一百條的時候就止步了,那剩下一百條就是浪費。

(六)推送

推送是個很重要提升日活的手段。假設公司的編輯習慣在每天三個時間點做推送,突然有天數據分析負責人看見前一天日活有明顯的降低,於是按小時對比日活,發現只有三個推送的時間點日活降低了,那顯然是推送出了問題。

推送很重要,它是提升日活一個特別有效的手段。但是我們通過GA的高級細分發現,戶時常打開推送直接看完一篇文章就走了,也就是說通過推送開啟App的用戶粘度明顯低於普通用戶。我們當然不希望這樣的人很多,所以我們會想辦法在這個推送打開的這一頁里去增加一些延伸閱讀,提升推送開啟用戶的停留時長。

(七)意見反饋

目前意見反饋有不少第三方的解決方案,但是我為什麼會堅持用GA也發一份數據過來,目的是為了把個人高級細分出來。通過GA可以查看任何一個反饋用戶的手機型號、手機系統版本等。之後找和他一樣或差不多的機器,看看會不會出現他反饋的那個問題,這樣就很容易定位他的問題。

(八)報錯

最後一個事件是報錯。報錯跟反饋有點接近,但是遇到錯誤還能反饋的人畢竟是少數,App程序上知道什麼地方出了什麼錯誤,通過系統進行信息收集也是可以細分出來這些報錯的用戶。

通常大家上手進行App數據埋點時不知道統計什麼,那我剛才說的這八個就是最通用的,按照優先順序排列。對於初創或中小企業,有這些數據就已經能把分析工作做到至少70分了。

二、PC端數據分析指標方法論

數據分析通用指標有三類,每類我可以再推薦三個最常用的指標。

第一類指標與流量數量相關。用戶數、訪問次數、交互數對流量的影響最大,它們是存在層級關係的,同一個人會貢獻多次來訪,同一個來訪也會貢獻多次交互點擊。

第二類指標與流量質量相關。一是參與深度,也就是平均訪問頁數,即用戶每次進入網站訪問了多少不同的內容。二是跳出率,用戶點擊一個廣告進入網站後什麼都沒有做的情況就叫做跳出,跳出率考量的是用戶是否對你感興趣,用跳出率做流量評估也比較直接。三是新用戶佔比,就是說你網站新老用戶各佔多少。這是引流質量的問題,但具體如何採取行動,取決於你的引流戰略是希望更多的新用戶加入還是維繫老用戶。

第三類指標與價值相關。一是轉化率,即用戶進入網站後產生交易的幾率有多大。二是客單價,它衡量流量價值、衡量用戶對你有多大的信任。三是每次來訪價值,每一個訪客的每一次進站對你來說意味著多少轉化,這個可以用歷史數據進行推算;反過來,你可以根據這個數據規劃你在營銷上應該投入多高成本。

除了上面三類通用指標,還有虛榮指標和行動指標。前者在分析過程中很有用,但它不夠去驗證生意或驅動運營行動,後者沒有固定的套路。如果本著指標精鍊的原則,考核中肯定要看行動指標。舉一個最簡單的例子:比如一個標準的電商網站,網頁瀏覽量——PV是一個通用的衡量網頁被用戶瀏覽的量級的指標,早期的網站統計工具也都會用這個指標來衡量網站的流量,但如果只看這個指標,對於後續需要採取什麼行動的指導意義其實並不大,因為這個指標可能是很多人每人只看一頁,或者是很少人,每人看了多個網頁造成的,所以如果將它升級成為能夠驅動行動的指標,不妨可以使用每次訪問頁數,這個代表的含義就是用戶每次來訪參與的平均深度了,它的升高和降低直接能夠對應到網站的運營者需要如何來優化用戶體驗和內容,如果再將它升級,因為背景是電商網站,所以還可以升級成為商品詳情頁瀏覽量佔總瀏覽量比重,這個升級對於電商網站的運營就更能明確方向了,鼓勵用戶每次來訪查看更多的商品詳情頁,對於網站銷售的情況是有非常明顯的推動作用的,這其實在大量案例中被驗證,這是一個非常良好的驅動行動的指標。

與移動端相比,PC端具備更完善的研究環境。移動端收集的數據量級、維度、角度都會少一些。作為研究者或理論的關注者,我還是建議把PC端當做一個研究的環境看待。那麼PC端數據分析到底怎麼做?

(一)制定規劃

一制定商業目標。對很多企業來說,真正進入數據分析前,商業目標並不是十分明確。在你的商業目標不清晰的情況下,數據收集是沒有大方向的,甚至你的企業運營因為商業目標不準確而形成比較大的風險。所以建議根據企業規模、所屬行業、發展階段,提煉出1-3個清晰的商業目標。

二規劃KPI。商業目標本身不是一個數據,它不是量化的,而是屬於比較概括性的東西。所以它和數據之間需要有「橋樑」的連接,KPI就是這個橋樑。KPI雖然也是數據,但它是非常精鍊的,每個部門甚至每個人的KPI可能都不太一樣,所以KPI也是需要做一些完整的規劃。

三規劃數據指標,即應該採集什麼樣的數據。企業需要的數據不是你能採集到什麼決定的,而是由你需要什麼決定的。商業目標對應KPI,來檢測你的數據指標,這是我們常用的方法論,能夠幫助企業更清楚地把數據體系搭建起來。

按照這個順序規划了清晰的數據需求,再開展數據的採集和分析工作,可以避免數據分析方向偏差。

(二)數據標籤化採集

首先,數據標籤化。數據最常見的問題是數據污染、數據不清晰甚至混亂。造成這些問題的罪魁禍首,可能是數據收集前就沒有做到非常清晰的標籤化,但用戶是需要標籤的。只有把前期準備工作做到位,後期才不會陷入數據混合無法拆解,無法做數據細分和聚焦分析的境地。

第二,選採集工具。不同工具的需求不同,我認為比較常見考量工具有五個角度。

一是可用性。你的工具是否能滿足當前提出的數據需求,或者說能不能滿足99%以上的需求。重點在於它是否能支持你的數據採集、實時查看數據、訂單數據的完整收集。

二是易用性。一個非常好的工具,但它解讀起來很困難,工作流程非常繁瑣,這種情況會降低我們的效率。如果工具不易用就會造成用戶對數據的抵觸甚至恐懼情緒。

三是智能性。現在很多工具都加入了人工智慧的因素,比如谷歌分析GA中加入了機器演算法告訴你哪些用戶的質量高哪些用戶的質量低。智能性是為網站分析錦上添花的,並不是非常基礎的東西,它只是決定了人使用電腦工具效率的高低,並不會關係到工具能不能用。

四是擴展性。第一項是數據整合,第二項是數據應用的方向。谷歌分析有個其他工具望塵莫及的優勢,它很好整合了谷歌所有的營銷工具,並且能把數據輕鬆地推到谷歌營銷平台上,對這些用戶進行精準的定向營銷。

五是經濟性。包括收費方式和收費水平,需要綜合收益去考慮投入是否合理,是否在你的接受範圍之內。

現在企業在選擇分析工具時通常有個誤區,會恰好把這個優先順序排序反過來,把經濟性作為首要考量因素。一個工具收費一百萬,企業首先一個反應就會覺得很貴不想用,但既然它在市場上存在即有它的合理性,應該考慮的是企業該如何駕馭這個工具獲取更高的數據價值。

(三)數據清洗

在做分析之前,一定要對數據進行一次清洗,我非常建議把這兩塊數據最大程度上剝離出來:無效和無用的數據。無效的數據就是假的數據,無用的數據是真實的數據,但是對分析沒有作用,最典型的是測試數據。

數據清洗不能做到百分之百可信,最大也是最常見的問題是數據偏差的問題,數據偏差的修正也是數據清洗的一個步驟。很多客戶會非常在意數據偏差,因為他們有後台數據,尤其是銷售數據和訂單數據,當他們在機器里看到的數據和自己的後台數據有10%到20%的偏差,有些用戶就會走極端,覺得裡面差距那麼大,就不相信不參考這個數據了。

所以作為網站分析師,需要有能力判定數據偏差對分析結論到底會不會造成重大影響,這是數據分析師的基本素質。在分析過程中,我比較建議側重過程的分析,而不要特別在意結果的對照,因為如果數據偏差是穩定恆定的,那麼數據分析的結論就是合理的,跟真實情況不會有太大的差異。

(四)真正進入數據分析

準備工作做完之後,才開始真正的數據分析工作。在網站分析方面,我們分析的數據通常會分為四個模塊。

第一個模塊叫做用戶屬性分析。分析你的用戶是誰、在什麼地方、使用什麼樣的設備、平時有什麼樣的興趣等等,相當於做人物畫像。

第二個模塊叫做流量分析。包括流量質量的評估,流量的效果,流量之間的配合效率。

第三個模塊叫做內容分析。針對你網站呈現的內容順序做一系列分析,來發現用戶的行為習慣。

第四個模塊叫產品分析。對於需要體現價值的產品、服務、內容進行分析。

可能有人按照網站分析工具的慣例會認為應該是做目標分析,但我認為最後一個模塊不應該作為一個單獨的模塊,而應該融入前面的三個模塊裡面,轉化分析實際上對於前邊的模塊體現的是驗證的作用。

(五)改善行動

我認為在做改善之前應該再做一步測試,很多分析師會忽略這個環節。比如,得到了一個數據分析結論卻沒有人採納。對於一些重大的決策,決策者會用一些比較高的代價去做決策,這個決策也會帶來比較大的風險。縮小結論到行動之間的距離,降低決策風險和抵觸心理,不妨採用一些測試的方法,比如A/B測試,到底哪個營銷策略更有效測試一下就會得出結果,這個測試的代價確實非常小,而且出來的結果立竿見影。真正的數據改善行動唯一要多做的一件事情是,利用數據做追蹤,來驗證改善的最後成果。

這五步會形成一個完整的循環,隨著企業的運營和深入,會有一些新的需求產生,也會有一些新的問題的排查,會不斷進入這個循環中。


歡迎查看我關於數據分析的其他回答:

1.數據分析會騙人么?

2.如何進行互聯網金融運營數據的分析,都有哪些方法?

3.如何轉行做數據分析--電商版

————————————————————————--

微信公號ID:woyaobiaoshi

營銷需求 官網

鏢獅,一個低成本、高效率解決營銷痛點的網站


感覺各樓回答都比較理想主義,直接就各種具體的事兒了。

然而前提呢?你們數據分析團隊在公司的定位是啥?有時候個人再努力,也很難跳出那個定位。

即便要努力衝破這個定位,也不是簡單的自己找活兒就OK的。還是要到業務中去,從那裡發掘真正的需求,而不是自己閉門造車,什麼完善數據報表、什麼探索性業務分析......有沒有想過,你們辛辛苦苦搞完之後的東西,人家業務團隊看了很可能就是客套的表達下好NB,而已。

所以真想給自己找活兒干,還是多跟著業務團隊開會,多跟一線的業務人員聊聊,尤其是跟人家老大聊,然後再說做什麼。到時候再說什麼業務研究PPT啊什麼完善數據報表啊也不遲。

最後說一句,公司里要想價值最大化,還是要跟錢產生關係,不變現就很難有話語權。所以數據分析工作也可以多往這個方向上靠,更直接的產生價值,而不是間接的支撐。具體還要結合所在公司的變現模式來,數據報表什麼的都比較遠了,要是能直接弄出一個對接變現的數據平台或者可售賣的數據產品,就算是不枉給自己找活兒了


蹭明星熱點,什麼夫妻互動頻度變化,什麼anglebaby粉絲都是水軍

至於分析建模靠譜不靠譜誰關心

反正我手裡這把鎚子看啥都是釘子,反正我已經有了結論怎麼分析都不會錯

完了發在知乎還能刷刷知名度,敢質疑的都得被我拉黑然後被人罵死

這麼做的人挺有幾個吧,對還可以相互吹捧互相引流

說實話你們跟明星吃的是一碗飯只是你們段位檔次低了點


真沒事的話,去kaggle上找比賽做吧。又能交朋友,又能增加團隊知名度,還有小錢錢獎金拿呢!


分析商品期貨、股票數據(在淘寶上,500元可以買齊國內數據),建模,交易。獲得基本的財務自由。


這個取決於什麼領域的。一般來說,找一個能盈利或者創造價值較高的業務部門抱大腿就行了。

如果你們平時是業務需求驅動你們的工作,

那麼你可以倒過來,通過數據驅動業務的發展。

當然,這需要你想得比業務方還遠。所以平時跟業務方多扯扯淡,多看點書擴展視野。


看誰不爽分析誰,沒有誰是乾淨的,啊哈哈哈哈……


前提是,要把自己當做公司老闆,運營,財務等等(主人翁心態),看看自己會有哪些需求?然後結合這些需求,看需要哪些數據和分析。

我分析了下題主問題,理解下來是這樣兩個問題:

1.如何為單獨的業務部門提供「更好」的數據服務?

2.如何站在公司整體層面,讓各個業務部門的數據分析合理銜接,並以數據驅動整體公司向前。

第一個問題:

從三方面入手,理解需求,提供數據,提供服務。

理解需求:

自己首先需要學習相關部門的業務知識,並弄清該部門的職能。具體方式可以採用多問「為什麼」的方式進行。為什麼需要這樣的數據,為什麼以前不需要這樣的數據,拿到這樣的數據後,怎麼用,目的是什麼?對公司的意義和價值是什麼?等等。 其實很多業務部門並不清楚自己需要的數據真正是什麼樣的,因為他們可能不同整體公司業務情況。比如財務需要訂單數據,但他不知道公司訂單有已付款,未付款,在線付款,付款後又退貨,或者活動等。所以他們只能知道自己大概需要什麼樣的數據,所以這個時候需要打破砂鍋問到底,為什麼需要這樣的數據,及具體如何使用。

提供數據:

需求明確了,接下來該我們提供數據結果了。提供一套24小時高可用,高效,全面的數據倉庫,或集市,或大數據存儲這樣一套大數據系統,應該多的是活干。搭建好後,什麼流式計算,分散式存儲計算等等太多活。可以網上搜大數據分析,數據倉庫等相關係統構建文章。

提供服務:

數據是提供了,可是如何使用,如何便捷的使用也是關鍵。

快速穩定的系統是前提,然後結合EXCEL報表,用戶交互界面等。關鍵是看用戶,也就是各個業務部門用起來是否方便高效。

第二個問題:

很複雜,我知道FACEBOOK 的數據部門是介於CEO決策層 和其他 各個部門之間的一個特殊部門。這個部門不僅僅是提供數據服務,還要完成監控管理。完完全全的數據驅動公司前進。比如運營部門會說明自己為公司帶來多少的業務增長,但是財務部門會說這些業務增長卻沒帶來收益增長,反而過多的活動,導致公司虧損。各個部門之間扯皮,數據部門來提供真相。

而且,數據部門可以同決策層,制定很多的KPI或者流程管理。通過數據,來檢測各各個部門是否運轉達到效果,任務是否完成,成本是否過多,或者提前通知公司人員未能達標,需要努力等功能。同時檢測技術部門中的各個業務系統數據是否異常,是否一一對應。通過郵件或系統來報警通知開發同事,及早修複數據BUG。

總之數據驅動,需要公司改變拍腦袋決定策略的方式,而是通過數據和方法,來管理並運營公司。

有些公司,明年在哪些國家需要生成多少產品都是又數據部門寫好的數據程序,預測出來的。

個人的一些心得體會,歡迎交流。


一個提示。

古代,在興盛的時期,巫師這個崗位幾乎是沒活兒乾的。而只有到了荒年的時候,各種占卜、算卦的行業才會興盛起來,需求量特別大。

所以,沒有問題,那就創造問題唄。

:)


如果是團隊管理者,感覺你們團隊也沒啥大發展了……Leader都找不到活干,還想如何……

1. 找大領導溝通,他們對數據還有什麼期許

2. 找員工溝通,他們有什麼自己想做,但是上面暫時還沒有注意到,或者投入的

3. 找兄弟部門(或者是服務的部門)聊,還有什麼需求沒被cover到(讓別人做事,應該業務部門會各抒己見吧)

有時候聊著聊著,今年一年幹什麼,基本就出來了哦~

如果是執行者,不妨跳出來,學習一下別的東西,用數據看看世界。


首先不清楚背景中提到的各類看板已經比較完善是到什麼程度,是否還有迭代的餘地,什麼都不了解的情況下比較難答,勿見怪。不過數據驅動不一定非要強依賴於業務部門的需求,可以嘗試讓數據分析團隊主動了解業務後看是否能找些新視角。


首先完成本質工作,分析、建議、做數據產品搭建分析平台,然後才是發現業務問題,主動分析找到痛點,聯合業務部門解決。


靠數據報表提高公司運營效率不太現實。實際上業務部門很清楚影響效率的問題,只是沒有技術,手段,設備去解決。用圖表展示他們早就知道的問題沒有幫助。


我現在也是這樣的


推薦閱讀:

金融行業有哪些領域需要大量運用數據分析?具體有哪些職位?
數據分析和財務分析之間有哪些可以相互借鑒的地方?
數學建模可以用來做哪些有趣的事?
如何看待yandex開源clickhouse這個列式文檔資料庫?
分析數據應用圖表進行可視化時,如何判斷使用哪些圖表能最有效地展現數據?

TAG:互聯網 | 數據 | 數據分析 | 大數據 |