原创： Kevin改变世界的点滴 Kevin改变世界的点滴
大家好，我是Kevin。这是2019年第102篇原创
你有没有遇到过类似场景，上线后的需求看数据出现上下波动。无法从数据去验证版本成功或失败？
心里万般焦急，好像也无他法。
最近刚好遇到了这样的case，分享下我们在其中遇到的坑。
让产品再跑一会儿
大部分互联网产品在上线前都会经过测试环境再上线。上线后的问题与测试环境也会有出现不一致。上线的问题在测试环境就没有出现过
这时候项目团队除了专注修复BUG,调整优化项外。就是立即增加数据埋点，有一个大体的数据标准。
图片来自网络
我在带团队进入数据埋点，通常会以粗数据开始。比如整个产品的UV、PV，时间唯独以7天到30天的周期来过渡。
上线第一周尤其是产品稳定性或文案、UI还原等问题，会少部分影响用户留存。如果是内容性产品，则内容的准备不足和填充不够，就会造成大量的留存降低。
典型在数据表现上：
第一天快速拉新，但后续用户访问留存下降
产品的回归优化
产品反复迭代，从某个页面到功能。都要考虑产品的全局，换句话说是框架化产品设计。
图片来自网络
高阶的产品经理不仅会从某个移动端的原型考虑，还会考虑公司整个业务线所涉及到的产品与底层服务搭建框架，如上图是一个从数据服务底层到高层的产品表现的框架图。
在产品上线后，尤其是要考虑一些关联模块。
如增加搜索是否支持新内容
如个人中心是否支持新字段
如消息通知是否增加新提示
如用户登录注册是否对应用户之前账户规则
当然在产品0到1期间，可以选择一边上线一边再填需求补上。但这迟早会打乱开发计划和耽误开发排期。
造成资源浪费和赶不上时间线
数据埋点与行为监测
市面上有百度统计、友盟等数据工具都可提供这类支持。我一直比较赞成用数据考虑迭代计划，但一定要考虑埋点的耗损资源、时间的占用都可能是致命的。
所以我更推荐用热力图与页面跟踪的方式，记录用户路径与流转漏斗。知道页面的转化差距。
图片来自网络
最后，产品上线是每一个产品经理熬夜、采坑走的路。每一个案例除了数据其实本身在上线后就可以有一个大概优化反馈。
所以不要怕迭代产品，反而是要考虑数据考核周期与数据资源占用性价比问题。
推荐阅读
2019年，让我们继续前进！
