干货如何做好数据异常分析.pdf

干货 | 如何做好数据异常分析 对于用户端产品经理来说，监控处理日常的用户端数据是必不可少的工作之一，转化数据、用户 数据、交易数据等等，都应该是列入日常监控的数据指标。一般来说，这些数据都有固定的波动 周期，每个周期内的数据变化应该是趋于稳定的，如果某天某周某月的数据不再符合预期的稳定 变化，也就是我们所说的数据异常。这种情况下，我们需要去深挖数据异常产生的原因。虽然这种 分析有点时候诸葛亮的意味，而且分析的过程往往无趣且极其耗费时间，对于那些认为产品经理的 工作理应充满挑战和创新的人来说，这项工作简直是最让人厌恶的了。 但是数据异常的分析仍然是必要的，首先，对于产品的各种数据知其所以然，这是对产品经理的基 本要求；其次通过数据异常分析往往能够发掘未知的机会或风险，尤其难得的是这些机会和风险往 往是我们平时忽略的（要不然我们也不会认为是 异常“ ”），这对产品的持续优化具有重要意义。（ 虽然我明白其中的道理，不过说实话数据异常分析仍然是我最讨厌的工作，没有之一 %_% ） 那么如何才能做好数据异常分析呢？（或者换个说法：如何完成我们必须要做的烦人分析工作？） 首先，当然是要求我们能识别和确认数据异常，其次就是细致的分析过程，如果想要很好的完成这 个过程，我认为可以用八个字概括：大胆设想，小心求证。 识别和确认异常 既然是数据异常分析，那么我们必须能察觉到这些异常，然后还要确认数据异常是真的存在，否则 只会在错误的道路上越走越远。察觉数据异常最难也最简单，最难是因为察觉的过程往往依靠丰富 的经验和对产品和业务的充分了解，我们称之为产品经理的数据敏感。最简单是因为我们一旦有了 这种敏感性，只要借助基本的数据报表，就能够风吹草动无微不察。数据敏感不是一个 硬“”技能，也 很难说有具体的操作步骤去提高数据敏感性，这种敏感一部分真的要靠天赋，有些人可能逻辑性强 ，通过数据本身的相对关系就能够发现异常的存在，比如 DAU 和转化率都有提升而交易额呈下降趋 势（这个异常相对明显，原谅我一时举不出需要更严密逻辑分析的例子）。另一部分，它需要产品 经理对产品和业务有足够的了解，这个是可以通过平时多加关注各种产品数据来逐渐加强的，比如 养成仔细阅读产品数据报告的习惯，然后对一些无法理解的数据进行详细分析，经过长期的主动 训练，是一定可以提高数据敏感度的，这也是为什么 Leader 们（有经验的产品经理）更容易发现异 常的原因。 如果你已经具备了察觉或明显或隐蔽的数据异常的能力，你或许有发现宝藏的兴奋，迫不及待的想 要去搞清楚所以然。但是我建议你在行动前最好确认一下这个异常是真的存在，简单的说，就是确 认下数据有没有问题。这种事情很常见：我们经常会遇到数据服务、数据上报、数据统计上的 BUG ，然后数据报表中的数据就变得难以理解。所以，找数据报表的产品和技术同事确认一下是不是真 的异常吧。 数据异常分析 如果数据异常经确认确实存在，那么你就要去找原因了。这个找原因的过程总结起来就是前面所 说的 大胆设想，小心求证“ ”，大胆设想就是对异常产生的原因做出合理的猜测，因为异常之所以为 异常，是因为我们之前的忽视，所以在猜测的过程中需要脑洞大开，联系所有你能够想到的所有 可能，回顾所有产品相关的信息，然后猜测一个可能造成数据异常的原因。小心求证是说在做出猜 测之后，我们需要对自己的猜测负责，找到能够支持（或者否定）这种猜测的数据。 大胆设想 那么，我们如何才能做到脑洞大开大胆设想呢？对新手产品经理（好吧，数据异常分析好像大多由 新手来分析处理）来说，你可能会觉得两眼一抹黑不知如何下手，下面有一个简单的表格，可供 参考。 * 如果你看到这个表格已经知道我要说些什么，那后面的内容你可以不用看了。 对于大部分已经产生的数据异常，大概可以从两个维度来分类（个人经验总结，可能不同产品有不 同的分类方式，但是我坚持推荐这种通过分类来确定分析方向的方式）： 我将已经遇到过的情况和一些觉得可能以后会遇到的情况填充到这个表格中，通过这些例子对这种 分析（猜测）方法做出解释。 产品层面， A1 和 B1 两种情况是指当自身的产品或者竞对的产品因为功能变更造成的数据变化，比 如自己产品因为增加了高价排序功能造成客单价升高，而竞对将某些品类商品入口提前而造成自 己Ap