截止到2017.9.25号，离开了大本营UC浏览器。从UC两年多时间里面，作为一名iOS开发者，除了专业技术得到提高外。产品意识也得到加强，这篇文章主要就是记录在这两年里面学到的一些产品意识以及分析的方法。欢迎各位拍砖～
流量
流量是衡量一个App好坏的一个关键指标。产品们每天都分析数据，经常会到三个基本的问题：
- 流量为什么涨
- 流量为什么跌
- 流量为什么涨不上去
用数据量化说明问题的产品，我觉得他算是一个牛逼的产品。
流量的拆解
- DAU 日去重活跃设备数
- MAU 月去重活跃设备数，一般取近30天去重活跃设备数
- 活跃率 DAU/MAU，反映的是用户使用APP的频次
DAU是产品关注的最核心指标，每天到公司，别说产品，连我都习惯看一下每天的DAU。说到DAU，不同的app属性不一样。有些app天生就属于高频的应用，如：wechat, 今日头条等。天生低频的应用，如：地图等。
提升app的DAU，需要从MAU和活跃率进行拆解。
DAU = MAU * 活跃率
提升MAU
- 本月新增 ：重在扩大规模，例如：夸克浏览器和zealer 合作，引入新用户。通过ASO排名提高app 的下载量。
- 上月留存 ：让用户感受到产品的核心价值，提升用户黏性，留住用户。
- 历史回流 ：通过某种手段召回流失的用户，例如：红包活动，Doodle
提升活跃率
提升活跃率也就是我们说的提活，而提活需要综合各方面的条件，制定出针对性的提活策略。活跃率可以从以下几点进行拆解：
- 流量来源：包括主动打开app，分享，Notification等
- 时段：分析在某一时间段内的UV变化
- 周期因素： 节假日等。例如：开学的时候，夸克浏览器和UC浏览器的日活都下跌，次日慢慢恢复。
从7月份到8月份，夸克浏览器的增长放缓。在这个阶段，需要关注如何扩展场景提升用户使用app的频次，提供有价值的内容提升用户的使用时长，优化流程提高用户的转化。
衡量指标：人均使用时长，人均启动次数，人均PV
流量的引入
流量的引入是app规模增长的主要途径。主要的手段有：
- 苹果的ASO
- 安卓的各大应用商店的投放
- App 软文推广
- App之间的导流
- 线下推广活动
另外需要注意的一点是，流量引入的监控。流量引入的监控是衡量各渠道的投放质量以及财务结算的关键。监控手段主要有：
- 反作弊系统 ： 防止恶意刷量行为
- 拉新质量评估系统 ：主要通过渠道用户的次日留存率反应拉新质量
- 渠道价值评估：夸克浏览器有一次的推广渠道是工厂渠道，留存率相当的低，用户质量也非常低
其中反作弊系统需要技术层面的支持，复杂程度是三个里面最高的
产品数据分析
数据打点基本上是每一个app都会有的，其主要目的是利用数据来驱动，优化设计。
用数据来监控产品，能了解到用户的使用情况，如发现某个功能的转化率/留存率低，可能代表存在一些问题，通过分析提出解决问题的方案。
另外，在产品迭代的环节中，用户通过使用产品产生相关的用户行为数据，透过观察这些数据，来了解迭代对产品本身起到的作用，验证改版是否有效，并做为后续迭代优化的方向。
数据分析的流程如上图，需要注意的有几点：
- 数据的分析必须有明确的，可落地的目的
- 明确分析的可行性，挖掘相关的数据
- 从数据上说明问题，不能带着结论去理解数据
- 根据数据分析的结果，回顾最初的问题并预测下阶段的可能性
功能优化-GSM
GSM模型是Google提出的一种指标体系，它是用来量化用户体验的。
GSM分别为目标（Goal）→信号（Signal）→指标（Metric），所以也简称GSM模型。
- 目标 ：用户的目标或者功能设计的目标是什么
- 信号 ：与目标密切相关的，实现目标或者未实现目标，相关的现象是什么
- 指标 ：对信号进行量化
在夸克浏览器中，自己也曾经对搜索效率的提高这么分析过。如下图所示：
用户体验评估
每次的需求评审或者变更，都离不开这个话题：对用户体验的影响。在夸克浏览器，产品的需求也经常被质疑这一点。那么用户体验评估，是否有某一套路可循？
Google了一下，用户体验评估模型还真有，比较知名的是Google的HEART模型。具体资料可自行查阅，这里说关键几点。该模型主要有以下几个目标：
- 吸引度 ：获取用户的注意力，引发用户感兴趣并产生尝试的欲望
- 完成度 ：用户被吸引过来后，能不能很好的完成任务，以及操作效率，成功率如何
- 满意度 ：用户操作之后，主观体验如何
- 忠诚度 ：用户使用完产品之后是否会继续使用
- 推荐度 ：用户是否愿意分享给其他人
以上目标对应的信号和指标（图片来自网络）：
看到上图的指标，令我想起一年前，通过用Charles抓包看今日头条里面涉及到的一些统计相关的数据，模糊记得里面有以下几点：
- 阅读时长
- 页面停留时长
- 滑动相关的统计
- 还有就是一些用户画像相关的数据
今日头条的推荐做得这么好，不知道是不是运用HEART模型来分析用户。who knows ?数据能表现出产品的现况，但是很多问题也不是光看数据就可以发现的。
需求开发
产品需求
正如我上面所说，我是一位iOS开发者。很多时候潜意识的从技术的角度替用户着想。导致以下两种结果：
- 这个功能很容易实现，开发成本很低，马上做好
- 这个功能开发成本很高，难实现。但是有一个替代的方案，就是用起来会增加用户使用成本，但是可以解决问题。
这样是有问题的，一方面很容易实现了一堆用户不需要的功能，另一方面很大可能损害了原有的用户体验。站在用户的立场思考，首先要考虑用户的需求，这个过程先不要考虑技术实现问题，从而可以避免上面提到的两种情况。
需求有可做可不做的，也有必须做的。对于必须做的，就算成本很高也必须做掉；对于可
做可不做的，就算成本很低，也绝对不能做。
技术需求
技术需求一般都是以解决某一类问题驱动的，开发者很容易把问题的解决办法和app实际情况耦合在一起。这样就会出现以下的问题：
- 技术需求解决了某一类问题，但是前提是在当前开发的app 内
- 技术需求缺失公用性，无法产品化
当接到技术需求的时候，首先考虑的是解决问题的普遍性，然后在普遍性的基础上再思考如何结合产品去解决实际问题。在做安装包大小瘦身的时候，其中某一种方法因为耦合了UC浏览器的相关逻辑，导致缺乏公用性，其他app要复用这套方案的时候，只能抽离或重写。
程序员要学会将自己的工作效果最大化，最简单的途径就是把技术需求对外输出，成为一种产品化的技术需求。
需求的天时，地利，人和
- 天时 ：外部有强烈的需求 （对方团灭，我方有龙或者小兵）
- 地利 ：依赖基础设施，配套的工具 （对方只剩下高地塔）
- 人和 ：需求涉及到多方合作的时候，需要确保团队是否已经准备好了。（开团的时候少了坦克，河都过不了呀）
- 夸克浏览器的一次推广活动，因为iOS端上架的问题以及推广活动本身存在的一些问题，导致推广效果比较差。
- 曾经有位同事花了3周的时间封装了一套数据库的SDK，结果只有自己做的的业务用了。其他业务根本没人用，导致就这么死掉了。
