前言

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

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

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

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

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

1. 解决问题的流程

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

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

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

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

日期

App启动率

8月5日

base + 0.8%

8月6日

base - 0.2%

8月7日

base + 1.7%

8月08日

base + 1.9%

8月09日

base - 1.6%

8月10日

base - 15.9%

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

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

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

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

客观标准的来源可以是：

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

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

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

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

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

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

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

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

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

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

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

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

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

版本变动：数据异常的时间节点有没有发版？前端、服务、策略等等指标口径：App启动率的口径是什么

数据来源：哪些是业务数据（服务端埋点）？哪些是用户行为数据（客户端埋点）？关键路径：App启动数据流转的关键路径是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

假设原因

验证假设需要的数据

1. 下载App失败

下载站点接口请求错误码占比、下载App的资源请求错误码占比

2. App启动量减少（打开崩溃）

首页曝光埋点数据（按设备去重）、启动埋点数据（按设备去重）

3. App登录的用户量减少

App进入登录页的埋点数据、App 登录成功的埋点数据

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

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

通过对假设的验证，我们发现假设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. 总结排查的过程 —— 把解决问题的过程展现出来

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

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

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

【问题背景】
    业务方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. 参考内容4. 作者介绍

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