如何做好数据异常分析

对于用户端产品经理来说，监控处理日常的用户端数据是必不可少的工作之一，转化数据、用户数据、交易数据等等，都应该是列入日常监控的数据指标。一般来说，这些数据都有固定的波动周期，每个周期内的数据变化应该是趋于稳定的，如果某天某周某月的数据不再符合预期的稳定变化，也就是我们所说的数据异常。这种情况下，我们需要去深挖数据异常产生的原因。虽然这种分析有点时候诸葛亮的意味，而且分析的过程往往无趣且极其耗费时间，对于那些认为产品经理的工作理应充满挑战和创新的人来说，这项工作简直是最让人厌恶的了。

但是数据异常的分析仍然是必要的，首先，对于产品的各种数据知其所以然，这是对产品经理的基本要求；其次通过数据异常分析往往能够发掘未知的机会或风险，尤其难得的是这些机会和风险往往是我们平时忽略的（要不然我们也不会认为是“异常”），这对产品的持续优化具有重要意义。（虽然我明白其中的道理，不过说实话数据异常分析仍然是我最讨厌的工作，没有之一%>_<%）

那么如何才能做好数据异常分析呢？（或者换个说法：如何完成我们必须要做的烦人分析工作？）首先，当然是要求我们能识别和确认数据异常，其次就是细致的分析过程，如果想要很好的完成这个过程，我认为可以用八个字概括：大胆设想，小心求证。

识别和确认异常

既然是数据异常分析，那么我们必须能察觉到这些异常，然后还要确认数据异常是真的存在，否则只会在错误的道路上越走越远。察觉数据异常最难也最简单，最难是因为察觉的过程往往依靠丰富的经验和对产品和业务的充分了解，我们称之为产品经理的数据敏感。最简单是因为我们一旦有了这种敏感性，只要借助基本的数据报表，就能够风吹草动无微不察。数据敏感不是一个“硬”技能，也很难说有具体的操作步骤去提高数据敏感性，这种敏感一部分真的要靠天赋，有些人可能逻辑性强，通过数据本身的相对关系就能够发现异常的存在，比如DAU和转化率都有提升而交易额呈下降趋势（这个异常相对明显，原谅我一时举不出需要更严密逻辑分析的例子）。另一部分，它需要产品经理对产品和业务有足够的了解，这个是可以通过平时多加关注各种产品数据来逐渐加强的，比如养成仔细阅读产品数据报告的习惯，然后对一些无法理解的数据进行详细分析，经过长期的主动训练，是一定可以提高数据敏感度的，这也是为什么Leader们（有经验的产品经理）更容易发现异常的原因。

如果你已经具备了察觉或明显或隐蔽的数据异常的能力，你或许有发现宝藏的兴奋，迫不及待的想要去搞清楚所以然。但是我建议你在行动前最好确认一下这个异常是真的存在，简单的说，就是确认下数据有没有问题。这种事情很常见：我们经常会遇到数据服务、数据上报、数据统计上的BUG，然后数据报表中的数据就变得难以理解。所以，找数据报表的产品和技术同事确认一下是不是真的异常吧。

数据异常分析

如果数据异常经确认确实存在，那么你就要去找原因了。这个找原因的过程总结起来就是前面所说的“大胆设想，小心求证”，大胆设想就是对异常产生的原因做出合理的猜测，因为异常之所以为异常，是因为我们之前的忽视，所以在猜测的过程中需要脑洞大开，联系所有你能够想到的所有可能，回顾所有产品相关的信息，然后猜测一个可能造成数据异常的原因。小心求证是说在做出猜测之后，我们需要对自己的猜测负责，找到能够支持（或者否定）这种猜测的数据。

大胆设想

那么，我们如何才能做到脑洞大开大胆设想呢？对新手产品经理（好吧，数据异常分析好像大多由新手来分析处理）来说，你可能会觉得两眼一抹黑不知如何下手，下面有一个简单的表格，可供参考。

* 如果你看到这个表格已经知道我要说些什么，那后面的内容你可以不用看了。

对于大部分已经产生的数据异常，大概可以从两个维度来分类（个人经验总结，可能不同产品有不同的分类方式，但是我坚持推荐这种通过分类来确定分析方向的方式）：

• 第一个是范围维度，包括自己的产品、竞对方面以及产品业务的大环境，这样分类的原因是因为相互竞争的产品都处于大的产品业务环境之中，任何一方的变动都会造成自家产品的数据变化；
• 第二个是内容维度，包括产品、技术、用户和运营，这几个维度基本囊括了互联网产品的重要构成，往往数据异常逃不过这几个方面。反过来说，如果我们发现了数据异常并且要给出一个合理的数据异常原因猜测，那么不妨联系实际选择表格中的某一格。

我将已经遇到过的情况和一些觉得可能以后会遇到的情况填充到这个表格中，通过这些例子对这种分析（猜测）方法做出解释。

产品层面，A1和B1两种情况是指当自身的产品或者竞对的产品因为功能变更造成的数据变化，比如自己产品因为增加了高价排序功能造成客单价升高，而竞对将某些品类商品入口提前而造成自己App上这类商品的交易额降低；C1指大环境发生了变化，而造成自己的产品数据变化，比如我们可以猜想当微博兴起时，人人网的产品经理会发现DAU持续下降。

因为大多数产品经理并非技术出身，所以技术上的问题往往是产品经理在分析数据时忽视的内容。比如A2，当我们的列表展示接口不够稳定时，会造成列表页点击率降低，进而交易额等等都接连降低。比如B2，当2015.5.28，携程因为系统故障而无法访问时，其他OTA网站的交易量可预见是提升的。C2情况相对少见，比如2014.1.21，国内所有通用顶级域的根服务器出现异常，而当日国内大部分网站的数据毫无疑问应该是异常的。

用户层面，当用户整体特征逐渐变化时，产品数据也会逐渐变化。对于A3和B3情况，我们假设有一类产品，最初培养的一群用户是学生，消费能力有限。如果这个产品黏性够强，当这批学生逐渐步入社会，客单价可能会持续增长。C3情况，每年到11月，各OTA网站的DAU和交易额整体就会降低，而三亚地区的交易额逆势上升，这就是大环境下旅游淡旺季的原因造成的。

对于需要支付的产品来说，所有运营活动都能影响市场的大小以及市场份额的分布，比如滴滴和快的在培育市场阶段，任何一方的大额促销都会提升自己的市场份额并侵占竞对的市场份额（A4和B4），而当滴滴快滴合并之后红包额度的减少，必然会造成App叫车用户数量的降低（C4）。

小心求证

前面讲了大胆设想的方法，如果只是停留个这个层面，那这个分析是没有说服力的，下面还有一个重要的步骤是小心求证。小心求证是找到直接或间接的证据来证明你的猜想。对于大环境维度的数据异常原因猜测，一般可以获取一些能够反映大市场的数据来证明，比如OTA网站DAU在某月降低幅度很大，我们猜测是因为旅游淡季开始，这时候可以去百度指数看看“酒店”或“酒店预订”搜索热度的变化，或者查查往年此时的旅游消费数据，就可以验证我们的猜测是否准确。

而对于自身产品和竞对产品维度的求证，不二法宝就是细分，下面介绍一些常见的细分维度及其案例。

• 分步：假设某产品的转化率数据出现降低的情况，而这个转化率是多步漏斗转化的最终转化，我们可以细分每一步的转化情况，查清是否因为某一步出了问题。比如微信支付服务器的故障会造成下单到支付的转化降低从而造成转化率降低，列表加载速度增加造成列表到详情转化率降低影响整体转化等等。
• 分平台/版本：假设某产品列表页到详情页的转化提升，我们猜测是iOS新版本中优化列表布局方式，我们需要分iOS和Android以及分iOS新版老版对比这个转化数据来证明我们的猜测。
• 分区域/城市：假设某年8月31日某OTA的交易额呈现大幅增长，我们猜测是因为大学生开学造成酒店需求增加，这时我们可以选取部分高校较多的城市如北京、武汉、西安等城市的数据来对比其他城市来侧面验证我们的猜测。
• 分时间：假设某日某产品转化率数据下降，我们猜测是10:00-11:00支付服务器故障造成的，那我们只需要分时间段和上一个波动周期同期的数据对比，如果当日这个时间段转化率确实下降很大，就可以证明我们的猜想。
• 分用户群体：假设某App新版上线之后新版转化率低于旧版，经过用户分析发现新版新用户比例较大，我们猜测新用户转化率会比老用户转化率低，这个时候我们只需要看一下新老客户的转化率区别就能知道我们是否蒙对了。
• 分场景（本/异地）：假设某App在某假期内转化率降低，已知异地用户转化率低于本地用户转化率，猜测假期转化率降低是因为异地用户较活跃造成的，这个时候，我们只要需要去看看本异地用户占比的变化就可以验证猜测了。
• 分Item：假设某OTA转化率在某段时间内明显提升，而这个时间段恰好是竞对较少补贴促销活动的时间，我们猜测是竞对促销活动终止对产品转化率造成了正面影响，如果我们查看数据证实那些被竞对取消促销的Item转化率提升明显，那说明我们的猜测是对的。

关于如何做细分分析，这里没有办法穷举，可以细分分析的维度实在太多了，但是我们需要记住这种分析方式，当猜测是某种原因造成数据异常时，只要找到该原因所代表的细分对立面做对比，就可以证明或证伪我们的猜测。当然，在分析的过程中，我们需要了解一些基本的统计学知识，这个将会在下周的推送中详细介绍，敬请期待。

小结

当发现数据异常时或者接到数据异常分析任务时，我们可以联系产品相关的信息，在范围维度（自身、竞对、大环境）和内容维度（产品、技术、用户、运营）结合给出合理的猜测，然后通过查看一些大环境变化数据或者细分的产品数据来验证我们的猜测。遵照这个流程，一般能够找到数据异常的深层原因，当然，着需要花费大量的时间和足够的耐心，但它能够让我们更深更全面的了解自己负责的产品的相关信息，并为未来的产品决策提供指导。对我们自己，这也能加强数据敏感度，让我们能够发现更多机会和问题，形成一个良性循环，成为一个能玩转数据的产品经理。