[Day 14] 资料产品生命周期管理-描述型模型

特别把描述模型和预测模型分开来写是因为两者在开发与验证阶段有不小的差异。
https://ithelp.ithome.com.tw/upload/images/20210915/20141140L25gveUqBq.png
(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

有些业务端会诟病每次资料分析都要等很久才会出来,或是资料分析的结果没有用。如果想要让分析更「敏捷」、更贴近商务需求,在做描述模型时也是需要持续和需求单位保持沟通,不需要等着个报表画好或是分析结果出来再来讨论。

建议可以用小步快跑的方式,例如找到相关的资料就跟需求单位解释、做出一个大方向就一起讨论一下、画出一两张图就同步一下自己的观察,确认这些资料跟需求单位的商务目的是可以结合,透过分析结果推进商务。


<<:  13. 关於 IIFE 的 4 题练习

>>:  EP02 - 配置本机虚拟机械并安装 AWS-CLI

24 让画面跟游戏联动

用 PubSub 更新游戏状态 现在我们要让玩家订阅游戏的状态 并让游戏在状态更新的时候,广播到双方...

【把玩Azure DevOps】Day29 再次建立Release pipeline:多个不同Artifacts来源

前面的文章建立过了Release pipeline,但是那次并没有加入多个不同的Artifacts来...

【Day15】公园跟你家院子—全域变数与区域变数的区别

JavaScript的变数依使用的切分范围(作用域)可以分为两种: 区域变数 全域变数 前面提到透...

JS 15 - this 关键字

大家好! 要写到今天也真是不容易呢!明天就要从 50% 开始了! 我们进入今天的主题吧! 严谨模式 ...

[2021铁人赛 Day-01] 前言 and 嵌入式系统简介

前言 大家好,我是 Kevinyu,就像我的参赛题目所描述的 虽然学习资讯领域的相关知识,也碰过树梅...