数据产品经理从埋点系统搭建到数据可视化落地

　　这些都是本文作者在数据分析这条路上踩过的坑，作者进行复盘与反思，供大家学习与参考
　　数据是产品的宝藏，数据分析就是产品设计中，挖宝藏的过程。
　　数据分析指导产品设计的这一整套流程，可能是产品经理在产品设计中最享受的部分了。而数据分析的基础就是数据源，数据源一般分为两部分：一部分叫用户行为数据，主要在APP的前后端埋点；另一部分，叫业务数据，一般存储在后台数据库。
　　这两种数据，会随着用户的操作，源源不断地产生。
　　比如：
　　笔者打开了某宝准备买一把键盘，搜索之后，浏览了3页商品，在某一页商品的详情里看到了键盘排行榜的入口。然后，发现排名第一的正是自己这款键盘，于是选型号、加入购物车，最后和本在购物车里的一箱屈臣氏苏打水一起下单、支付，完成购买。
　　这一整套流程，笔者跳转了8个页面，进行了8次点击操作，触发了n次信息流曝光，完成了一次电商线上购物流程，包括购物车收藏、订单确认、订单支付等三个阶段流程。
　　在这个流程中，前后端埋点会按时上报，在极少量损失的情况下，上传到服务器并存储在埋点数据表里。同时，笔者的订单、交易、钱包、会员等相关数据，也因为这次交易的发生，做了相应的变化。
　　APP的产品经理，通过分析笔者这类用户的行为数据，得出了以下结论：
　　用户查看排行榜后，80选择对排行第一的产品进行下单购买，15选择购买排名第二的产品，其它5没有发生购买。（行为数据分析）。
　　笔者在后台被打上了高级用户标签，这种用户人数占活跃用户数的30，但贡献了60的交易额，同时这个标签群体的退货率不到2。（业务数据分析）。
　　84的用户在商品列表页翻页时，最多翻到4页就选择跳出，而最多翻页的用户，剔除极端异常数据后，一般是翻到10页左右。通常搜索结果在10页以上且发生购买的情况下，前五页商品被下单的概率高达88。（行为数据、业务数据结合分析）。
　　于是，产品经理依照分析结论，按照产品优先级，在下一个迭代中加入了排行榜展示及详情维度策略优化等需求，上线后新版本排行榜购买率提升1，GMV同比新增0。02。
　　以上就是数据分析指导产品设计的理想流程，但要实现这种设计流程，可能需要整个研发团队的倾力协作去做好数据体系的搭建。这个过程往往费时费力，且有很多坑。
　　笔者总结了搭建数据体系过程中的三大常见难点，即：
　　埋点流程及体系
　　数据报表及后台
　　数据监控及可视化
　　接下来我们将依次详述。
　　一、埋点流程及体系
　　埋点是数据分析的底层设施。
　　但埋点不是凭空出现的，埋点往往是研发同事一个个做上去的，是有一定开发量的。同时，也需要大量的测试人力来验证；否则，一两个数据指标埋点错乱的话，后续的后果不堪设想。
　　那么有开发量，就代表有需求。
　　埋点的需求，一般来说是随页面需求走的；也就是说，通常不单单要做需求方案评审，还要做埋点评审。由数据产品经理，对每次有页面变更需求的埋点文档进行评审。
　　埋点文档，一般是随需求文档，由需求提出的产品经理来撰写，形式不限。但主要目的是能够标注清楚每一个点位的位置、上报逻辑、上报字段参数。
　　通常有页面跳转关系的，叫页面埋点。即笔者点击商品列表页的商品图片，进入商品详情页，此时APP就要上报这个埋点，假设编号为P02。
　　这个埋点的意思是，笔者从编号为P01的列表页，通过点击商品图片，跳转到编号为P02的详情页。同时，上报字段包括商品的参数goodid。
　　这时通过上报的埋点数据，我们可以知道笔者从哪个页面去到了哪个页面，又查看了哪个商品，从哪个入口进行下一步操作。
　　而APP内不单单有页面跳转，还有同一页面的操作和信息的曝光。
　　当笔者在购物车页面时，发现自己之前添加了一把键盘，但是没有今天看到的喜欢，于是在购物车页面选取那个键盘进行了删除。这个时候，就需要上报事件埋点，并携带被删除商品的goodid及加入购物车时间等参数，假设埋点编号为C01。也就是说，在购物车页面（假设为P03）下，有N个事件。其中，删除事件的埋点编号为C01，上报时携带了删除商品信息等字段。
　　在曝光方面，笔者在浏览商品列表时，并没有把第三页的商品看完，只看到了前三个，还有后3个没有曝光在笔者的手机屏幕上。于是，在笔者手机屏幕停下的时候，一次曝光埋点被上报了，这次上报的商品信息仅包括3个商品，并不包括此页面还没有曝光的后三个。
　　以上我们分别讲述了：埋点文档，以及埋点文档包括的页面埋点、点击事件埋点和曝光事件埋点。
　　通过规范埋点流程、定义埋点需求、完善埋点系统的方式，才能建立起一个APP进行用户行为数据分析的必要底层数据基础。
　　二、数据报表及后台
　　和埋点需求一起确认的，应该还有报表需求，因为两者是相辅相成的。
　　埋点是报表分析的基础，而报表分析提供了埋点的思路和方向。一个产品功能往往承载了指标提升的任务，比如上面说到的排行榜，可能是为了拉升下单转化率。
　　而该目标是否实现，是要靠数据报表来体现的。比如为了衡量排行榜的产品价值，我们可以搭建一个时间维度的报表，字段诸如：排行榜入口曝光量、排行榜引流其它商品量、排行榜跳转购物车量、排行榜直接购买量等。
　　只要产品核心价值不变，往往上述需要定期分析的数据指标就不会变。这个时候，做成报表就会节省很多重复工作，也更加方便跟产品之外的人来汇报，或发定期报表给关联方进行知会。
　　但报表并不是数据分析的全部，还有部分无法固化下来的内容。比如，短期运营活动的数据、ABtest的数据、其它维度的灵活数据分析等。
　　短期运营活动的数据很好理解，一般都周期较短，可能加工成报表的开发时间比活动时间都长，故临时手工支持即可。ABtest也一样，有专门的ABtest分析系统，且动作偏过程化，没有定论，不建议体现在报表中。
　　而其它灵活维度的数据分析，比如新增事件、位置调整等，就需要埋点分析后台来支持，待方案稳定落地后，再逐步提需求到报表中。
　　一般的数据分析后台，比如天眼、神策等，这种平台已经把常用的分析方法和功能沉淀下来了。接入APP后，产品经理可以在管理后台快速上手进行分析。
　　具体的分析维度，要根据目标来定。比如内部产品，可能不需要看留存等数据，更多需要关注漏斗转化和性能，而C端产品，留存分析就重要一些。
　　三、数据监控及可视化
　　除了分析，监控和可视化也是很重要的。
　　数据监控指的是，要定期跑一些数据看看，有没有异常情况发现。比如，每小时跑一下排行榜打开的数据，如果排行榜人均打开次数10次左右，而某天有个别用户单日打开100次，那可能是异常数据，要追查原因了。看看是统计问题，还是机器刷量，再对症下药来解决。
　　可视化通常是在报表基础上，更进一步的表现形式。
　　通常可视化有几种：表达一串操作的衰减情况时，通常采用漏斗模型；表达功能用量或关键数据时，通常采用线装状趋势图，来表达增减趋势情况；分析渠道占比或其它横向类比时，往往采用饼状图，这些都是最基本的可视化形态。
　　更高级的可视化应用有很多，比如我见过的有动线系统。
　　动线起源于商业地产：在商场中，某一个顾客从入口到逛街到购买到出口的全流程，他行动的线路，就叫顾客动线。
　　依据对动线的分析，商场的每一个门店、每一个楼梯、每一个收银台的位置设置都有讲究的，能够最大化用户体验，最大化购物转化率。
　　同样，在APP中用户也存在一定动线。比如用户同样完成一个购买行为，可能是通过列表页详情页购物车付款的动线，也可能是通过活动页详情页直接下单付款的动线。
　　如果能够把这些动线通过可视化的方式展示出来，我们就可以看出动线之间的关系，以及每条动线的优劣势，从而跳脱出现有功能，而从整体规划这个流程的最优动线。
　　类似的可视化手段还有热力图，可以看到用户在某一个页面的点击情况，从而分析出用户的真实操作和我们产品设计的视觉引导之间的关系。如果存在偏差，可以有目的性地来调整视觉和交互。
　　总结
　　数据分析，是有范围和目的性的；也就是说，一个团队要先有数据指导产品设计的需求，才能培养起全员的意识，才能建立起数据分析和埋点的机制，才能建设好底层埋点等设施。
　　埋点的方式，根据页面和场景的不同，采用最合适的方法，其核心是业务目标或用户行为目标的反馈，要从产品价值进行梳理。
　　通过报表、监控和可视化，能够洞察到产品运行中的机会点和优化点，逐步走向最优。
　　如果你作为一个产品经理，想做好团队的数据分析工作，就从以上几项入手吧。
　　希望能够帮到你，感谢阅读。