解决实际问题的数据分析流程

前言

对大部分的研发同学来说，如果要给日常工作中头疼的事情弄个排行榜，那“排查某流程转化率异常”必定榜上有名且排名靠前。至于头疼的原因，我想有下面几点：

1. 公司业务日益复杂，系统间数据流转节点繁多，使用局部视角无法解决复杂流程的问题
2. 解读数据的能力欠缺，没有掌握通用的整理和分析数据的基本方法。
3. 流程的关键数据指标欠缺，分析进行不下去。
4. 耗费大量的精力和时间来分析数据，但只是用数据对现象进行描述，没有找到造成这种现象的原因，导致领导或业务方对结果不满意。

我们都知道“把大象放进冰箱分几步”的梗，它说明了做事流程或思维框架的重要性。如果缺少流程，那么解决问题的效率和正确性很难得到保证，进而拉长问题的平均修复时间 MTTR (Mean Time To Repair)，对系统稳定性造成不小的挑战。

本文将给大家分享一个解决问题的流程 —— 来自柏木吉基的书《如何用数据解决实际问题》，并在介绍这些概念时增加真实案例以便大家加深理解。当我们掌握并熟练运用好“流程”后，定义问题、分析问题、解决问题的能力及效率都能有所提升，进而完善自身的数据分析思维。

柏木吉基，日本数据分析实战专家及资深培训师，数据&故事公司总裁

1. 解决问题的流程

整个流程的核心是先发散（广阔的视角出发）后收敛（聚焦于关键点）的过程，共分为5个步骤：

1. 明确问题或目的  确保所有过程与操作在理论上最终都与这一目的或问题相关，这样整体的逻辑和流程才不会出现偏差。
2. 大致把握现状  通过了解问题的背景等相关内容，收集对应的数据。
3. 锁定问题的关键点  对数据进行分解和比较，以确定分析范围。
4. 锁定原因  提出一个或多个假设，用已有的数据来对照分析和推理验证，最后锁定出主要原因。
5. 讨论及实施对策  针对原因来实施相应的措施。

我们现在使用上面的5个步骤来分析真实的案例 —— App启动率下降，先交代下案例的起因：

业务方8月11日反馈，8月10日App启动率下降明显，需要排查原因，业务方提供了近期的启动率数据，如下表（数据已做脱敏处理）

1.1 明确问题或目的 —— 学会用数字或数据来定义问题

业务方反馈的“启动率下降明显”只是一个观点，而不是一个客观事实。不同的人理解同一个“观点”，可能会存在歧义，如：听到“启动率下降明显”，你可能这么想：

1. 降了算异常？
2. 下降幅度过大算异常？
3. 不符合历史规律算异常？

定量评价或判断数据分析结果时，需要客观的判断标准，这样就能避免分析者靠自己的主观感受来决定一个问题的优先级。

客观标准的来源可以是：

1. 行业和竞品的平均标准
2. 历史数据的平均水平或规律
3. 老板心中的标准。老板思考问题的深度和广度毕竟高于普通的员工，也就是说老板自然有老板的道理

通过整理业务方给我们提供的数据可以发现，App启动率的日常波动应该在 [base - 2%, base + 2%]内（这是历史数据的平均水平或规律），8月10日直接降到了base - 15.9%，中间差了16%左右，所以这16%的差异才是“问题”，而我们的目的就是要找到引起这个差异的原因。我们通过使用数字或数据来定义“问题”，其优势在于：

1. 可以明确用哪项指标来客观地衡量问题
2. 可以定量地与其他人一起确认问题的严重程度及最终目标

如果用客观事实的表达方式来描述这个问题，不同的人都能理解，不会出现歧义，如下：

App启动率从8月10日开始，相比于前几日降低了约16%，正常波动范围应该在正负2%，需要排查降低的原因。

我们在日常沟通数据相关的问题时，也应当尽量使用客观事实的表达方式来描述，而不是用“观点”进行沟通，否则可能会出现大量的误解。

另外，很多同学经常会拿到需求或问题就埋头苦干，干着干着就逐渐忘记“初心”，所以目标导向就显得非常重要，需要确保所有过程与操作在理论上最终都与这一目的或问题相关，这样整体的逻辑和流程才不会出现偏差。

1.2 大致把握现状 —— 详细了解问题的相关内容

在明确问题或目的时，你已经掌握了一些信息，但距离着手进行数据分析，这些信息还远远不够，你还需要尽可能多的收集信息。

这个过程你应当和“问题”的关联方/干系人保持沟通，因为查问题并不是你一个人的事情，一个人的精力、知识、视角毕竟有限，在和关联方沟通的过程中，也能相互印证一些看法，进而增进彼此间的合作关系。

这里我整理了排查问题需要收集的一些内容，仅供参考：

1. 影响范围  影响范围能够确定问题的紧急程度，根据此来决定你现阶段的工作重点，要知道，并不是业务方反馈的问题都是高优先级的。
2. 版本变动  在出现“问题”的时间段内，是否存在代码功能变动 —— 也就是我们常说的“发版”，包括前端、服务、策略等等，而“发版”也最容易引入BUG，导致转化率异常。
3. 指标口径  指标口径的意义在于无论何时何地何人进行数据分析和决策，计算的逻辑都是相同的，它确保了数据准确性和可靠性，避免了因为不同理解而导致的数据误差和错误决策，有助于提高决策的精确性和时效性。
4. 数据来源  通过指标口径，可以知道哪些数据是业务数据，哪些是用户行为数据。一般来说数据来源应该尽量一致，否则就容易导致误差，因为数据类型不同，其上报的逻辑也不同，有可能出现数据不匹配的情况。
5. 数据流转的关键路径  得弄明白数据从哪里来，去往哪里，中间经过了几个环节，否则就无法得知某转化率的分子和分母代表什么意思。在排查问题的时候，就会陷入停滞不前的状态，无法取得有效进展。

针对App启动率下降的案例，我们在进行数据分析前，进行了相关现状的整理：

• 影响范围：范围有多大，是不是造成了资损？即问题的紧急程度
• 目前影响暂无业务反馈资损情况，需进一步排查，优先级较高
• 版本变动：数据异常的时间节点有没有发版？前端、服务、策略等等
• 8月9日 App全量发布了新版本
• 指标口径：App启动率的口径是什么




• 数据来源：哪些是业务数据（服务端埋点）？哪些是用户行为数据（客户端埋点）？
• 除了App启动量是用户行为数据，其他都是业务数据
• 关键路径：App启动数据流转的关键路径是什么？
• 媒体广告 -> 投放落地页 -> 用户注册成功 -> 用户下载App -> 用户启动 -> 用户登录成功

至此，我们已经掌握了许多关键信息，如：“8月9日 App 全量发布了新版本”等。下一步我们就可以开始着手进行数据分析，来锁定问题的关键点。

1.3 锁定问题的关键点 —— 对数据进行分解和比较

对较大范围的数据（包括多个要素）一筹莫展时，可以运用 “四则运算” 来分解数据，拆解成若干个“小数据”逐一考虑，使其变得更为详细和具体，从而进一步缩小范围。

通过 1.2 大致把握现状 中我们搜集到的信息，App启动率指标口径为：

我们通过“四则运算”来分别对分子和分母进行分解，进而得到对比的维度：

• 分母的分解

  
  

• 分子的分解

  
  

这样我们可以得到需要对比的维度为：媒体、操作系统、App版本。

通过对比不同维度的数据发现，启动率下降问题的关键点是：Android App 新版本启动量减少。

下图是 操作系统维度下启动率的表现，可以看到 Android 系统启动率在8月10日显著降低约20%

1.4 锁定原因 —— 提出假设并验证

为了锁定原因，我们需要通过假设来列举出可能的原因并通过验证来找到根本原因。但要注意的是，假设验证和预设立场不同

• 假设验证，事先规划验证这个假设需要的数据。如果数据最终不符合假设，那么就抛弃这个假设。
• 预设立场，是要找到证据来证明猜想，一个数据不行，那就换另一个数据。直到能证明这个观点为止。预设立场再去找证据是一件相当不靠谱的事，因为只要你想证明一件事，总能找出一些证据然后强行关联。

  
  

那如何进行假设呢？这里提供2个方法给大家参考：

1. 目标相关法。通过相关分析，找出对最终目标具有密切影响的原因。如：如果要使“App启动量减少”，我应该做些什么，比较容易想到的是：用户在落地页注册后，App下载失败。这样通过将问题转变为目标，来给出候选原因（假设）

   
   

2. 流程相关法。在某个业务流程中找到瓶颈，理想的状态是所有要素都畅通无阻地抵达最终阶段（输出）。但如果某个环节出现了停滞，预想的输出就无法实现

   
   

为了整理思路，我们可以制作一个包含目的或问题、假设、方法以及所需数据等4个要素的图表辅助我们进行分析。

如上图，我们列举出了“Android App 新版本启动量减少”的3个假设原因，及验证假设需要的数据：

并非所有的情况都是只有一层假设就够了，如果觉得最初的假设挖掘得还不够深入，也可以进一步反复思考“为什么”，继续深入挖掘第二层、第三层假设，从而找到更为具体的问题或原因。值得一提的是，假设和假设之间需要保持独立，避免相互关联。

在实际工作中，我们未必能直接获得自己所需的数据，常需要对假设进行重新调整，反复尝试多个回合。在假设和验证的过程中循序渐进，将所发现的事实和逻辑一层层积累起来，这个过程对任何问题来说都是相同的。

通过对假设的验证，我们发现假设2的数据验证结论是：“Android App新版本启动埋点的量级比首页曝光埋点的量级少”，这不符合常理，理论上应该是启动埋点应该不少于首页曝光埋点。这个“不合理的点”是否就是引起“Android App 新版本启动量减少”的原因呢？

我们还需要推演一番。就像法官的判决讲究证据链完整，证据链中的链字，就有一环扣一环的含义在其中。但是我们也需要警惕自身的经验、自觉 带来的副作用，这也是为什么法官在审判时，有陪审团或陪审员一起判案的原因。在推演时，应当需要找更有经验的同学对自己的的“假说”进行确认，避免“偏差”。

我们将App启动量埋点减少，代入到 1.2 大致把握现状 中我们收集到的App启动率指标中，发现：App启动量埋点减少确实会导致App启动率的下降。

最终通过和其他的小伙伴验证，我们终于锁定了根本原因：新版本App首次打开后无法上报启动埋点

1.5 讨论及实施对策 —— 采取必要的措施

只是找到原因不能算解决了问题，还要针对原因决定必须采取的措施。通常来说，对于业务上的问题找到了原因后，我们需要将相关信息条理清晰地展现出来。与解决问题的中间过程、分析内容相比，对方可能更想先知道结论及其根据，所以对于面向的对象是决策者来说，先陈述结论（希望得到批准的措施、预算等）会比先陈述理由（锁定的原因）效果更好一些。因此，面面俱到地介绍分析过程中的所有详细内容未必是上策。多数情况下，这些内容都是在被问到的时候稍加说明就足够了。

可以参考下面的模板进行反馈，这里以“App启动率下降问题”为例

经排查，8月10日App启动率比于前几日降低了约16%的原因为：App启动量埋点减少，系首次打开App无法上报启动埋点所致。
解决方案建议如下，请XXX评估是否可行：1. 短期方案：为了保证报表数据的准确性，建议修改指标口径，将「App启动数」统一调整为「用户在App的登录数」。由 @XXX 进行调整。2. 长期方案：首次打开App无法上报启动埋点的问题计划下跟App下个版本修复。由 @XXX 进行跟进。

另外，如果有待办事项，注意加上跟进人（最好还能加上时间约束），否则容易导致事项遗忘

1.6. 总结排查的过程 —— 把解决问题的过程展现出来

最后，很重要的一点是将分析的整个过程通过文字记录下来，其作用有两个

1. 再次整体梳理一遍排查的过程，避免遗漏。
2. 存档。为了将来可以清晰的回顾历史发生的问题，而不是靠记忆，正如那句俗话说的：“好记忆不如烂笔头”。

模板可以参考下面的进行，这也是我们移动应用团队使用的模板：

【问题背景】    业务方8月11日反馈，8月10日App启动率比于前几日降低了约16%，正常波动范围应该在正负2%，需要排查降低的原因。【影响范围】    暂无实际业务影响，仅影响业务数据统计【问题原因】    * 8月9日 Android App全量发布新版本, 但首次打开App时无法上报启动埋点，导致App启动率指标下降。    * 附：App启动率口径：    App启动率 = 投放页注册的用户中，当天打开App的启动数量（通过登录事件向前关联）（分子）/ 投放页注册的用户数量（分母）【解决方案】    经与业务方沟通，分为短期和长期两个方案执行    1. 短期方案：为了保证报表数据的准确性，建议修改指标口径，将「App启动数」统一调整为「用户在App的登录数」。由 @XXX 进行调整。    2. 长期方案：首次打开App无法上报启动埋点的问题计划下跟App下个版本修复。由 @XXX 进行跟进。

2. 总结

上面的部分为大家详细介绍了数据分析流程的各个步骤，其实与医生为患者看病并开出处方的过程有很多共同之处，大家可以通过下表进行类比，以便更好的理解“流程”：

本文非常适合零数据分析基础的同学，通过理论与真实案例相结合的方式，帮助大家认识数据分析流程（特别是经验不是太丰富的同学）。希望大家能通过掌握这个流程来提升我们日常排查问题的效率，也希望能对大家建立起分析型思维有所帮助。当然，这里只是提供了一个排查问题的思路，大家可在自己的工作中，结合自己所负责的业务，不断实践并总结出自己的一套方法论

3. 参考内容

• [日]柏木吉基. 如何用数据解决实际问题(数据让洞见更准确，让沟通更简洁。） (Chinese Edition) (p. 65). Kindle 版本.
• 《会工具懂方法，但分析还是没思路？这5点让你拥有数据分析思维》 https://mp.weixin.qq.com/s/rzRqXlGhopscyEa5og86yw

4. 作者介绍

Wenz，信也科技移动端技术专家

招聘信息

Java、大数据、前端、测试等各种技术岗位热招中，欢迎扫码了解~