最近安排一位实习生小R同学排查一个数据bug问题。小R同学排查的过程非常坎坷，踩了很多的坑，好在最后基本解决了问题。我觉得他的一些错误对于新人来说挺有代表性的，整理一下，分享给大家。让大家也了解一个基本的数据bug排查流程大概是怎么样的。 问题背景首先说下背景。我们希望新用户在首次进入APP的时候，进入一个标签选择页面。在设计这个页面的时候，我们希望首次进入APP的新用户都会进入这个页面，理论上讲，当天新用户的数量和这个页面的曝光人数应该是一致的。但是我们在分析的时候发现，页面的曝光人数远低于当天的新用户数。 这就给后续的分析带来的困扰，于是我们需要找出为什么会出现这样的原因。 于是这个任务就交给了小R，小R的基本分析过程总结起来就是以下几步。确认问题、缩小问题范围、找出原因、总结汇报

基本步骤没啥问题，不过中途犯了一些小问题，下面详细看一下。  第一步 确认问题最初提出提出排查数据bug问题的需求，是因为每日看到这个页面的人数和当日新用户数对不上。看到页面的人数要比新用户数低。但是这个问题还需要继续细化，显示的用户数低，到底低多少？是持续的低还是偶尔低？这些问题都需要先搞清楚。这就跟肚子疼去医院看病是一个道理，你跟医生说肚子疼，医生肯定要先确定到底是哪疼，什么时候开始疼的等等这些问题，确定到底是一个什么问题。 小R同学在这一步骤做的还是不错的的。经过初步分析，发现有两类错误：

有些新用户该看到这个页面却没看到，占比x%。有些老用户不应该看到这个页面，却看到了这个页面，这部分用户占比y%

确定了问题的表现，小R进入了下一步。 第二步 缩小问题范围初步判断问题类型之后，接下去就是找不同错误类型各自的原因。小R同学将有问题的用户挑出来，看这些用户与正常用户之间是否存在不同维度上的差异。比如系统、版本、机型等维度去做对比，希望通过细分分析继续缩小问题的范围。随后发现这个问题确实和系统有一定的关系，问题主要集中在安卓。到这一步似乎一切都很顺利。但是之后小R还想再看看还有什么其他维度也有差异，于是在这一步花了太多的经历。但除了之前发现的安卓有问题之外，其他几乎没有进展。 错误：过度分析新人分析师经常会犯的错误就是过度分析。总觉得只要多拆几个维度，总能找到问题的原因。可能大部分新人分析师入职前， 做的项目一般都是网上的数据集拿来使劲折腾。这类项目不需要找出真正的原因，有相关关系就行，再加上一个过拟合的模型，分数够高就能拿高分。但是实际工作中，业务情况非常复杂，不是自己闭门造车就能解决的。在缩小问题的范围后，我们要开始找问题的原因，而不是继续拆解问题。第三步 找原因小R在细分分析那卡了很久，一筹莫展。然后终于想到请教分析师前辈。分析师前辈听罢献计：去找负责的某某开发工程师。于是小R屁颠屁颠跑去问开发，一轮沟通之后，小R终于把这个数据的获取流程搞明白：新用户是怎么判断的、数据是怎么上传的。搞清了数据产生的机制，继续排查也就简单了。把数据产生的环节画出来，然后一个一个排查下去，或者直接提出假设，验证假设就行。好在这个开发的哥们比较有经验，很快就基本锁定了问题。 错误：沟通不足数据的产生机制很复杂，可能牵扯到的工种有开发、测试、运维、数据仓库等等不同的岗位。一个新人想要自己把问题排查出来，不是没可能，但是往往时间成本非常大。小R解决这个问题，分析师前辈的一句话让他少走不少弯路，然后开发工程师的假设又快速地锁定了原因。小白分析师一定要清楚，自己花2个小时百度搞懂的事，问一下负责的同事，可能2分钟就能解决。既然上一步已经缩小了问题范围，要尽快确定问题原因，最快的方式就是找专业的人。  第四步 总结汇报在找出问题后，小R确定了开发后续的修改方案，这个时候需要写一封邮件把这件事通知给各关联方和领导。在第一版的邮件当中，小R把问题说清楚了，背景、原因、后续方案等都有，但是全是文字，也没有任何排版。我看到第一眼就打回去让他重做。错误：邮件可读性太差几百字的内容，没排版没图片说明，除了密切关注的人员，其他人谁有时间仔细看啊。邮件的书写是所有职场小白需要修炼的技能，这不仅关系到你的专业形象，也让领导知道你到底干了个什么事。 这次的数据BUG，用一个韦恩图来说明既简单又清楚。花10秒钟读100个字说清的事，2秒钟一个图看完就懂了。 对比一下你就懂了文字版：

该页面被设计为只有首次登录的新用户能查看，但目前发现两个问题：1.部分新用户看不到这个页面2.部分老用户会看到这个页面

图片版

文字版的内容，光看“新用户老用户，看不到看得到”这几个字，就能把人绕晕，绝对有人要反复看几遍才能看懂。所以汇报有句话，叫做字不如表，表不如图。总结排查数据问题的基本思路和其他解决问题的思路都是类似的：是什么、为什么、怎么办。确认问题和缩小问题范围，都是为了确认问题到底是什么。这个环节我们常用细分分析，从肚子疼缩小到胃疼。但要注意不要过度分析，初步锁定了问题表现之后，就要马上进入“为什么”的环节。要解决为什么，单纯的细分分析是不够的。这时候必须先了解这个数据到底怎么来，然后再顺藤摸瓜把数据产生的环节都排查一遍。或者直接找专家，看能不能直接提出假设，直接验证假设即可。如果找到了为什么，那“怎么办”一般也就很简单了。数据分析师要做的是把这个问题的情况跟各方说清楚，拉几个相关人员开个会讨论一下基本就能解决。这个环节一定要注意邮件或者ppt的可读性，你自己参与全程当然很清楚，但要让别人一眼就看懂就是一个技术活了。数据问题毕竟产生机制是死的，搞清楚产生机制慢慢排查总能找到原因。这次用这样一个简单数据bug的分析案例，为之后的业务分析思路文章做一个引子。