[Dashboard] 三種商業儀表板的用途以及在17直播的實際應用
3 Types of Dashboard and How We Apply in Practices
此篇主要引用 “How to Design a Dashboard” 電子書的內容(線上免費下載)。“How to Design a Dashboard” 是 CHARTIO 提供的免費線上教學內容，除了這本電子書之外，Data School 還提供其他資料相關主題的教學，都是簡明易懂、好入門的資源。| 前言
做為一個商業分析師 (Business Analyst)，最有成就感的時候，就是每週的主管常會，首先開啟那張我們含辛茹苦產出、嘔心瀝血維護的 Dashboard。展開後，沒有任何一個 chart 顯示錯誤或是無法顯示，沒有任何一個數字是 “-”, “No data”，主管們不需要先質問「數字為什麼出不來？」「為什麼跑這麼慢？」「為什麼沒有比較前期？」「我的 KPI 為什麼沒在上面？」而是，直接開始針對血淋淋的指標數據 (metrics) 進行檢討，討論改善方向和方案。
商業分析師有許多存在的價值，而屬於最「有形」的，應該就是 Dashboard 了吧！在這邊就把 Dashboard 的定義、價值、發展歷史交給維基百科了。然而，Dashboard 的範疇很廣，我知道網路上有許多文章從「圖表呈現」的角度來分類，有些從「內容」或是「受眾」來分類，而我認為對於商業分析師來說，Dashboard 最重要的就是要「能夠使公司內更廣泛地用資料來解決問題」，因此 “How to Design a Dashboard” 書中從「Dashboard 如何被使用」的維度，將 Dashboard 分成三個種類 — — Ad Hoc Analysis、Reports、Ongoing Decision Support，這種分類方式最深得我心。唯有「被使用」，Dashboard 才有對商業決策造成影響力的能力。
本文除了描述性地讓大家知道這三個種類的分別，我也會介紹我在 17直播 時，這三種 Dashboard 的使用情境，讓公司內上至 CXO，下至客服人員、基層員工都能透過 Dashboard 監測公司狀況、個人成效，達成從上到下 Data-driven 的落實。
| Dashboard 的種類
1. Ad Hoc Analysis
從商業上的資料使用者角度出發，「Day by day Retention 是多少？」並不會像考卷上的題目一樣出現的又乾淨又明瞭(寫考卷簡單多了！)，而是在想辦法進步業務的情況下，有脈絡性地發生的，以 Product Manager 為例：起心動念一定是：
1. 「產品的黏著度不夠高….」
2. 「不知道現在留存率是多少呢？(問一下 Data team 好了！)」
3. 「原來是 0.5 啊…，不知道有留言行為的用戶留存的機率是不是有比一般用戶高？(問一下 Data team 好了！)」
於是 Data team 的最佳反應狀況，就是針對每一個被提出的問題給出一個數字的解答，越快越好，如果資料的答案能夠和 PM 的思考一樣快，開發決策也會快狠準。
BUT 人類是視覺的動物，與其得到一個 0.5，正常的人類都會更想得到一個「折線圖」告訴我 0.5 是高還是低？然後就產生了「Ad Hoc Analysis Dashboard」的需求。除了分析師會使用 BI 工具提供之外，這種類型的 Dashboard 為了反應快速，也常常直接由營運單位自己使用 Spreadsheet 完成。(畢竟等到分析師有空，「選取」→「插入」→「圖表」都可以做 100 次了 😏)
[分析師角色咩衝啥？] 之 既然可以自己做，我要分析師幹嘛呢？
當然是因為你會做錯啊😵。營運單位看到的通常都是自己能夠接觸到的資料，如果只是為了做一個快速的決策，數字拿到做個參考，重要的是決策好不好執行、能不能落地，這中間很容易忽略了數據的真確性。
假想一個情況：公司 KPI 監測的都是「每月留存」，於是為了快速取得，PM 使用「每月留存」作為「每日簽到功能」的數據參考。但是，這份功能的提案可以說是「按照數據分析的結果產出」的嗎？分析師就是為了把關這層邏輯存在的，所以囉唆又愛管閒事的我們會問你需要這份資料的起心動念、你的推理思考脈絡，這是為了確保你使用的資料是有意義、分析是有邏輯、以至於最後的結論是能夠確保公司的指標成長的。最後我們才會告訴你：「要嘛你看每日留存，要嘛你證明每日留存會影響每月留存。」
只有這樣，我們才願意替你的功能提案背書，PM 才可以在提案會議裡面大聲地說：「只要開發每日簽到功能，公司關鍵指標就(有很大的機會)成長。」(如果可以的話我們也希望你自己做插入圖表就好了🙂)
2. Reports
有時候，為了一個很大的 Project，會產生需要深入研究的資料問題。不只是一個數字、一組指標，而是要探討歷史數據、指標和指標之間的互相影響關係，最終需要在一場會議做建議或是提案，這時候一張 Dashboard 就會以報告(Report) 的形式出現。
報告和 Ad Hoc 最大的不同是解決問題的規模(Scale)，Ad Hoc 講究的是 [快速] 做出 [一次性] 決策；報告追求的則是 [嚴謹地] 訂出方針 [策略]，並提出執行方案。因此，報告會考慮地更加周全，同樣以上面 PM 的例子來說，除了檢查推論邏輯是否正確，同時還會考慮「有沒有其他因素或條件會導致推論失效？」當 PM 問出「每日簽到功能能否幫助每月留存增加？」時，除了檢查每日簽到和每月留存之間的關係，或許還要檢查「每月留存」是否被其他功能更大幅度地影響？
同樣的，有時候營運團隊也可以就直接能夠取得的資料，自己製作成分析報告，用表與圖來進行說服，但是由於會比較耗時，也更有可能被抓到推理漏洞，分析結果遭到質疑。下圖就是使用 Spreadsheet 製作分析報告的常見結果。
想像一個熟悉的情境：你拿出靠著高超的時間管理之術，有時候還必須要加班才擠出的季分析報告，從目的到策略，每個步驟都有佐證資料(supporting data)，正氣凜然的告訴主管這一季應該開發的項目，然後主管問你：「這個表我只看到上一季的成績，有沒有去年同期的？可能只是上一季數字特別高/低」
「啊，去年這個時候有個大颱風影響了銷售和行銷活動，有沒有更久之前的資料可以參考？」
「你怎麼只看留存，我一個 CEO 朋友說要同時看流失率才可以。」
「我們要做營收給老闆看，只做流量不行。」
「你做的表格是不是少考慮了成本？」
「我們上一季開發的功能要半年才可以有成效，你現在就評估準嗎？」
………………
面對排山倒海不可能全部解決的質疑，怎麼辦？
[分析師角色咩衝啥？] 之 幫我解決我主管，他不相信我 QAQ
讓開！讓分析師來！我們會做出一個和你做的 Spreadsheet 87趴像的 Dashboard，乍看之下，結論和你的沒差太多，圖表的設計和顏色會用得更文青一點，介面好像比 Spreadsheet 更高級，然後會有一個神秘的過濾器 (filter)，只要選了就可以動態改變時間區間，或是改變分群屬性(例如男/女；年齡層etc..)。 [當然 Spreadsheet 也可以做過濾器]
除了由於 BI tool 介面理當比看起來很陽春、預設色彩太飽和的 Spreadsheet 更專業之外，報告經常遭到質疑的「區間/群體 偏差」(報告中選擇的時間區間，或是分析群體遭質疑為非普遍狀態，不可類推) 也可以藉由過濾器，在提案的當下解決質疑。
最重要的不只是呈現上的差異，而是分析師在更熟悉資料的情況下，不僅看到報告該解決的問題，也可以提出更多 [驗證為真、為假、驗證是否有意義] 的解答。
如果把分析師的腦袋具象化，我們其實會畫出有點像下面表格的驗證流程。盡可能地在報告前試過有意義的、主管可能提出的、常見的、探口風之後問到的質疑 (至於究竟要鑽牛角尖到什麼程度… 主管和男朋友的習慣和地雷都只有自己最清楚。) 而驗證過程中，就會需要使用到很多「資料庫有，但是你找不到」的資料。也就是「分析師知道，但你不知道」的資料源。
3. Ongoing Decision Support
雖然上面兩種 Dashboard 眉角已經有這麼多，但事實上第三種類型的 Dashboard 才是身在 SaaS 產業中商業分析師最常提供的類型。你的公司一定也有辣種，很神奇每次打開來數字都會更新的 Dashboard，在17直播的三年中，至少做了 50+ 張這類型的 Dashboard，每天至少有一半以上的公司員工上線瀏覽 Dashboard，應該算是各部門上下做決策的根基。
這類型的 Dashboard 出現的脈絡是：因為一個公司的商業模式就是長那樣，大家也知道一間 SaaS (Software as a Serive) 的公司，最重要的指標就是營收和流量，於是「賺多少錢？」「有多少用戶？」當然就會不停地被詢問，但分析師不想要一個一個回覆，所以就會乾脆做成 Dashboard 讓你自己查詢。敘述到這邊， “How to Design a Dashboard” 一書也破題表示，接下來的介紹都會圍繞著這類型的 Dashboard 進行深入的討論。
這張圖就是 Chartio dashboard 的介面 (好像我在業配一樣)，非常基本地，將重要的指標用 Score board 的方式表現，需要知道歷史數字的指標(如營收) 則是用有時間序軸的折線圖，這張表當中除了營收之外，還畫出了用戶數量、活躍行為，以及公司每日成本花費。就算老闆剛起床拿著手機在廁所，也可以立刻知道昨天公司賺多少錢。
雖然長得很像，不過這類型的 Dashboard 和上面兩種類型的開發方式有根本上的落差，是你用 Spreadsheet 的過濾器也做不出來的(資料量會讓你的電腦先當掉)。這裡的圖表來源並不是一個試算表，而是一組工程團隊維護的資料庫。
也就是說，之所以你看得到 Dashboard 上面一個一個精美的數字、精美的圖表，是因為有一群工程師在寫產品功能的時候，將使用者使用產品的紀錄回傳到資料庫，想要越精細的資料，就要越多工程資源投入。欲知17直播的資料生命歷程，可以看看這篇文章：17 Media 資料生命週期概述
[分析師角色咩衝啥？]
「可以教我怎麼自己做這個嗎？」不行！這樣我會失業耶！(開玩笑的)
我在17直播擔任商業分析師時，大約有 30–50% 的時間都在製作這類型的 Dashboard，我們必須非常了解資料獲取的流程，才能最快速地判斷商務端提出的數據問題，是否是既有資料庫就能回答的？抑或是要再開一條資料獲取管道才能達成？從 Layer1 Data set 開始，商務分析師則是必須知道每一筆資料的 metadata (資料的資料)，包括存取格式、更新時間，同時也要有能力開發 Layer2/3/4… 以便加快後續資料需求的反應速度。
我剛剛有提到在17直播的時候，總共做了 50+ 張 Dashboard，這也是歸功於17直播產品順暢的開發流程：產品紀錄資料的規格撰寫 → 功能開發工程師埋點 → Data team 檢查資料 → 分析師製作 Dashboard → 提供資料給業務部門，是一條龍的 SOP 在進行。
這 50 多張 Dashboard 涵蓋了 CEO 每天要看的公司整體情況、高階主管要看的部門表現、中階主管要看的指標分析，還有基層員工要看的專案成效。同時由於17在日本、美國、東南亞都有辦公室，為了讓各國同事也都能方便管理及獲取資料，我們也需要將各國資料需求統整後提供。
針對這些 Dashboard，我們有根據使用部門及TA階層做樹狀圖的分門別類、權限管理，同時為了視覺一致性，設計 Dashboard template 以及色彩使用規範。我將17直播 Dashboard 大致上規劃成 2 種 3 階，2 種分別是 [營運管理用] 及 [分析用]；其中 [分析用 Dashboard ] 又可以分為 3 階 [Overview]、[Details]、[Raw data]，在各部門都有相對應的使用範例。若有下集，或許可以再詳細分析當時規劃的心路歷程。
| 後話
前面幾篇文章，我都盡量使用我阿嬤都看得懂的口吻來敘述，但是 Dashboard 這個主題畢竟含有許多分析師的知識內容，無法避免比較艱深的詞彙，也許是我的功力不夠深厚吧。
Dashboard 的系列估計會有不止一兩篇，以此篇作為起頭，接下來還是會結合 “How to Design a Dashboard” 以及我個人的實務經驗，撰寫 Dashboard 設計及製作的相關內容，也歡迎留言告訴我文中是否有你想要延伸的問題，或是交流關於製作 Dashboard 的心酸血淚史哈哈。
