如何做好数据异常分析？

摘要：对于用户端产品经理来说，监控和处理日常用户端数据是必不可少的工作之一。日常监控的数据指标应包括转换数据、用户数据、交易数据等。对于用户端产品经理来说，监控和处理日常用户端数据是必不可少的工作之一。日常监控中包含的数据指标应包括转换数据、用户数据、交易数据等。一般来说，这些数据有一个固定的波动周期，每个周期的数据变化应该是稳定的。如果某一天的数据不再符合预期的稳定变化，我们称之为异常数据。在这种情况下，我们需要深入挖掘数据异常的原因。虽然这种分析有时意味着诸葛亮，而且分析过程往往很无聊，非常耗时，但对于那些认为产品经理的工作应该充满挑战和创新的人来说，这项工作是最令人讨厌的。然而，对异常数据的分析仍然是必要的。首先，了解各种产品数据的原因是产品经理的基本要求；其次，通过数据异常分析，我们往往可以探索未知的机会或风险，特别是这些机会和风险往往被我们忽视（否则我们不会认为是“异常”），这对产品的持续优化具有重要意义。(虽然我明白真相，但说实话，数据异常分析仍然是我最讨厌的工作，没有一%>_<%）那怎样才能做好数据异常分析呢？(或者换句话说:如何完成我们必须做的烦人分析？）首先，当然，我们需要识别和确认异常数据，其次是详细的分析过程。如果我们想很好地完成这个过程，我认为我们可以用八个词来概括：大胆的想法和仔细的验证。由于识别和确认异常是数据异常分析，我们必须能够检测到这些异常，然后确认数据异常确实存在，否则我们只会在错误的道路上越走越远。检测数据异常是最困难和最简单的，因为检测过程往往依赖于丰富的经验和对产品和业务的充分理解，我们称之为产品经理的数据敏感性。最简单的原因是，一旦我们有了这种敏感性，只要我们使用基本的数据报告，我们就可以无微不至地忽略它。数据敏感性不是一项“硬”技能，很难说有具体的操作步骤来提高数据敏感性。这一敏感部分真的取决于人才。有些人可能有很强的逻辑性。他们可以通过数据本身的相对关系发现异常。例如，DAU和转化率有所提高，交易量呈下降趋势（这种异常相对明显，请原谅我暂时无法举出需要更严格逻辑分析的例子）。另一方面，它需要产品经理对产品和业务有足够的了解，这可以通过更关注各种产品数据逐渐加强，如养成仔细阅读产品数据报告的习惯，然后详细分析一些不可理解的数据，经过长期的积极培训，肯定会提高数据敏感性，这就是为什么领导者（经验丰富的产品经理）更容易发现异常。如果你已经有能力发现或明显或隐藏数据异常，你可能会对发现宝藏感到兴奋，迫不及待地想弄清楚为什么。但我建议你在行动前确认这种异常是真实的，简单地说，就是确认数据是否有问题。这种事情很常见：我们经常遇到数据服务、数据报告和数据统计中的bug，然后数据报表中的数据变得难以理解。因此，找数据报表的产品和技术同事确认是否真的异常。如果确认数据异常确实存在，则需要找出原因。总结原因的过程是上述“大胆的想法，仔细验证”，大胆的想法是对异常的原因做出合理的猜测，因为异常是异常的，因为我们以前忽略了，所以在猜测的过程中需要打开想象力，联系所有你能想到的可能性，回顾所有产品相关信息，然后猜测可能导致数据异常的原因。仔细验证意味着，在做出猜测之后，我们需要对自己的猜测负责，找到能够支持(或否认)这种猜测的数据。那么，我们怎样才能做到脑洞大开大胆的想法呢？对于新手产品经理（嗯，似乎大多数异常数据分析都是由新手分析和处理的），你可能会觉得你的眼睛被抹黑了，不知道如何开始。下面有一个简单的表格供参考。*如果你看到这个表格已经知道我想说什么了，你就不用看下面的内容了。对于大多数已经产生的数据异常，可以从两个维度进行分类（个人经验总结，不同的产品可能有不同的分类方法，但我坚持推荐这种通过分类确定分析方向的方法）：第一个是范围维度，包括自己的产品、竞争和产品业务环境，分类的原因是相互竞争的产品处于较大的产品业务环境中，任何一方的变化都会导致自己产品的数据变化；二是内容维度，包括产品、技术、用户和运营。这些维度基本上包括互联网产品的重要组成部分，异常数据往往无法逃脱这些方面。另一方面，如果我们发现数据异常，并给出合理的数据异常猜测，我们不妨联系实际选择表中的一个网格。另一方面，如果我们发现数据异常，并给出合理的数据异常原因猜测，我们不妨联系实际情况，选择表中的一个网格。我将在表中填写我遇到过的情况和一些我认为将来可能会遇到的情况，并通过这些例子解释这种分析（猜测）方法。在产品层面，A1和B1是指自身产品或竞争产品因功能变化而引起的数据变化。例如，由于高价格排名功能的增加，客户单价上涨，竞争提前进入某些类别的商品入口，减少应用程序上此类商品的交易量；C1是指环境发生变化，导致产品数据发生变化。例如，当微博兴起时，我们可以猜测，人人网产品经理会发现DAU持续下降。由于大多数产品经理不是技术背景，技术问题往往是产品经理在分析数据时忽略的内容。由于大多数产品经理不是技术背景，技术问题往往是产品经理在分析数据时忽略的内容。例如，当我们的列表显示接口不够稳定时，A2会降低列表页面的点击率，然后交易量等。例如，B2，2015年5月5日.28.当携程因系统故障无法访问时，其他OTA网站的交易量可以预见会增加。C2相对罕见，如2014年1月1日.21.中国所有通用顶级领域的根服务器都有异常，而当天大部分国内网站的数据无疑应该有异常。在用户层面，当用户整体特征逐渐变化时，产品数据也会逐渐变化。至于A3和B3，我们假设有一种产品，最初培养的一群用户是学生，消费能力有限。如果这个产品有足够的粘性，当这些学生逐渐进入社会时，客户单价可能会继续上涨。C3，每年到11月，OTA网站的DAU和整体交易量都会下降，而三亚的交易量逆势上升，这也是大环境下旅游旺季的原因。对于需要支付的产品，所有经营活动都会影响市场规模和市场份额的分布，如滴滴和快速在市场阶段，任何一方的大促销都会增加市场份额，占据竞争市场份额（A4和B4），当滴滴合并红包金额减少时，将不可避免地导致应用程序用户数量（C4）。仔细验证前面提到的大胆想法。如果只停留在这个层面，这个分析就没有说服力了。下面还有一个重要的步骤是仔细验证。仔细验证就是找到直接或间接的证据来证明你的猜想。对于环境维度的数据异常猜测，一般可以获得一些数据来反映大市场来证明，如OTA网站DAU在一个月内大幅下降，我们猜因为旅游淡季，此时可以去百度指数看到“酒店”或“酒店预订”搜索热变化，或检查旅游消费数据，可以验证我们的猜测是否准确。对于自身产品和竞争产品维度的验证，唯一的法宝就是细分。以下是一些常见的细分维度及其案例。步骤：假设产品的转化率数据降低，这个转化率是多步漏斗转换的最终转换。我们可以细分每一步的转换，找出是否有问题。例如，微信支付服务器的故障会降低从订单到支付的转换，从而降低转换率，增加列表加载速度，降低列表到细节的转换率，影响整体转换。分平台/版本:假设从产品列表页面到详细页面的转换升级，我们猜测是IOS新版本中优化列表布局的方式。我们需要比较这个转换数据来证明我们的猜测，分为iOS、Android和旧iOS。区域/城市：假设某一OTA的交易量在某一年8月31日大幅增长，我们猜测酒店需求增加是因为大学生开学。此时，我们可以选择北京、武汉、西安等大学较多的城市的数据，与其他城市进行比较，以验证我们的猜测。分时间:假设某一天某个产品的转化率数据下降，我们猜测是10:00-11:由00支付服务器故障引起的，我们只需要将时间段与上一个波动周期的数据进行比较。如果当天的转换率确实大幅下降，这可以证明我们的猜测。用户群：假设应用新版本的转化率低于旧版本，用户分析发现新版本的新用户比例较大，我们猜新用户转化率会低于旧用户转化率，此时我们只需要看看新老客户的转化率差异就可以知道我们是否正确。分场景(本/异地)：假设一个应用程序在假期内的转换率下降，已知异地用户的转换率低于当地用户的转换率，假期转换率的下降是由于异地用户更活跃造成的。此时，我们只需要查看异地用户比例的变化，就可以验证猜测。分Item：假设OTA转化率在一段时间内显著提高，这段时间只是竞争较少的补贴促销活动，我们推测竞争促销终止对产品转化率产生积极影响，如果我们查看数据证实竞争取消促销ITEM转化率显著提高，这表明我们的猜测是正确的。关于如何做细分析，这里没有办法穷举，细分析的维度太多了，但我们需要记住这种分析方法。当猜测是由某种原因引起的数据异常时，只要我们找到原因所代表的细分对立面进行比较，我们就可以证明或伪造我们的猜测。当然，在分析过程中，我们需要了解一些基本的统计知识，这将在下周的推送中详细介绍。请期待。当发现数据异常或接收数据异常分析任务时，我们可以联系产品相关信息，在范围维度（自身、竞争、环境）和内容维度（产品、技术、用户、运营）进行合理的猜测，然后通过查看一些环境变化数据或细分产品数据来验证我们的猜测。根据这个过程，我们通常可以找到数据异常的深层原因。当然，这需要很多时间和耐心，但它可以让我们更深入、更全面地了解我们负责的产品的相关信息，并为未来的产品决策提供指导。对我们自己来说，这也可以增强数据的敏感性，让我们找到更多的机会和问题，形成一个良性循环，成为一名能够玩数据的产品经理。