数据产品Bug定位流程与实用方法

数据产品一般是服务与企业内部，一般原则是实现功能为第一优先级，能用就行。所以在资源配备上是能省就省，比如没有专门的UI资源，产品经理自己设计原型图直接开发；没有测试，数据产品自己进行功能可用性和数据准确性测试。没有运营，数据产品自己当客服，挡运维等。这也是为什么多数数据产品的岗位招聘时，对候选人的综合能力要求更高的原因。

在产品功能测试验收的环节，最经常遇到的情况就是发现页面没数据，或者指标数据不对，提了bug list，标注责任人的时候，把前后端、数据开发都加上了，但一个和尚挑水吃，2个和尚没水吃，不把问题清晰直接指向具体地一方，这个问题往往是最后才会被解决，都想着对方先去排查一下。所以，掌握一些bug定位的小技巧，作为产品经理，就可以直接判断是前端还是后端的问题，快速有效提升问题修复的效率。

数据产品的常见bug类型及排查方法

一、数据不显示

数据产品的核心是要把数据呈现出来，给用户进行使用和分析，但是经常是开发提测后，产品进行测试和验收时，发现页面全是“暂无数据“,根本无从测试。这个时候，需要界定清楚，是数据问题还是接口问题。

1.数据有没有

一般来说，数据产品的查询数据库是一些可以秒级响应用户交互操作的关系型数据库或者列式存储的非关系型数据库，所以需要使用基础的SQL查询语句，查询数据是否已经被成功的从数据仓库（hive）成功地推数到了MySQL（或其他）。经常出现地情况就是，反馈页面没数据，一查发现，数据没有推送，或者推送的数据格式不对

2.格式对不对

有数据了，在判断页面用到的筛选条件是否和数据里面的格式保持一致，比如接口开发时，用day和month区分日报或月报的日期类型，但是数据推送过来的枚举值是“日报、月报”，对于数据开发和接口开发不是同一个人，数据格式是经常会出现对接问题的地方

3.前端有没有请求？

数据产品数据查询类的功能为主，一般是采用C/S架构，即客户端发请求，服务端返回数据，通常每一次用户的点击、筛选都需要请求后端接口，但是如果前端压根没法请求，那就不可能有数据显示。判断的方法就是页面右键-检查，或者直接F12，调出页面debug的弹窗，监测本次操作是否有请求接口

找到network(网络)，刷新页面，或者先清空历史请求的接口避免干扰，再点击页面，看下最新的操作是否有发起请求。右上角可以设置检查的界面的显示方式，右侧显示，还是新窗口打开，还是下方显示。

另外，数据产品一般要求数据查询性能控制在2s内，感觉页面慢，定量的看到底有多慢，也是通过network看每个接口的响应时间

4.接口有没有返回

数据库有数据，格式正确，而且前端正常请求了接口，但是就是没数据，那就要看下接口是否返回了数据，或者前端传参是否正确

点击某一个具体的接口，首先看接口有没有返回数据。主要是看接口的response，首先看是不是报错了，报错了直接把错误截图扔给后端（java）开发。如果操作成功，但是data为空，也找后端。

如果操作成功，也返回了数据，就主要前端的问题了，比如传参问题，或者界面展示bug。那就要近一一步看前端的传参是否对了。主要通过payload看这个接口的入参

二、数据不准确

近期做的项目，搞了100多个数据指标，经常出现指标数据看着不符合常理的情况，比如同比异常大，占比超100%等，这个时候就需要一个指标一个指标的拿着页面显示的结果，和MySQL（或其他）比对，常见的错误类型就是后端取错字段，或者前端界面呈现指标名和接口返回的指标绑定关系错误。在这个过程中，主要涉及的就是基础SQL select * from table where等语句，连Join都很少用到。想学习SQL基础可以参考之前的文章产品经理必知必会的SQL知识（附pdf版电子书）

以上都是非常基础知识，但是在数据产品实际工作过程中还是非常实用的，至少对于我自己的这个项目，一个人把产品经理，QA、项目经理，运维、运营全干了。总结一下分享给产品新人同学，以作备忘。

也顺便告诉大家，数据干饭人的号，还是不定期更新。