这些都是本文作者在数据分析的道路上踩过的坑。 笔者进行回顾与反思，供大家学习参考。
数据是产品的宝藏，数据分析是产品设计中挖掘宝藏的过程。
“数据分析指导产品设计”的整个过程，可能是产品经理最享受的产品设计环节。 数据分析的基础是数据源，数据源一般分为两部分：一部分称为用户行为数据，主要嵌入在APP的前后端； 另一部分称为业务数据，一般存储在后台数据库中。
这两种数据会随着用户的操作不断产生。
例如：
笔者打开某宝购买键盘。 搜索后浏览了3页商品，在某页商品详情中看到了键盘排行榜的入口。 然后，我发现排在第一位的键盘是我自己的，于是我选择了型号，加入了购物车，最后在购物车里用Ben的那盒屈臣氏汽水下单，付款，完成了购买。
在这整个过程中，笔者跳转了8个页面，进行了8次点击操作，触发了n次信息流曝光，完成了一个电商网购流程，包括购物车提取、订单确认、订单支付。 阶段过程。
在此过程中，前后端埋点会按时上报，在损失很小的情况下，会上传到服务器，存储在埋点数据表中。 同时，作者的订单、交易、钱包、会员等相关数据也因本次交易的发生而发生相应变化。
该APP的产品经理通过分析与笔者一样的用户行为数据，得出以下结论：
因此，产品经理根据分析结论和产品优先级，在下一次迭代中增加了“排行榜展示和详细维度策略优化”等需求。 上线后，新版排行榜购买率提升1%，GMV同比提升0.02%。
以上是数据分析指导产品设计的理想流程，但要实现这个设计流程，可能需要整个研发团队的通力合作，构建数据体系。 这个过程往往费时费力，而且陷阱很多。
笔者总结了数据系统搭建过程中常见的三个难点，即：
埋地过程和系统数据报表及后台数据监控和可视化
接下来我们将依次详述。
1. 埋入式工艺及系统
埋点是数据分析的底层设施。
但是埋点并不是凭空出现的。 埋点往往是研发同事一个一个做出来的，有一定的开发量。 同时，也需要大量的测试人力去验证； 否则，一两个数据指标埋错了，后果不堪设想。
然后有开发量，就是有需求。
埋点要求一般遵循页面要求； 也就是说，通常不仅是需求计划评审，还有埋点评审。 数据产品经理将审查每个页面更改要求的嵌入文档。
埋文件，一般都附有需求文件，是提出需求的产品经理写的，形式不限。 但主要目的是为了能够清楚地标明每个点的位置、上报逻辑、上报字段参数。
通常存在页面跳转关系，称为页面埋点。 即作者在商品列表页点击商品图片进入商品详情页。 这时APP会报这个埋点，假设编号为P02。
这个埋点是指作者从列表页P01点击商品图片跳转到详情页P02。 同时，报告字段包括商品的参数good_id。
这时候通过上报的埋点数据，我们就可以知道作者从哪个页面去了哪个页面，查看了哪个产品，从哪个入口进入下一步。
在APP中，不仅有页面跳转，还有同一个页面的操作和信息曝光。
笔者在购物车页面的时候，发现之前添加了一个键盘，但是今天看到的不喜欢，于是在购物车页面选择了那个键盘，将其删除。 此时需要上报事件埋点，携带被删除商品的good_id、加入购物车的时间等参数，假设埋点编号为C01。 即在购物车页面（假设为P03）下，有N个事件。 其中购物商城网站 一个商品应该具备哪些字段，删除事件的埋点编号为C01，报表中包含删除的商品信息等字段。
曝光度方面，笔者在浏览产品列表时，第三页的产品并没有看完，只看到了前三款，而后三款并没有曝光在我的手机屏幕上。 所以笔者手机屏幕一停，就报出了一个曝光埋点。 此次上报的产品信息仅包含3款产品，不包含本页面未曝光的最后三款产品。
上面我们分别描述了：埋点文件，埋点文件包括页面埋点、点击事件埋点和曝光事件埋点。
通过规范追踪流程、定义追踪需求、完善追踪系统，可以为APP分析用户行为数据建立必要的底层数据基础。
二、数据报告及背景
确认与埋点要求一起，还要有报告要求，因为两者相辅相成。
埋点是报表分析的基础，报表分析为埋点提供思路和方向。 一个产品功能往往承载着提升指标的任务，比如上面提到的排行榜，可能是为了提高订单的转化率。
目标是否达到，要靠数据报表来体现。 例如，为了衡量排行榜的产品价值，我们可以构建一个时间维度的报表，字段有：排名入口曝光、排名引出其他产品、排名跳转到购物车、排名直接购买等。
只要产品的核心价值不变，上述需要定期分析的数据指标就不会发生变化。 这时候做报告会省去很多重复性的工作，更方便向产品外的人报告，或者定期向相关方发送报告通知。
但报告并不是数据分析的全部，还有一些内容无法固化。 比如短期经营活动的数据、ABtest的数据、其他维度的灵活数据分析等。
短期运营活动的数据容易理解，周期一般较短，加工成报表的开发时间可能比活动时间长，临时人工支持即可。 ABtest也是如此。 有专门的ABtest分析系统，动作是程序化的，没有结论。 不建议在报告中体现。
其他灵活维度的数据分析，如新增事件、位置调整等，需要嵌入式分析后台支持。 计划稳定实施后，要求逐渐添加到报告中。
通用的数据分析后台，比如天眼、Sensors等，这类平台积累了常用的分析方法和功能。 接入APP后，产品经理可以在管理后台快速开始分析。
具体的分析维度要根据目标来确定。 比如内部产品可能不需要看留存等数据，而更需要关注漏斗转化和绩效。 对于C端产品，留存分析更为重要。
3. 数据监控与可视化
除了分析，监控和可视化也很重要。
数据监控就是定期跑一些数据，看看有没有发现异常。 比如每小时跑一次排行榜的开盘数据。 如果排行榜人均打开次数在10次左右，某天某用户单日打开100次，则可能是数据异常，需要追溯原因。 看看是统计问题还是机刷量问题，然后对症下药解决。
可视化通常是基于报表的进一步表现形式。
可视化通常有以下几种：在表达一系列操作的衰减时，通常使用漏斗模型； 在表达功能使用或关键数据时，通常使用线装趋势图来表达增减趋势； 通道比例分析或其他横向类比 使用饼图时，这些是最基本的可视化形式。
还有很多更高级的可视化应用，比如我见过的动线系统。
动线起源于商业地产：在商场中，某一顾客从进店到购物再到购买再到退出的全过程称为客动线。
根据动线分析，商场内每一家门店、每一段楼梯、每一台收银机的位置都经过精心设置，可以最大限度地提升用户体验，最大限度地提高购物转化率。
同样，用户在APP中也有一定的动线。 比如用户也完成了一个购买行为，可能是通过列表页-详情页-购物车-支付的流程，也可能是通过活动页-详情页-直接下单-支付的流程。
如果能够将这些动线以可视化的方式展示出来，我们就可以看到动线之间的关系，以及每条动线的优缺点，从而脱离现有的功能，规划出最佳的动线。从整体的角度看过程。 金属丝。
类似的可视化方法还有热图，可以看到用户在某个页面的点击情况购物商城网站 一个商品应该具备哪些字段，从而分析用户的真实操作与我们产品设计的视觉引导之间的关系。 如果有偏差，可以有目的地调整视觉效果和交互。
总结
数据分析有范围和目的； 也就是说，一个团队首先要有数据来指导产品设计需求，才能培养全员意识，建立数据分析埋点机制，做好底层埋点等设施。
埋点的方式，根据不同的页面和场景，采用最合适的方式。 核心是业务目标或用户行为目标的反馈，应该从产品价值中梳理出来。
通过报表、监控和可视化，洞察产品运营中的机会点和优化点，逐步走向最优。
如果你作为产品经理，想要做好团队的数据分析，就从以上几条入手。
希望有所帮助，感谢阅读。
#专栏作家#
作者先生，微信公众号：产品的艺术，人人都是产品经理专栏作家。 金融行业资深产品经理，具有丰富的职业规划和个人发展经验，产品涉及范围广泛，包括ERP和金融领域。
