若数据产品 DAU 比较大，动辄几百万上千万，甚至过亿的那种，核心数据中肯定会有一些数据是波动比较大的。俩原因：一是目前数据本身有问题；二是业务本身有问题。
需要我们能够透过问题看本质，进行数据异常排查，异常排查的前期准备：
业务理解：
比如某个 App 的 DAU 低于1000w，那么请问这个 DAU 代表的是什么行动的DAU，是在进程中还是需要打开 App，还是必须有主动行为，这理解起来是不一样的。第二个指标口径，同样是 DAU 一千万，是 Android 还是所有系统。第三个产出过程，对于 DAU 一千万目前是由哪份日志做了哪些数据清洗计算出来的，只有了解清楚这些才能够开始异常排查。
指标口径：
若产品已经比较成熟，但指标口径没有文档化，所以可能对业务理解不深，这个时候面对领导的提问就会手足无措，一旦不能解决问题就会失去信任，所以前期准备工作一定要做好。
当前数据产出过程：
举个例子，市场部领导看了某一张日活数据和你提供的数据相差较大，就来询问是怎么回事。实际上这时你首先需要弄清楚他看到的数据表是怎样产出的，然后指标口径是什么，指标的业务含义是什么，只有熟悉这些情况后才能分析出产生差异的原因。
有了前期准备工作，就到异常排查步骤了，异常排查主要分三步：
1.判断是否异常；
2.最大概率法则归类；
3.闭环。
第一步判断是否异常，有四个关键点：
亲自去看数据准确性，不要人云亦云，比如业务方说 DAU 下降了就立马去调查，这是不对的，而是应该亲自查看数据是否真实，有时候业务方不一定多专业，也会出现错误。
时间轴拉长，看是近期异常（3 个月）还是历史异常，一般分析师看数据时习惯看近一两周或一个月的数据，然后突然出现波峰或波谷就认为数据异常了，但实际上往往不是。我们一定要拉长时间轴，如果仍出现波峰或波谷可能就真的出现异常了。
看和该指标关联的其他指标或其他核心指标是否也异常，比如 DAU 异常时，需要查看自流、渗透率是否异常，如果也异常就需要一起解决，而不是按下葫芦浮起瓢，反复做无用功。
找到一个关键人物（产品/数据），提前沟通，也就是当我们确认是数据异常后，找经验丰富的人提前沟通，看他们对此是否有什么见解，往往经验能够快速的定位问题。
第二步就是最大概率法则原因归类，抓住问题主线，可以把异常问题分为六大类，基本上所有的异常问题都归属于这六大类。
假期效应：开学季、暑假、四大节、当地节日；
热点事件：常规热点（世界杯）、突发热点（爆款 IP）；
活动影响：双 11、618，公司层面活动；
政策影响：互联网金融监管，快递实名；
底层系统故障：数据传输、存储、清洗有无问题；
统计口径：业务逻辑更改、指标计算方式更改。
第三步就是闭环，当我们排查出问题原因后，一定要形成闭环，关于闭环有三个点：
持续跟踪后期数据是否再次异常，比如当我们排查出原因后，产品做相应的改进，而问题仍在就说明前期排查问题出错。
记录、沉淀、文档化，因为后续我们可能还会遇到相同问题，所以记录文档利人利己。
邮件化，只有确认没有问题再发邮件给相关方，描述影响范围和主要结论即可。
网友评论