數據分析師幹什麼工作內容時候，需要和業務層打交道？越詳細越好？
是不是數據分析師工作時，發現數據有變化，這個時候就有可能要和業務層打交道，了解變化原因了？
下面對需要與業務方打交道的情況進行介紹，並說明可能出現的工作場景。
需求溝通
1. 明確需求——所有對於業務方的支持性工作
不得不說，大多數情況下業務方並不了解自己的需求，他們遇到了某種問題，希望能夠從數據的層面進行解決，但是對於這個問題的本質和解決方案並沒有深入的思考。
以模型支持為例，當業務方說「我們需要一個反映產品和運營狀況的分析模型」的時候，他想要的可能是「一個多指標關聯，可以通過改變某項指標分析其他相關指標變化的數學建模」，也可能僅僅是「一個包含分析路徑的看板報表」。
這個時候，我們需要與業務深入交流他們存在的問題，從而逐步明確解決問題的方式，以及需要做到的程度（要用80%的精力來解決20%真正重要的事情，簡單或價值不大的事情不要做的過於複雜，用力過猛）。
2. 溝通模型假設——模型支持
模型是對於現實的簡化和抽象，各種假設就是進行簡化的邏輯基礎，因此在模型構建時，我們的假設要合理（例如在預估用戶未發生的留存時，使用冪函數擬合方式，因為留存曲線通常先快速下降，後逐漸趨緩），並且需要與產品確認，獲得他們的肯定。
3. 了解分析背景——迭代分析
在進行分析前，我們要預先詳細了解產品各項變動、測試時間、覆蓋用戶（A/B測試或是全量迭代？分尾號或是分渠道？）等各類信息，並溝通業務方對於該項功能的預期（提高新用戶留存？促活？），從而對我們最終應該解答的問題有所了解，並基於這個問題逐步拆解，確認需要提取的數據和報告格式。
結果反饋
1. 數據異動預警與反饋——數據監測
數據監測是數據分析師的常規工作，通過構建能夠反映產品重要指標變動的報表體系，監測數據異常變動，及時發現外部或內部問題。
對於構建良好的指標體系，持續的趨勢或大幅的變動必然有其原因，這時需要與更了解產品變化的業務方溝通，查明原因，獲得業務方的處理方案並對管理層反饋。
2. 分析結果溝通——迭代分析
常規功能或活動分析通常兩種結果，符合預期、與預期不符。
符合預期時，我們通常通過簡單溝通，明確方案的合理性即可；
與預期不符時（例如活動效果不良，或拉新效果好，但是用戶質量差等），更需要通過有效溝通，引起業務方重視，並且需要獲得他們下一步的處理方案（功能回滾？活動方案優化？）。
方案落地
1. 方案推動與建議落地
報告或數據監測只是常規產出，但是對公司產生價值，必須達成方案的實際落地，並且通過數據反饋，不斷優化。
以基於聚類演算法用戶分群運營方案落地為例，使用聚類演算法獲得分群用戶標籤，還僅僅停留在理論層面。必須經過深入理解業務場景，與業務方探討，找尋適當的應用場景，並且嘗試和優化各類策略，才能最終對用戶產生影響，從而達成精細化運營的目的。
以上只是對各個環節的典型場景進行了說明，希望有所幫助。
實際上在數據分析師的工作中，數據與分析僅僅是工具和手段，達成最終的目的（創造價值）離不開同各個部門的協調，與業務層打交道基本是常態。
想要更多了解數據分析，歡迎關註：
互聯網數據分析?zhuanlan.zhihu.com
免費學習資料及更多數據分析文章，請關注我的公眾號：Ray的數據分析自習室
數據分析師要溝通的角色
包括: 產品經理 | 運營經理 | 後端開發 | 前端開發 | 客戶端開發
下面說下, 每個要溝通的細節:
通常在有產品改動前或者新上一次運營活動, 產品或者運營就要拉你一起開會, 定義改動後要看的數據指標, 看是否該數據已經進入數據釆集流程, 還是需要重新埋點. 如果要重新埋點, 這時候就需要找後端和前端定義埋點, 比如頁面按鈕點擊, 這時候一般是找前端或者客戶端工程師提前埋點, 至於是找前端還是客戶端, 取決於頁面是H5還是APP內嵌Activty. 最後如果埋點後, 需要進行埋點數據測試, 看數據是否順利進入日誌, 格式是否符合預期.
另外, 即使產品沒有變動, 但是產品希望看某個頁面的數據但實際並沒有收集該數據時, 也需要從新走一次埋點流程.
另外, 在埋點過程中, 很可能需要大數據團隊的支持, 雖然不屬於業務直接相關的團隊, 但是對應埋點後數據的流向, 往往需要數據團隊的支持. 往往小的創業公司是沒有專門的數據工程團隊, 這時候主要是後端, 前端, 客戶端會支持這部分工作.
有數據變化後的下一步
首先, 看數據變化, 是否分析現有數據就可解釋. 簡單舉例: 某天收入大增, 可能這天就是雙十一, 運營做了優惠促銷. 那麼這個變化是預料當中. 或者某天日活抖降50%, 這時候是不是check下數據源上報有問題? 這時候可能自己先做下初步判斷, 如果自己掌握的信息不足以解釋, 那就需要諮詢以上相關業務方, 看最近是否有產品變動? 運營策略變動? 數據採集流變動? 最後, 還是要回歸, 基於數據來解釋變化.
上面, 不知道講得是否容易理解.
對應數據分析師主要工作, 可以看之前的大白話, 可能更容易理解.
數據民工來取經兒：數據分析師幹啥活兒
謝邀！
數據分析應用的核心基礎在於，業務的數據化和數據的業務化，通俗來講，就是把銷售、市場、售後等商業過程中的數據記錄下來，再對這些數據用業務的語言進行解釋，讓業務決策人員可以理解，業務流程可以應用起來。我們常說的用戶畫像，就是一種對用戶行為數據的業務語言解釋。例如，在營銷場景中，用戶瀏覽了某產品三次，意味著該用戶對該產品的購買傾向增加。
而業務部門不同，對於同數據的描述方法也不盡相同。例如，「安裝師傅挺好的，只是這個聲音堪比鼓風機啊，只能說一等價錢一等貨吧！麻煩配送人員了！」。這樣一條評論，對於售後部門，就是一條正面評價，而對於產品設計部門，就是一條負面評價，且負面內容具體描述的是產品性能上的噪音問題。
因此同一條評論、用戶行為等過程數據，通常需要打上多種標籤，同時要把標籤之間的語義關係表達出來，這樣的方式近似人類語言中的概念與知識體系。學術界稱之為「知識圖譜」。
有經驗但不懂業務需求的分析師，往往喜歡把記憶中的分析維度與當前可以獲得的數據結合起來，來驗證一些業務假設或者既定的猜想。
分析中常見的人口統計學、轉化率、關鍵詞雲等分析維度，分析師採用的是「驗證式」的分析方法，而業務人員的思考模式更近似於「探索式分析」，想要知道分析結果背後的誘因或會有多少關聯因素會受其影響，從問題出發，去找到答案。
例如，通過監測，數據提示競爭對手上市了新款，並且銷售與好評最近3天表現一直在上升，從這個數據出發，我們可以探索，該款產品的設計要素與價格，直接與企業的那些品牌產生競爭，同期內，我們的策略與口碑表現對比如何？競爭對手的這個產品，好評在哪些方面，是哪些產品要素導致了這些好的口碑？是否值得我們跟進？
這種探索分析的方式，利用了數據挖掘的手段，更加符合人類的思考與推理方法，更容易得到有效的、可行動的結論。
數據決策過程需要多種背景、多種角色的人員參與，程序猿、分析狗與營銷喵，分別負責處理數據、生成分析報告，產生業務決策三種不同的任務。通過一個在線的協同系統將三者置於同一套界面、語言和流程下，不僅僅有利於大家更加具象的進行交流，減少信息漏斗，提高溝通效率。
希望對你有幫助。
關於億信華辰
億信華辰是中國專業的智能數據產品與服務提供商，一直致力於為政企用戶提供從數據採集、存儲、治理、分析到智能應用的智能數據全生命周期管理方案，幫助企業實現數據驅動、數據智能，已積累了8000多家用戶的服務和客戶成功經驗，為客戶提供數據分析平台、數據治理系統搭建等專業的產品諮詢、實施和技術支持服務。
編輯於 03-12繼續瀏覽內容
知乎發現更大的世界打開
Chrome繼續
九月風飛數據分析，商業分析，愛瞎聊天什麼時候都需要吧，數據分析的基礎就是業務，了解業務也是數據分析base的基本功，細化到具體場景就是 需求確認，專項分析，自助研究，都是需要和業務進行前後兩階段多次確認交流的
什麼時候都需要吧，數據分析的基礎就是業務，了解業務也是數據分析base的基本功，細化到具體場景就是 需求確認，專項分析，自助研究，都是需要和業務進行前後兩階段多次確認交流的
看到題主的兩個邀請，覺得題主挺有想法，並且很認真的思考了這個職業選擇。我是個顧問，服務的對象是傳統行業的數據分析師們。可以說數據分析師與數據分析師間區別太大了。有些服務於高層，當個師爺，有些服務於business unit。。。有些天天做 high level dashboard，有些天天就是抓 outlier然後解決他們。。。你說的發現「數據有變化」應該說的是後者。總的來說，答案就是「可能需要」。一些數據分析師希望自己的分析有用，能指導實踐，那麼就必須精通業務，和業務部門搞好關係。一些數據分析師立志於用最新的技術，做最炫的圖，那也很好。還有一些混日子的，實話說，畢竟商業實踐在這個職位存在前就存在了，不犯低級錯誤，很容易混下去
數據分析更多要理解業務，並對sql深入了解，目前主流是大數據數倉例如hivesql，對業務就行ETL，獲得不同維度的計算。
當然還可以做數據的展示，比如finereport,或者其他bi工具。數據計算要注意兩個概念，維度和度量。
關於SQL說起來挺多的，具體不一一展開。
數據分析是手段，終極目的還是要解決業務的問題，所以數據分析師任何時候，做任何工作內容，都需要懂業務，需要和業務層打交道。想要了解的更加詳細，自己去找資料吧。
按理來說，應該在所有階段保持和業務人員的溝通，最好在一起工作，有問題趕緊問。因為你做的任何結論都得業務上說得通，行得通才行，而且不了解業務的挖掘，得出來的很可能都是沒用的或者錯誤的結論。
不過，在實際工作中就很複雜了，各種各樣的原因導致你沒機會溝通，我一般是退而求其次，最開始的業務理解和數據理解階段一定好好聊，之後分析挖掘的時候有問題再去問，最後出結論改良的時候好好溝通。
我理解的數據分析一定是基於業務的分析，並不是只從數據分析，不了解業務談不了數據分析，換句話說，不知道數據從哪裡來，怎麼分析呢？
要積極跟業務同學打交道啊，看他的業務思路，同時從數據的角度看這個產品，會碰撞出很多火花的，甚至可以影響到業務產品。
推薦閱讀：
