數據分析師做成了提數工程師,該如何破局?

大數據技術2019-06-21 23:30:07

來自公眾號:木東居士

0x00 前言

最近收到了不少數據分析朋友的吐槽和抱怨:

  1. Title 是數據分析,結果天天做着提數的工作,沒有技術含量

  2. 分析結論都是運營和產品向老闆彙報,沒自己什麼事

  3. 別人家的數據分析都是各種算法和模型,為什麼到了自己就是提數和提數

上面這些情形不管是在大公司還是小公司都是很常遇見的,如果你經常處於類似的工作狀態下,那麼一定時間後,你將失去兩項核心競爭力:技術深度和業務深度。

本文聊一下三個內容:

  1. 為什麼數據分析會變成提數工程師

  2. 數據分析該如何改變提數工程師的命運,充分發揮數據分析的作用

  3. 聊一下其它崗位的類似情況

0x01 為什麼成了提數工程師?

為什麼做數據分析會變成提數工程師?我們來看一下數據分析的大致工作流程:1. 問題提出;2. 數據獲取;3. 數據處理;4. 數據分析與建模;5. 數據結論輸出。

由於現在大部分互聯網公司的產品和運營相對更靠近業務,因此這兩個角色更容易發現和提出問題,如果數據分析師的主動性比較弱,那就會變成了如下這樣的工作分工:

  1. 【產品或運營】問題提出

  2. 【數據分析】數據獲取

  3. 【數據分析】數據處理

  4. 【數據分析】數據分析與建模

  5. 【產品或運營】數據結論輸出

也就是説,問題提出 這個重要的環節不屬於數據分析師負責,按照上面的模型運行的時間一長,數據分析基本就變成了幫助產品或運營驗證想法的工具

因此我們可以得到第一個原因:問題提出權不在數據分析師,數據分析只能去實現產品和運營的想法!

如果問題不是由數據分析師提出,再加上數據分析師的主動性差一些,那就會變成這種情況:產品或運營提一個需求,分析師就按需求實現一下,不需要思考太多,按需求做就好。這樣的結果是,很多分析問題都會很簡單,因為產品和運營並不太瞭解數據分析師能提供的能力。

我們得到第二個原因:產品和運營可能會提出相對簡單的問題,數據分析機械去執行即可,不需要過多的技術深度。

在上述兩種原因的影響下,數據分析也會逐漸失去主動性,最終淪為提數工具。

0x02 如何優雅地進行數據分析工作

前面拋出了問題和可能的原因,那麼我們該如何去改進呢?畢竟沒有誰願意只做個機械的提數工具的。總的來講,主觀能動性是解決問題的最重要的因素。細分來講,可以從下面幾個角度來改變:

  1. 積極主動地發現和提出問題,如果產品或運營已經拋出了問題,那就去深入詳細的瞭解問題的背景

  2. 提供更多的分析思路和自己的見解,幫助產品和運營同學打開思路,讓對方知道數據分析可以提供的能力

  3. 持續跟進分析結論的效果和反饋,不斷改進和優化

  4. 優化數據分析的流程,加入數據分析師可以更多參與的環節

一、舉個栗子

上面説的太虛,我們舉個例子來説明:

需求:

假設運營同學提出了這樣一個數據分析需求:最近我們網站的DAU降低了,麻煩你提個數據,看一下近30天我們各個模塊的DAU是什麼樣子的。

解決方案一:

假設我只是想簡單地完成這個需求,那麼很簡單,我只需要做這三件事即可:2. 數據獲取;3. 數據處理;4. 數據分析與建模。到這個場景裏面,可能就是從數據裏面撈一下我們網站數據裏面各個模塊的DAU情況,提供給運營就行了,不需要多複雜的處理,甚至如果有現成的報表,簡單導出來一個excel即可。

那麼當運營拿到數據後,就可以看出哪一個模塊的DAU降低,簡單看一下原因後寫在報告裏面即可。

解決方案二:

我們當然不希望是上面這種解決方案這麼低的參與感。那麼,該如何做呢?

首先,我們可以改進我們的分析流程

  1. 問題提出:通過監控或者主觀的數據敏感度,提前來發現相應的數據問題,比如DAU下降,是可以通過監控平台來提前發現DAU的下降

  2. 確定分析目標和產品訴求:需求中只是要看各模塊的DAU趨勢,但運營同學更想要的是找到為什麼整體DAU會下降,找到原因並優化該問題。我們需要和運營童鞋溝通並get相應的點

  3. 收集假設:運營同學提出要看各模塊的DAU,這只是運營提出的一種猜測,讓我們提相應的數據去驗證該猜測。我們既然知道了運營童鞋的訴求,在盲目地直接撈數據之前,可以提出一些假設,比如説:是不是某種瀏覽器的兼容出現了問題,是不是某種類型的用户對我們的網站感興趣度降低了,是不是某個模塊出現了問題,等等。

  4. 設計指標:有了假設,我們就可以根據相應的假設設計一些統計指標或者相應的分析方法,比如看不同用户畫像的用户近期的訪問情況、不同瀏覽器用户的訪問情況、不同模塊的訪問情況。

  5. 設計驗證方法和建模:有了假設,有了指標,我們就可以設計相應的方案來驗證我們的假設是否正確,這時就可以用到相應統計學和機器學習的方法,當然用户畫像也是很重要的一環。

  6. 確定分析結論和運營策略:最終,根據前面的步驟,我們再提供相應的分析結論給到運營側,此時,我們提供的就不是簡單的一個數據,而是一整套的數據分析報告

  7. 效果驗證和改進:一定要關注數據分析的效果,比如你的報告中提出了DAU降低是由於18-25歲年齡的用户大量流失,相應的運營策略是增加年輕化的內容,那你就要關注該策略上線前後的數據變化,數據是否按照你們假象的方向來發展,如果不符合預期就要相應的做調整。

如此,這才是相對優雅的數據分析流程。

在改進分析流程之外,我們可提供更多的自助分析工具,讓產品和運營能夠更多地自助驗證自己的想法,將數據分析師的工作從提數中解脱。這一塊就不再展開細講。以後有機會再做分享。

0x03 思考

其實,除了數據分析師之外,數據倉庫和數據開發同學都會面臨類似的困境,在很多分工不明確的公司中,這種提數需求是可以落在任意的數據同學身上,不同的是各個角色解決該問題的角度是不同的。簡單來講:

  1. 數據分析師:更多地要去深入到業務的需求中去,幫助產品、運營或者老闆思考,通過更多的思考來幫助需求方設計更好的分析思路

  2. 數據倉庫工程師:數倉同學的側重點更多地在數據模型的設計,設計出更靈活的數據模型來支持多樣性的分析提取需求

  3. 數據開發工程師:開發同學呢,則可以更多地側重於工具的建設,比如OLAP系統的建設,自助分析工具的建設等等。

0xFF 總結

總結一下本文的內容:本文通過【數據分析師做成了提數工程師,該如何改變這種現狀?】 這一個問題,引出了造成這種現象的兩大原因:

  1. 問題提出權不在數據分析師,數據分析只能去實現產品和運營的想法!

  2. 產品和運營可能會提出相對簡單的問題,數據分析機械去執行即可,不需要過多的技術深度。

針對這兩個原因,我們提出了兩個解決方法:

  1. 改進分析流程

  2. 提供更多的自助分析工具



●編號838,輸入編號直達本文

●輸入m獲取文章目錄

相關推薦↓↓↓

數據庫開發

https://hk.wxwenku.com/d/200964742