在公司内部总是有大大小小的提案,每个提案都有拥护的人,但是大家各说各话,没有办法公平的做出决定,这时候我们应该要采用数据驱动 (Data Driven) 的方式做决定,但在那之前,我们就必须做好数据工作。
首先,当然是要先蒐集资料,这里的资料指的不只是像会员资料这种服务器必须存下来的资料,还有像点击了什麽按钮(但是什麽状态都没有改变)这种额外记录的资料,你可能会好奇为什麽已经有必须存下的资料还要再记录一份,因为我们可能会记录谁、在什麽时候、在什麽流程下、在什麽平台、做了什麽事作为一笔资料,这样就多了许多个维度可以观察,例如使用搜寻功能的次数(Y 轴)趋势(X 轴),这边举例一些情境:
对了,埋这些数据是功能未上线时就要做的事,否则可能会遇到资料不乾净的问题,比如,用户更新上有新功能但没有埋数据的版本後,就没有再更新了(可能前一版是强制更新),这样就要额外判断在某个版本之後的数据或是再次强制更新了。
当然,除了 app 内的数据,也有不同的数据蒐集方法:
总之从微观到宏观的方法都有,调查方式应该取决於想要得到什麽类型的资料。
数据蒐集後,我们有一大堆看起来很没用的数据,可能还散落在不同的资料库、资料表,我们应该要建立自己的 dashboard 来追踪我们在意的指标的趋势:例如会员数、月活跃使用者(MAU)、每日下载量/播放/点阅量、商店评分与留言等,也就是把蒐集来的数据做成可以一眼就看出趋势好坏的图表,并由机器不断更新。
也就是说,资料视觉化是帮助我们观察不同事件带来的成效,并了解我们的处境。
资料视觉化的工具也有很多,能支援不同资料库来源,从云端资料库服务到手动上传 csv 格式都有,也能产出各类图表,但可能需要自己下查询语法。
每个部门在意的指标不同,所以不同部门应该会有不同的 dashboard,而产出的 dashboard 应该要放在公共的区域,让经过的同事、甚至是不同部门的同事都能看见,每个人对这些走势都有不同见解,经常会引起讨论。
这边介绍几个资料视觉化工具:
数据分析是最有趣但也最复杂、困难的一环,它可以说是最有价值的,让我们知道下一步要往那里走。
首先,我们应该要以公司的价值、策略方向为前提出发,接着找出 dashboard 上有问题、趋势不理想、甚至只是成长力道不够的数据,或是自己想问题,这个时候,我们会发现 dashboard 上的图表往往不够,所以会再根据我们的问题、猜测,再下查询语法验证。
基本会怀疑的一些面向,例如:
我们也可以用 user story、user journey 等方法来找原因。
要注意的是,有没有其他可能呢?会不会被数据或自己的理解所欺骗,毕竟这些理解有时候是很主观的,一个人就有好几种理解,不同人的理解还不重叠,需要小心验证。
每家公司面对的课题不同,没有一个公式或 SOP 可以套用,这边分享一些思路:
要注意使用者是不是能接受这些改动,如果是比较久或是使用者众多的服务,通常也会有避免较大改动,怕影响使用者既有习惯的包袱,这时候我们也许可以尝试 A/B 测试 或发布早期测试的做法,来避免大量客诉与负评。
另外,别忘了观察其他环节的影响,比如,如果让使用者去用某个功能,是不是也可能造成其他既有功能的使用时间变短。其他还有黏着度、转换率、广告效益等影响。
不管我们是上架了一个完美的 app,有着大量的付费用户、良好的商业模式,甚至拿到了投资,又或是一个乏人问津的 app,我们都不会知道下一步在哪里。
当然,并不是有了数据就会知道,但有了数据就像看到前方或是自己脚下所踩的地方,要伸一只脚还是用跳的,要踩多大力,都让我们做出更安全有效率的选择。
Generics 可以在我们定义型别时给予其他对於型别的资讯,例如说我们因为不确定会传进 funct...
Day 30 - 这不是篇完赛废文,我是认真发完最後一天!! 今天这篇其实是一直想做的整理拉,因为前...
插入图表 插入图表的方式有2种 1.右键插入图表(Image) 2.从Toolbox拖拉图表过来 再...
⚠行前通知 先前已经学过Python但想学爬虫的人可以回来罗~ 从今天起就开始大家最期待的网页爬虫的...
物件导向的继承(inheritance)特性 继承 为物件导向程序设计的特性之一,子类别 (subc...