今天读了《决战大数据》中的养数据、混通晒和存管用，记录下读后感：
如何“养”数据 养数据就是收集数据，目前我们的思路是一致的，都是根据问题去收集数据。 比如，我们这次PC和M站点埋点需要解决的问题是： 对比推广渠道质量； 分析不同留资类型转化率； 分析用户使用择居网的行为路径； 分析留存情况； 为后续改版提供数据支持； 车品觉提出的“数据是有生命周期的”这个概念还是蛮有收获的，比如身高、体重在成年之前变化很快，需要注意时效性；也比如我们的用户的购房需求在他不了解购房政策、没搞明白市场情况、没想清楚个人购房目的之前在网站上产生的浏览或搜索记录对最终的推荐也只能是参考。 — 产品也是有生命周期的，即使有长远规划，也不应过度设计，满足阶段性需求，并留出扩展性即可
数据的颗粒度个人还是倾向于越细越好，比如书中提到的生日是否应该收集到时分秒，如果从计算年龄的角度，时分秒确实没有意义；但如果是从聊天话题的角度，当双方发现自己都是在上午11:30出生的，那种莫名的亲切感会油然而生。
当然，车品觉也强调“小”不是指数据量，而是指应用的目标很具体； “小”是指从小角度切入，从小做起（不要一开始设计过于复杂的框架，针对具体问题去设计，不用过度担心扩展性）； — 这点很认同
总的来说，个人认为收集数据和设计产品一样，不过度设计，留出扩展余地，根据当下需求尽可能的收集更多更细的数据； 评估数据收集好坏的方法：数据有没有、细不细、全不全、稳不稳、快不快。
对于“混、通、晒”的理解 对于“混”这个话题，我到觉得不同的阶段有不同的做法，书中列举了和业务人员一起吃饭、参加业务部门的周会、业务规划讨论会或头脑风暴，这些我也觉得是有意义的，但要看投入回报比，比如我们现在的产品部门是严重缺人，对业务部门主动反馈过来的需求都处理不完，所以很难在现在这个阶段去参加业务部门的头脑风暴、业务规划或部门会议，我现在对支持业务部门反馈问题的计划是这样的： 所有人员无论是在群里、电话里或单聊反馈的线上产品不能使用的问题，无论研发团队是否是休息状态，都需要马上解决（测试负责人验证、跟进并反馈）； 如果反馈的是需求和产品优化建议，产品先收集，然后每周统一整理分析； 产品也会每周安排一天时间专门和各业务部门对接一次需求
产品部门半封闭后，和业务部门的协作方式如下： 周一 到公司汇报上周工作进展、本周工作计划、后续需要讨论的原型及产品委员会会议； 周二 到公司和各业务部门负责人面对面或电话方式沟通之前收集到的需求和咨询业务相关的问题 周三 在封闭地，内部讨论产品需求、原型、规划等 周四 在封闭地，设计后续迭代产品的规则、流程、原型和设计稿； 周五 在封闭地，内部验收产品相关输出，并计划下周或后续工作内容；
在“通”这方面，需要做的一些事情： 用户行为数据和业务数据的打通； 第三方展点消数据和转化数据的打通； 历史其他业务积累数据（比如电信数据）和业务数据的打通；
之前看到马云预测双十一成交额的时候，还觉得预测的那么准，难道数据是造出来的，现在明白了： 大促成交额预估 = 预热期加入购物车的商品数商品单价经验转化率*经验成交额占比
书中列举的一个“晒”的案例，“二手闲置”业务的案例，非常有参考价值，简直可以成为我们以后分析择居网数据的范式： 分析留资转化漏斗，找出流失率高的环节并优化； 分析渠道留资转化率，优化来源渠道； 分析不同留资类型的转换率，优化引导流程； 所有分析应该基于不同用户群分析；
关于数据的“存、管、用” 数据的灾备方面，咱们使用的都是第三方服务，包括阿里云的RDS、ADS，还有BDP与诸葛IO，都提供了数据备份机制； 以后设计产品的依据优先级为： 参考竞品与大众产品； 分析用户行为数据； 逻辑推理与理论分析（理论包括用户心理学、消费行为学、设计规范等）； 所有产品设计的前提，是要明确用户群、使用场景和痛点。
书中也提到了用户标签化的三种方法： 通过业务规则结合数据分析来建立标签 — 专家系统（我们正在使用的方法） 通过模型来建立便签 — 智能化（后续计划使用的方法） 通过模型组合来生成新的标签 — 模型成熟后可以使用的方法 在数据化思考里，又一次强调了细分指标的重要性，列举了提高成交额可以细分的指标：日均UV、浏览转化率、购买转化率、笔单价、人均笔数。
几个分析数据的理念 每天看的数据不应该太多； 数据泛化：把分析的理念和框架变成一个数据产品，本质上是一个数据泛化的过程；– 不明白泛化在这里是什么意思？ 数据分析步骤：数据描述->数据诊断->探索预测；
产品上的一点小总结：任何新功能都是再改变用户以前的习惯（没有这个新功能，他也有办法解决），所以做任何功能都要说出比之前方案好的地方。
书中提到的一些好听的产品名字 观星台 地动仪 西湖品学 黄金策 生意参谋 数据魔方 量子报告
始发于简书：nextbang
相关阅读
