趁着有时间将自己做过的产品进行复盘思考。本篇以曾经做过的一款产品--XXX健康周报为例，记录产品需求实现后通过数据分析问题进行的迭代。市面上的产品文档有很多，我所写仅仅是对自己工作的随性简要记录。
健康周报目的
引导关注电脑周健康状态。
1.展示个人电脑状态，
2.与同类型电脑的对比产生竞争和对比，PK
3.推测用户职业，引导用户修正，与用户产生互动
展现形式
H5形式。建议页面设计的活泼一些。产品文档展示功能为主，设计实现可以多方考虑。
健康周报与账号
周报展示设备状况，不与LID关联
周报内容
1.周设备整体概况
aCPU温度
b内存占有率
c开机时长
d总结性话术
2.CPU，内存使用，开机时长的使用曲线
3.最常使用的管家功能
4.最常使用的软件
周报弹出条件
1.一周最少要有2 天有效数据（若某天的数据无体检分则为无效数据，不上报）；
2.从菜单显示健康周报，显示最近一周有效记录（若从来都没有过周报，则提示从未有过；若最近一次的在 2 周前，则提示已超过 2周未体检）
周报业务流程
周报功能描述
如上为V1版本周报上线时产品需求，业务逻辑规则、后端逻辑、数据上报等没有展示出来。在V1版本上线后，由于指定的规则比较严苛，导致仅有1%不到的用户点击此功能，虽然用户反馈普遍评价不错，但是数据量一直低。通过漏斗模型分析很快就发现问题出在哪里，由于对生成周报条件的限制导致生成周报的用户数少，自然弹出和点击就少。总结V1版本存在的问题：
1.需要用户去手动操作才可生成周报；
2.对各项数据的上报进行严格要求，但凡有一项数据存在问题即不符合上报条件；
3.界面存在数据加载异常的bug。
也是由于我们上述严格条件的限制，找到问题所在后，于是我们进行了V1.2的版本，主要从优化数据生成和上报方向进行着手。在V1.2更新发布后，数据点击量从1%提到到5%，虽有提升，但是依然很低，数据有了，生成条件也优化了，为什么数据还是很低呢。
在更新V1.2版本后，并未放弃对数据的分析，虽然符合弹出条件的用户和实际弹出的用户是匹配的，但是与产品的活跃用户却存在差距，通过我们产品本身的反馈系统联系到未弹出周报的用户，跟用户详细了解情况后发现：周报所需数据用户并不会主动触发（此项操作关系到生成周报的数据），周报是一个惊喜型的需求，对用户来说会产生惊喜，但是至于如何触发这种惊喜并不关心，也不会去主动触发。为用户提供使用产品的惊喜感是需要产品本身去考虑的。
由此我们也发现了产品本身存在的一些问题，作为工具类产品，为用户提供惊喜感和我实际提供出来的惊喜是存在差距的，而这种差距单凭数据是看不出来的，还需要用户调研和回访，尤其是安全管家类的工具产品，既然存在就应该主动去保护设备安全，而不需要用户再去操作。
在此基础上我们进行了V1.3版本的优化，即增加对用户设备的智能化操作，在征得用户同意的基础上，在用户使用设备时进行主动操作，无需用户再点击。类似运动手环类APP在获得用户访问权限基础上，无需用户再去点击开始记步就可以自动记录步数。经过此次优化，数据点击率提升到10%+。至此，我们算是解决了数据源头的问题。在数据获取源头的基础上也通过数据分析对周报内容进行了迭代优化。
如上是从产品的数据层面，结合用户反馈对产品进行的分析，找出产品存在的问题，并寻找解决方案。如今周报已经走过V1.X.X的系列迭代，进入V2的产品定义和规划，将会接入更多智能化的服务和体验，期待上线后的反馈。
