特别把描述模型和预测模型分开来写是因为两者在开发与验证阶段有不小的差异。
(https://ubiq.co/analytics-blog/create-operational-dashboard-business/)
起始阶段有几件事要确认
商业意图是否明确:商业意图不是只明确的需求,而是他想利用这个模型做什麽。例如「想知道公司的使用者面貌」,这只能算是需求;「想根据不同使用者面貌做差异性行销」这样才是商业意图。因为使用者可能会提出无法满足商业意图的需求,这时候做了也是白做,所以最重要的事情就是确认商业意图。
需求:例如是想知道使用者 Profile 分布、人数趋势、还是看热门排行。如果商业意图还不明确的话,就还需要在回到上一步多着墨,至少要需要变成一个比较明确方向的问题,才有办法往下走。
资料来源是否足够:这关乎到「能不能回答问题」,如果资料不够就要再回到上一层(原始资料)去寻找可以回答问题的资料。
只要问题明确,描述型的模型设计起来相对单纯,只要先确立:
这样我们就可以透过相对的描述统计图表来呈现关注的议题。
在做 Implement 的时候,通常都是透过图表的方式来呈现结果,一些图表设计要注意的东西,之前也有提过一点。重点是要让分析故事讲起来有逻辑。通常也是有公式的:
技术上来说有很多 BI 工具像是 tableau、Redash、PowerBI、Excel 等可以做到,不会是本篇的重点就跳过了。
因为是描述行模型,部署指的就是将结果呈现给使用者。呈现的方式可以做成所谓「战情报表」、「监控仪表板」、或是简报的方式呈现。(如果是简报通常不会纯粹呈现、而是会带上分析师对於内容的观察和见解。)
评估的话有几个面向:
这两个面向都会需要业务端或是提出问题的人才能回答。
有些业务端会诟病每次资料分析都要等很久才会出来,或是资料分析的结果没有用。如果想要让分析更「敏捷」、更贴近商务需求,在做描述模型时也是需要持续和需求单位保持沟通,不需要等着个报表画好或是分析结果出来再来讨论。
建议可以用小步快跑的方式,例如找到相关的资料就跟需求单位解释、做出一个大方向就一起讨论一下、画出一两张图就同步一下自己的观察,确认这些资料跟需求单位的商务目的是可以结合,透过分析结果推进商务。
>>: EP02 - 配置本机虚拟机械并安装 AWS-CLI
用 PubSub 更新游戏状态 现在我们要让玩家订阅游戏的状态 并让游戏在状态更新的时候,广播到双方...
前面的文章建立过了Release pipeline,但是那次并没有加入多个不同的Artifacts来...
JavaScript的变数依使用的切分范围(作用域)可以分为两种: 区域变数 全域变数 前面提到透...
大家好! 要写到今天也真是不容易呢!明天就要从 50% 开始了! 我们进入今天的主题吧! 严谨模式 ...
前言 大家好,我是 Kevinyu,就像我的参赛题目所描述的 虽然学习资讯领域的相关知识,也碰过树梅...