特別把描述模型和預測模型分開來寫是因為兩者在開發與驗證階段有不小的差異。

(https://ubiq.co/analytics-blog/create-operational-dashboard-business/)

Initiation

起始階段有幾件事要確認

• 商業意圖是否明確：商業意圖不是只明確的需求，而是他想利用這個模型做什麼。例如「想知道公司的使用者面貌」，這只能算是需求；「想根據不同使用者面貌做差異性行銷」這樣才是商業意圖。因為使用者可能會提出無法滿足商業意圖的需求，這時候做了也是白做，所以最重要的事情就是確認商業意圖。

• 需求：例如是想知道使用者 Profile 分佈、人數趨勢、還是看熱門排行。如果商業意圖還不明確的話，就還需要在回到上一步多著墨，至少要需要變成一個比較明確方向的問題，才有辦法往下走。

• 資料來源是否足夠：這關乎到「能不能回答問題」，如果資料不夠就要再回到上一層（原始資料）去尋找可以回答問題的資料。

Design

只要問題明確，描述型的模型設計起來相對單純，只要先確立：

• 要用什麼方式回答問題？是比較不同群體、比較趨勢型、還是呈現單純的數值？
• 能用來回答問題的資料屬於哪種類型

這樣我們就可以透過相對的描述統計圖表來呈現關注的議題。

Implement

在做 Implement 的時候，通常都是透過圖表的方式來呈現結果，一些圖表設計要注意的東西，之前也有提過一點。重點是要讓分析故事講起來有邏輯。通常也是有公式的：

1. 先介紹關注議題的整體趨勢：例如人口趨勢、產業趨勢、或 App 使用者人數等大趨勢。
2. 針對單一變項切入凸顯故事重點：例如主題是最近三個月的人數衰弱趨勢。
3. 針對特殊的部分切維度比較：這時候可以依照使用者人口屬性切、或是依照登入平台切，看不同面向的差異，找到最關鍵的影響因子。

技術上來說有很多 BI 工具像是 tableau、Redash、PowerBI、Excel 等可以做到，不會是本篇的重點就跳過了。

Deploy

因為是描述行模型，部署指的就是將結果呈現給使用者。呈現的方式可以做成所謂「戰情報表」、「監控儀表板」、或是簡報的方式呈現。（如果是簡報通常不會純粹呈現、而是會帶上分析師對於內容的觀察和見解。）

Evaluation

評估的話有幾個面向：

1. 這些描述性的模型究竟是不是有意義的描述。
2. 提供的觀察或 Insight 有沒有切入產業核心問題。

這兩個面向都會需要業務端或是提出問題的人才能回答。

Iteration

有些業務端會詬病每次資料分析都要等很久才會出來，或是資料分析的結果沒有用。如果想要讓分析更「敏捷」、更貼近商務需求，在做描述模型時也是需要持續和需求單位保持溝通，不需要等著個報表畫好或是分析結果出來再來討論。

建議可以用小步快跑的方式，例如找到相關的資料就跟需求單位解釋、做出一個大方向就一起討論一下、畫出一兩張圖就同步一下自己的觀察，確認這些資料跟需求單位的商務目的是可以結合，透過分析結果推進商務。