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

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

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

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

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

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

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

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

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

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

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

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

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

1. 埋点流程及体系

2. 数据报表及后台

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

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