解鎖數據分析師的日常：如何在工作上發揮最大影響力
在 ChatGPT 問世之後，在數據相關的職位當中，有些人認為數據分析師是最容易被取代的工作，或有些數據分析師覺得自己是個撈數據的工具人。
但在 17live 直播平台擔任數據分析師的講者 Joy 卻認為，不管是 DS(Data Scientist) 或是 DA(Data Analyst)，其實都有自己的專長領域，數據分析師也有其不可取代的優勢，因此本次分享的重點在於：數據分析師要怎麼在工作上發揮最大的影響力。
職涯選擇：從數位行銷到數據架構完整的 17 Live
講者職涯初期投入於數位行銷領域，因為行銷常需要辦活動、經營粉絲團、相關線上活動…等等，碰到數據的機會非常多，也發現自己對數據的興趣，因此從遠傳離開後，就跨領域到數據相關的職位，加入玩美移動，擔任商業分析師。
玩美移動結合 AI 跟 AR 提供虛擬試妝技術的服務，業務包含 To B 和 To C：
- To B 主要會跟美容彩妝品牌合作，提供線上試妝或肌膚檢測的服務，舉例大家去百貨公司的美容專櫃，會看到有像 iPad 的機器進行臉部掃描後會分析消費者的肌膚狀況。
- To C 部分就比較單純，就是常見的 APP 修圖、影片編輯的 APP。
玩美移動當時數據分析團隊的分析師有三位，因為 To B 的業務比較大，所以 To B 的分析師有兩位，To C 只有一位就是講者。
講者當時的工作內容包含：規劃 To C APP 上面的數據埋點、撰寫規格跟工程師開會討論、發現數據 bug，請工程師修正、APP 上線後依照各部門數據需求，撈數據提供，最後會製作報告，使用的工具有 Excel、PPT，或是視覺化工具的 BI 工具像是 Tableau 或是 Looker Studio。
這份工作比較大的優點是：數據埋點都是由講者負責，所以對整個 APP 的數據的了解可以很全面，而公司各部門像是行銷、PM、業務有數據需求時，也會找講者討論，因此講者可以了解每個部門的運作以及業務內容。
在講者撈數據時，也可以清楚知道數據是否存在，數據需要到哪一張表去找，整題而言撈數據比較有效率。
缺點方面：因為公司當時並沒有獨立數據團隊，所以在數據品質控管方面就沒有那麼嚴謹，發生 bug 的機率比較高，修復時間也會比較久。另外公司在 Data 投入還沒那麼深，因此要用數據結果去影響公司決策會比較難。
因此講者在找下一份公司時，就特別希望找有投注資源在 Data team 的公司，也就是講者現在的公司 17Live。
17Live是個直播平台，用戶下載 APP 後，可以在 APP 裡購買點數，點數可以購買禮物送給主播，也就是常聽到的 Donate，另外也可以訂閱喜歡的主播。
主播會在直播當中跟用戶有即時互動，也可以在平台貼文或是短影片，跟粉絲做更多線下互動，另外也會針對訂閱者提供更多福利，像是只有訂閱者能看到的限定直播。
17 的數據團隊架構分三大塊：
- 獨立 Data Team，團隊成員由 DS(Data Scientist) & DE(Data Engineer) 組成。
- 各個部門裡會有各自的 Data Analyst，講者就是在 PM 部門底下的 Data Analyst。
- ML(Machine Learning) Team，主要負責直播的推薦機制。
從架構與數據團隊的人數來看，可以知道 17 的確有花蠻多資源在數據這塊，包含維護數據。另外 17 的優點是蠻 Data-Driven的公司，像是 PM 在做規劃或決策時，會非常依賴數據去支持各種規劃，這些都符合講者當時轉職的考量：想找 Data 架構相對完整的公司。
講者在 17Live 擔任的角色是產品數據分析師，主要工作分三大塊：
- 新功能上線前的成效預估，舉例：PM 在新功能上線前，會需要設定這個功能想要達成什麼目標，以及要用什麼指標去做成效的衡量，如果有新的付費功能，也會需要產品數據分析師協助規劃定價策略。
- 新功能上線後，產品數據分析師會協助產出成效報告，去確認是否有達成上線前的預估目標，如果沒有，PM 就會再去做後續的優化行動。
- 個人的專案研究，這個部分相對彈性，產品數據分析師可以根據 PM 比較關注的功能，或是自己比較有興趣的領域，去做一些數據研究，這部分完全由數據分析師決定，而研究結果是為了讓 PM 未來做產品規劃時可以參考。
這份工作的優點：
- Data Team 架構完整，資料完整度較高且品質較好，如果有數據的 bug 也比較容易找到專人提供協助。
- 數據團隊會進行交流與分享，無論是 DS 最近研究的新技術，或是 DA 做了什麼新的分析報告，都會在公司內進行分享。
- 公司有 Data-Driven的文化，數據團隊會比較多機會去影響 PM 的規劃或是決策，比較不會是單純撈數據的工具人，而是可以對決策做出貢獻。
小缺點是：
- 公司業務量跟資料量龐大，要分析的情境也會隨著部門或者時間有所不同，每個部門對同個指標的定義也會有所不同，舉例：VIP 用戶的定義，可能今年定義是要在 APP 上花費某個金額才算 VIP，但明年因為情境改變，而又會調整 VIP 的定義。如果要避免同個名詞有不同定義造成的混淆，數據團隊必須在每一份報告中清楚解釋每個名詞的定義還有背後計算的條件是什麼。
- 不管是DS還是在各部門內的DA都會有自己的分析報告、自己的研究主題，所以偶爾會產生重工的情形，例如：講者現在在研究用戶的註冊行為，但可能 DS 先前也已經有類似的報告，當發現研究範疇有些重疊時，現在的解決方式會是同編輯一個文件來紀錄大家做過的報告，盡量減少重工的現象。
數據分析師的價值
不管目標是成為處理數據的角色，或是當個有影響力的分析師，講者分享了六個成為分析師需掌握住的基本技能：
- 敘述性統計概念：做分析不一定要讀統計系，但對敘述性統計的概念，例如：平均數、中位數、百分位數還是要了解，對分析會比較有幫助。
- SQL：做數據分析很難不碰到 SQL，是非常重要，要練到很厲害的技能。
- Python：蠻多數據分析師的職位會要求會 Python，但講者自己的情況，只有在處理比較大量的資料跟複雜的計算時才會用到 Python，但頻率不高，不會像 Data Scientist 那麼常用到，會依照每個公司跟每個人遇到的狀況而定。
- Excel：比較常用到的包括樞紐分析、各種函數、分析圖表…等。
- BI（Business Intelligence ）工具：BI 工具使用上其實大同小異，使用過一家 BI 工具，要上手其他家 BI 工具其實不會太困難。
- Storytelling：做分析成果簡報時怎麼報告，比分析怎麼做還重要，因為在分享分析成果的時候，其實聽者不會很仔細去看分析細節，但會很仔細去聽整個分析故事，要如何讓聽眾了解你要傳達什麼資訊？要說服聽眾做什麼決策？這時候的時候 Storytelling 的能力就很重要。
前面提到的都是成為分析師的技能門檻，但如何成為有價值的分析師，關鍵差異在於「主動性」
這個主動性會體現在幾個地方，例如：分析師會主動去理解需求方的業務內容跟 KPI，就可以用數據分析去更好地解決需求方的問題，更進一步可以協助需求方建立假設，找出 Insight 跟 Action item。
建立假設的能力講者分享可以參考《BCG 問題解決力》這本書，這本書的作者是 BCG 的顧問，他們挖掘與解決客戶問題的流程其實跟數據分析的流程滿像的，所以數據分析師想知道如何用數據解決問題，可以參考這本書，滿有幫助的。
關於提升 Story telling 能力講者分享了《Google的必修圖表簡報術》、《資料故事時代》兩本書，除了教你如何做出簡單易懂的圖表，還可以學習在簡報當中如何運用圖表，讓整個故事變得更順暢，也可以更有力道去說服目標聽眾做出決策。
數據分析的流程五步驟
一、定義問題
釐清專案要解決什麼問題，可以幫助後續分析事半功倍，所以投資在這個階段的時間雖然比較久，但卻很值得。
定義問題可以從三個面向來思考：(1)專案背景(2)專案目的(3)欲驗證假設。
回答這三個問題就會延伸到我們選用哪些數據？產出哪些指標？這些數據跟指標可否能回答問題？這些數據跟指標是否能協助決策＆行動？
講者分享範例是：17 APP 裡的探索頁，這個頁面會分兩個區塊，一個是搜尋功能，可以搜尋主播名稱或是直播內容，得到想看的內容，另一個區塊就是依照影片類型分類，使用者可以挑選有興趣的主題找到想看的直播。
PM 一開始的需求單，專案名稱是：進行探索頁面的優化。數據需求是：每個模塊的點擊率、多少使用者點入探索頁、進入探索頁使用者的 Retention Rate。
這個需求對於數據分析時來說，其實是很困惑的，因為 PM 並沒有告知這個專案的背景是什麼？目標想要做到什麼事情？也沒有提出假設或者是問題，導致分析師對於為什麼要看這些數據指標感到困惑，不確定這些指標是否能達到 PM 的目的或是可以協助 PM 作出決策嗎？
講者跟 PM 釐清專案背景、目標、想要驗證的問題，因此知道專案背景：因為探索頁面的 Page View 不斷下降，為了減少下降 PM 考慮是否要在探索頁新增更多不同類型的影片區塊？或是提升搜尋的準確度？這是兩個不同的優化方向。
專案目標就隨之改寫為：決定現階段優化重點該著重於探索模組或是搜尋功能？因此我們需要先知道進到探索頁的人，會使用搜尋還是點選探索模組？
目標之下就會是幾個需要被驗證的問題（假設）：
- 第一個假設：進到探索頁得使用者只會使用搜尋功能，數據驗證指標=搜尋人數/進入探索頁人數。
- 第二個假設：使用探索頁後，使用者對 APP 的滿意度會提升，數據驗證指標=使用者使用過搜尋或是探索模組後，觀看時間以及Retetion rate 是否有提升？
- 第三個假設：新註冊的使用者對於探索頁的使用率會較高，新註冊者比較會搜尋特定直播內容或直播主，或是看 APP 推薦的內容，如果新使用者的使用率真的比較高，後續就可以著重向新用戶推廣探索頁。
聽到這邊可能大家會有疑問，在這個階段都還沒看過資料內容，怎麼知道要驗證什麼？為什麼不是先撈數據再解釋？
實際執行時，分析師手上會有超多數據，但就像在數據海裡，如果船沒有指南針，無法確定這些數據對決策有沒有幫助，可能撈了一堆數據出來但卻不知道如何解釋與收斂，反而會讓自己變得很混亂。
所以講者提醒做專案首要也最重要的是根據專案背景，還有過去的經驗，先提出假設再去驗證，這樣的流程可以把資源優先放在重要的關鍵問題。
可能有人會擔心假設的正確性，但其實不用太執著假設的對錯，因為假設本來就不一定是對的，所以才會叫假設，但我們可以透過持續的驗證去修正或是優化假設。
雖然假設不需要完全正確，但還是有些原則可以去設定出好的假設，就是《BCG 問題解決力》有提到的三個原則：
- 針對性：假設需要具體不能太過空泛。舉例今天要了解月活躍用戶下跌情況很嚴重，要寫得更具體的話，可以去拆解月活躍用戶是因為新用戶數量減少、既有用戶留存又下跌，這兩個因素才是造成月活躍用戶下跌，那就可以具體寫出來，後續才能做更精確地驗證。
- 驅動性：假設得到結果後，需要有後續的行動方案去改善。舉例最近發現新手主播開播數量很少，假設可能是：對新手主播的引導不夠，新手主播不了解怎麼進行開播。「新手主播不了解」這個有點抽象，把假設寫得更具體就是：在 APP 上面引導新手主播如何開播的說明，或是 FAQ 寫得不夠好，因此新手主播開播數量少，如果假設驗證為真，就可以從 FAQ 頁面或是引導說明進行優化。
- 可證性：假設必須有辦法被驗證的。舉例今天想要知道月活躍用戶降低的原因，你的一個假設是用戶轉移到競爭對手的 APP ，這個是無法驗證的，因為你不會有競爭對手的資料，這個假設對專案就沒有什麼幫助。
二、收集資訊
講者最常用的資訊包含質化跟量化的部分。質化數據來自公司使用者調查團隊定期做的用戶訪談，或是來自用戶的意見回饋 FAQ；量化數據來自公司內部資料庫的所有數據，是主要分析的大宗。
三、分析數據
數據分析金字塔：從底層 Data 經過層層處理會變成 Information，最後會得出 Insight。
Data 指的就是沒有經過處理的資料，純粹是客觀事實，例如：APP 月活躍用戶有一萬人，知道這個資訊不會產生下一步的行動。
Information 是稍微被處理、組織過的資訊，例如：月活躍用戶一萬人裡，有 80% 是 30–40歲男性，就可以知道 APP 主要用戶是中年男性。
Insight 方面，需要試著從分析資訊去找到結論可以產生行動，例如：知道 80% 用戶是 30–40 歲男性後，又分析知道這些男性的直播偏好是遊戲類為主，就可以試著在 APP 裡增加遊戲主播曝光率，或是做一些推薦提升整體直播觀看次數跟主播收入，就是個比較有行動方案、比較有價值的 Insight。
講者分享幾個量化分析技巧
- 比較：當拿到絕對數值時，很難判別好壞，舉例一個按鈕點擊率 20%，無法判別高或低，但如果有其他比較基準，舉例其他按鈕點擊率 40%，或是 10％ 就可以判別這個 20% 的好壞。
- 趨勢：某些現象的表現在特定期間比較好，就是在分析時要注意的現象。據力：公司的營收都是月底比較好，要觀察一個功能上線對營收造成的影響，不能拿月底功能上線的營收跟月中或月初的營收比較，要做同期比較，結論才不會有所偏誤。
- 構成：在數據分析時會看很多指標，這些指標都還可以進一步拆分，舉例月活躍用戶可以再拆分成 新用戶（new）＝當月新用戶、留存（remain）＝連續兩個月都有使用 APP、喚回（resurrected）= 上個月沒使用，這月有使用的用戶。拆分構成的好處是，可以精確知道月活躍用戶上升下跌是因為哪群人的變動造成的結果，就可以針對特定人群做後續的行動，決策可以更精準。
- 資料集中度：了解資料分布，可以對後續離群值的處理有幫助。
四、簡報製作
講者不方便公開公司簡報，但是分享一個講者常用的簡報架構(Resource)，包含4個區塊，最上面的標題就是要陳述的關鍵訊息，接下來一些敘述說明搭配主體的視覺化內容，如果有需要註解補充可以寫在旁邊，最下方可以放上資料來源。
講者用以下 Before & After ，說明更多簡報製作的細節
Before
顏色蠻漂亮的，但資訊呈現來說一點點雜亂，比較大的問題是標題有點長，聽者不太好去抓到關鍵訊息，圖的部分大概知道想比較 2021 Q3 跟 2020 Q3 同期營收成長表現，但這張圖其實也沒有 Highlight 這件事情就會有點抓不到重點。
另外表格部分講者會盡量減少使用，因為對聽眾來說要短時間理解表格架構跟內容相對吃力，盡量還是選擇用視覺化方式呈現。
After
標題相對來說較簡潔明瞭，會知道重點是 2020 Q3 表現得非常好，超過原本目標設定，左邊圖表就有用深色 bar 去強調 Q3 營收的同期比較。
表格的部分則是用長條圖取代，可以很清楚的瞭解每個品牌的營收，跟目標（黑色 Bar）的差距可以用視覺來快速理解，不需要自己看表格內的數字計算才知道重點。
五、分享報告
分享報告的簡報中會有一頁 Summary，這頁的目的是讓讀者快速了解這份報告的關鍵資訊，因為不是每個人都了解專案，所以要簡單闡述專案背景、問題與假設、分析後的結論跟後續行動方案，主管比較忙沒時間看完 30 幾頁的報告，可以看這一頁就快速抓到重點。
報告時也有幾點可以特別注意的訣竅
- 要講聽眾聽得懂的語言，像是數據分析會用到的專業術語 etc. PR 值、離群值，不是每個人都知道這個詞的概念，就必須要換成簡單同俗話的講法，要講聽眾聽得懂的內容與用詞。
- 不用追求投影片數數量，重點是把關鍵訊息保留，把能回答假設跟問題的數據保留，其他部分相對來說沒有那麼重要的內容可以刪減，或是放到附錄。
- 不要害怕被問問題，有些人會認為被問題是對於分析結果挑戰，或是怕自己答不出來，但其實收集簡報的回饋是蠻重要的，有些人可能會提出可補充的數據，或是針對還想深入看什麼分析內容，分析師了解這些反饋後就可以把簡報修得更佳完善
- 數據分析的工作不是做完簡報就功成身退，講者認為可以試著去追蹤後續行動方案。如果數據分析師是想發揮影響力，去了解分析結果提出的建議或方案執行後的結果，可以了解自己的報告是否真的對於決策方面有幫助，這個就是發揮影響力的過程。後續例如你在轉職的時候，有些面試官也會很喜歡問：可以舉例你的報告內容有沒有為公司作出什麼貢獻，如果你有追蹤，那就可以有自信的分享這個報告後續引發的行動帶來的貢獻。
Q&A
Q1：在分析時會用到因果推論的方法嗎?如果有的話會是在什麼樣的場景？如果沒有的話，產品團隊會如何討論跟驗證因果？
A1：我覺得要驗證因果關係最好的方法還是要做 AB testing，因為在做一般數據分析其實最多只能驗證相關性，但如果是要驗證因果關係，需要控制比較多的變因，所以還是要用 AB testing 去確定真的有因為這個功能提升什麼樣的表現。
Q2：會做 AB testing嗎？使用的場景跟頻率？
A2：會，我自己遇到蠻多次的，頻率不太一定。使用場景滿多是在頁面改版或是流程改版，通常是擔心這個改動會不會大幅影響 KPI 指標，例如註冊人數或營收，就會傾向先用 AB testing 做小規模驗證後再推到整個 APP。
舉例：我們那時候想驗證註冊流程有無特定頁面對註冊率的影響，就會針對這個頁面做 AB，註冊人數或者是影響到revenue的話其實，還蠻可怕的
Q3：小規模的 Roll-out 跟 Testing 你們是怎麼去抓 Sample Size 跟要 Target 的使用者？
A3：實驗細節會是 DS 進行設計，我了解的是，他們會先抓一個預期效果，例如提升 5%，還有測試要做多長，都會影響到要收集的 Sample Size。
Q4：當公司有一個指標，但各部門對指標定義用法不同時，會有什麼分析上的困難？有什麼具體的建議？
A4：我覺得目前來說大的指標就是跟營收有關，或是關鍵 KPI 有關基本上不會差太多，這些大指標應該在跨部門間都要是一致的，大家才可以在同一個基準點上分析跟解讀分析結果。
但可能有些比較細節的指標，例如說直播的互動人數到底怎樣才算互動人數，有些人可能覺得有留言就算，有些人覺得有留言、有送禮物、有 follow主播才算。
像這樣的情況，在報告裡看到互動率提高，你不知道互動率的定義是什麼？所以在報告的 Criteria 裡就會寫清楚這份報告中指的互動率包含哪些行為，互動率的定義的確可能會隨時間而改變，最好的方式就是每次報告都要寫得非常清楚。
Q5：請問數據分析師的工作有辦法遠距嗎？還是有些事情必須要實體工作？
A5：我在 17 都是遠距上班，所以我覺得是可以的，實體工作的好處是我要問 Data 一些定義上的問題，或是針對資料抓取的細節，用遠端就會比較耗時。
特別是數據需求很急的時候，如果相關合作同事無法立即回覆，就會比較緊迫一點。我覺得要遠距是一定可以，但還是會有點小缺點，不過整體來說要用遠距方式去完成整個專案，不會有太大的問題。
Q6：請問數據分析師會很要求本科系研究所學歷或作品集嗎？
A6：科系本身還好，因為有些 DS 可能是心理系出身，我自己是企管系，的確有些是統計系或是數學系出身，但其實沒有限制什麼科系，或是研究所學歷。
作品集的部分要看公司，我在求職的時候有蠻多公司有要求作品集的，但是我記得 17 沒有特別跟我要作品集，但我最後還是錄取了。所以作品集可以準備，但可能不是每間公司都非常的必要。
Q7：每個月會花多久時間進行個人想探索的專案？可以分享一些有趣的題目嗎？
A7：因為我們平常手邊的東西還蠻多的，所以1個月內大概是做不太完。我自己平均抓做專案的時間差不多是三個月左右，但中間當然包含要處理很多利害關係人的需求，所以我們會先設定三個月，是你個人專案的 Dead line，然後會列一兩個 Check Point。
我覺得我們的題目都蠻有趣的，像有研究 APP 上提供給主播的一些特殊功能是否有提升開播頻率。
其他的同事可能會研究說看越久直播跟收入貢獻的關係，不一定是看越多主播或看越久越好，有可能使用者看得主播數量不多，但會把所有的錢花在一兩個只播身上，對平台來說，反而這種只追少數主播的使用者價值比較高。
或是會做一些虛擬主播的研究…等等。只要有興趣的話都可以去做不同的主題，不會有太大限制。
Q8：團隊是如何管控數據品質？
A8：主要是 Data Team 會處理，拿玩美跟 17 比較的話，17 在數據埋點前的確認會比較多，PM 在功能上線後需要什麼數字，會在上線前就跟 Data Team 討論，確定這些資料確實在哪張表上拿的到，這張表上的數據除了分析師們會確認，也會交給 QA 團隊去確認這個數據的正確性，在事前的確認做得比較多。
事後如果發生真的有數據的 bug，要修正 bug 就是開單去做完整的紀錄，可以確定 QA 什麼時候會測？哪一版會測好？測好之後我們就可以再使用。我覺得不管在事前還是事後的把關手續比較多，這樣來回確認就可以確保數據的正確性。
Q9：17 直播的分析師會跟 User Research Team 一起合作嗎？如何合作？
A9：我沒有跟他們直接的合作，他們比較是獨立的 team。我自己聽到是其他的同事會跟他們合作，例如他們今天可能要訪問特定條件的 VIP 用戶，就會請分析師撈出那些人的名單。但基本上合作機會很少，幾乎不太會合作。
Q10：有遇過 Dashboard 內部使用率偏低的情況嗎？如果有會建議怎麼改善呢？
A10：有些比較久之前做的 Dashboard 內部使用率偏低，是因為這些 Dashboard 上的指標隨著業務變化，大家漸漸覺得不太重要，因此 Dashboard 的使用率就會降低，這個跟公司目前重視的指標會有關。
如果要避免這個情況，通常要做 Dashboard 之前我會先跟利害關係人確定這個內容有沒有需要持續、高頻率（etc. 每天）的觀測，有的話才會做成 Dashboard 或是自動化報表，如果是觀測頻率不高，例如半年才會看一次，我就會 by request 抓資料給使用者。
筆記手：盧姵吟 Lavina Lu
校稿：Joy Lin、Andy Chang
👉 歡迎加入台灣資料科學社群，有豐富的新知分享以及最新活動資訊喔！
https://www.facebook.com/groups/datasciencemeetup
