既然是分享数据产品经理的认识囷理解那我们就从专业的数据角度来进行分析和复盘，一起来看看数据产品经理从埋点系统搭建到数据可视化落地的日常工作流程

先仩一张数据产品经理非常常见的后台系统截图：

数据是产品的宝藏，数据分析就是产品设计中挖宝藏的过程。

「数据分析指导产品设计」的这一整套流程可能是产品经理在产品设计中最享受的部分了。而数据分析的基础就是数据源数据源一般分为两部分，一部分叫用戶行为数据主要在APP的前后端埋点；另一部分，叫业务数据一般存储在后台数据库。

这两种数据会随着用户的操作，源源不断地产生比如：

我打开了某宝准备买一把键盘，搜索之后浏览了3页商品，在某一页商品的详情里看到了键盘排行榜的入口然后发现排名第一嘚正是自己这款键盘，于是选型号、加入购物车最后和本在购物车里的一箱屈臣氏苏打水一起下单、支付，完成购买

这一整套流程，峩跳转了8个页面进行了8次点击操作，触发了n次信息流曝光完成了一次电商线上购物流程，包括购物车收藏、订单确认、订单支付等三個阶段流程

在这个流程中，前后端埋点会按时上报在极少量损失的情况下，上传到服务器并存储在埋点数据表里同时，我的订单、茭易、钱包、会员等相关数据也因为这次交易的发生，做了相应的变化

APP的产品经理，通过分析我这类用户的行为数据得出了以下结論：

1. 用户查看排行榜后，80%选择对排行第一的产品进行下单购买15%选择购买排名第二的产品，其它5%没有发生购买（行为数据分析）

2. 我在后囼被打上了高级用户标签，这种用户人数占活跃用户数的30%但贡献了60%的交易额，同时这个标签群体的退货率不到2%（业务数据分析）

3. 84%的用戶在商品列表页翻页时，最多翻到4页就选择跳出而最多翻页的用户，剔除极端异常数据后一般是翻到10页左右。通常搜索结果在10页以上苴发生购买的情况下前五页商品被下单的概率高达88%。（行为数据、业务数据结合分析）

于是产品经理依照分析结论，按照产品优先级在下一个迭代中加入了「排行榜展示及详情维度策略优化」等需求，上线后新版本排行榜购买率提升1%GMV同比新增0.02%。

以上就是数据分析指導产品设计的理想流程但要实现这种设计流程，可能需要整个研发团队的倾力协作去做好数据体系的搭建往往费时费力，且有很多坑

笔者总结了搭建数据体系过程中的三大常见难点，即：

3. 数据监控及可视化

接下来我们将依次详述

埋点是数据分析的底层设施。

但埋点鈈是凭空出现的埋点往往是研发同事一个个做上去的，是有一定开发量的同时，也需要大量的测试人力来验证否则，一两个数据指標埋点错乱的话后续的后果不堪设想。

那么有开发量就代表有需求。

埋点的需求一般来说是随页面需求走的。也就是说通常不单單要做需求方案评审，还要做埋点评审由数据产品经理，对每次有页面变更需求的埋点文档进行评审

埋点文档，一般是随需求文档甴需求提出的产品经理来撰写，形式不限但主要目的是能够标注清楚每一个点位的位置、上报逻辑、上报字段参数。

通常有页面跳转關系的，叫页面埋点即，我点击商品列表页的商品图片进入商品详情页，此时APP就要上报这个埋点假设编号为P02。这个埋点的意思是峩从编号为P01的列表页，通过点击商品图片跳转到编号为P02的详情页，同时上报字段包括商品的参数good_id。这时通过上报的埋点数据我们可鉯知道我从哪个页面去到了哪个页面，又查看了哪个商品从哪个入口进行下一步操作。

而APP内不单单有页面跳转还有同一页面的操作和信息的曝光。

当我在购物车页面时发现自己之前添加了一把键盘，但是没有今天看到的喜欢于是在购物车页面选取那个键盘进行了删除。这个时候就需要上报事件埋点，并携带被删除商品的good_id及加入购物车时间等参数假设埋点编号为C01。也就是说在购物车页面（假设為P03）下，有N个事件其中，删除事件的埋点编号为C01上报时携带了删除商品信息等字段。

在曝光方面我在浏览商品列表时，并没有把第彡页的商品看完只看到了前三个，还有后3个没有曝光在我的手机屏幕上于是，在花生酱手机屏幕停下的时候一次曝光埋点被上报了，这次上报的商品信息仅包括3个商品并不包括此页面还没有曝光的后三个。

以上我们分别讲述了：埋点文档以及埋点文档包括的页面埋点、点击事件埋点和曝光事件埋点。通过规范埋点流程、定义埋点需求、完善埋点系统的方式才能建立起一个APP进行用户行为数据分析嘚必要底层数据基础。

和埋点需求一起确认的应该还有报表需求，因为两者是相辅相成的

埋点是报表分析的基础，而报表分析提供了埋点的思路和方向一个产品功能往往承载了指标提升的任务，比如上面说到的排行榜可能是为了拉升下单转化率。而该目标是否实现是要靠数据报表来体现的。比如为了衡量排行榜的产品价值我们可以搭建一个时间维度的报表，字段诸如：排行榜入口曝光量、排行榜引流其它商品量、排行榜跳转购物车量、排行榜直接购买量等

只要是产品核心价值不变，往往上述需要定期分析的数据指标就不会变这个时候，做成报表就会节省很多重复工作也更加方便跟产品之外的人来汇报，或发定期报表给关联方进行知会

但报表并不是数据汾析的全部，还有部分无法固化下来的内容

比如，短期运营活动的数据、ABtest的数据、其它维度的灵活数据分析等短期运营活动的数据很恏理解，一般都周期较短可能加工成报表的开发时间比活动时间都长，故临时手工支持即可ABtest也一样，有专门的ABtest分析系统且动作偏过程化，没有定论不建议体现在报表中。而其它灵活维度的数据分析比如新增事件、位置调整等，就需要埋点分析后台来支持待方案穩定落地后，再逐步提需求到报表中

一般的数据分析后台，比如天眼、神策等这种平台已经把常用的分析方法和功能沉淀下来了，接叺APP后产品经理可以在管理后台快速上手进行分析。具体的分析维度要根据目标来定。比如内部产品可能不需要看留存等数据，更多需要关注漏斗转化和性能而C端产品，留存分析就重要一些

除了分析，监控和可视化也是很重要的

数据监控指的是，要定期跑一些数據看看有没有异常情况发现。比如每小时跑一下排行榜打开的数据如果排行榜人均打开次数10次左右，而某天有个别用户单日打开100次那可能是异常数据，要追查原因了看看是统计问题，还是机器刷量再对症下药来解决。

而可视化通常是在报表基础上，更进一步的表现形式

通常可视化有几种：表达一串操作的衰减情况时，通常采用漏斗模型；表达功能用量或关键数据时通常采用线装状趋势图，來表达增减趋势情况；分析渠道占比或其它横向类比时往往采用饼状图，这些都是最基本的可视化形态

更高级的可视化应用有很多，仳如我见过的有动线系统

动线起源于商业地产，在商场中某一个顾客从入口到逛街到购买到出口的全流程，他行动的线路就叫顾客動线。依据对动线的分析商场的每一个门店、每一个楼梯、每一个收银台的位置设置都有讲究的，能够最大化用户体验最大化购物转囮率。

同样的在APP中，用户也存在一定动线比如用户同样完成一个购买行为，可能是通过列表页-详情页-购物车-付款的动线也可能是通過活动页-详情页-直接下单-付款的动线。如果能够把这些动线通过可视化的方式展示出来我们就可以看出动线之间的关系，以及每条动线嘚优劣势从而跳脱出现有功能，而从整体规划这个流程的最优动线

类似的可视化手段还有热力图，可以看到用户在某一个页面的点击凊况从而分析出用户的真实操作和我们产品设计的视觉引导之间的关系，如果存在偏差可以有目的性地来调整视觉和交互。

数据分析是有范围和目的性的。也就是说一个团队要先有数据指导产品设计的需求，才能培养起全员的意识才能建立起数据分析和埋点的机淛，才能建设好底层埋点等设施

埋点的方式，根据页面和场景的不同采用最合适的方法，其核心是业务目标或用户行为目标的反馈偠从产品价值进行梳理。

通过报表、监控和可视化能够洞察到产品运行中的机会点和优化点，逐步走向最优

如果你作为一个产品经理，想做好团队的数据分析工作就从以上几项入手吧。

希望能够帮到你感谢阅读。

转载自公众号：产品之术

最后摹客为产品经理和产品团队送一份福利，产品经理高效沟通离不开原型为各位产品大大自荐，更快更简单5分钟制作一个交互原型页面！比Axure快三倍，支持团隊协作和在线审阅更多实用、易上手的功能，包括：

• 海量现成的图标（3000+）和组件（200+）快速构建原型；
• 交互设计完全可视化，直接拖拽鼠标设置组件或页面交互简单又直观；
• 支持脑图及页面流程图模式，快速构思、预览及设计原型模块；
• 支持Sketch导入可导出Mockplus项目文件，或矗接发布为Mockplus云项目

【福利】小摹为大家准备了摹客Mockplus的个人版15天激活码。诚邀体验！数量有限先到先得！

• 激活数量：限量150个
• 激活地址： （登录/注册后输入激活码即可）