基于前期准备工作，接下来就是异常排查步骤了，异常排查主要分三步：
1 判断是否异常；
2 最大概率法则归类；
3 闭环。
第一步判断是否异常，有四个关键点：
亲自去看数据准确性，不人云亦云，比如业务方说 DAU 下降了就立马去调查，这是不对的，而是应该亲自查看数据是否真实，有时候业务方不一定多专业，也会出现错误。时间轴拉长，看是近期异常还是历史异常，一般分析师看数据时习惯看近一两周或一个月的数据，然后突然出现波峰或波谷就认为数据异常了，但实际上往往不是。我们一定要拉长时间轴，如果仍出现波峰或波谷可能就真的出现异常了。看和该指标关联的其他指标或其他核心指标是否也异常，比如 DAU 异常时，需要查看自流、渗透率是否异常，如果也异常就需要一起解决，而不是按下葫芦浮起瓢，反复做无用功。
找到一个关键人物（产品/数据），提前沟通，也就是当我们确认是数据异常后，找经验丰富的人提前沟通，看他们对此是否有什么见解，往往经验能够快速的定位问题。
第二步就是最大概率法则原因归类，
很多分析师遇到异常时无从下手，抓不到问题主线，无法对问题进行有效分类，而我把异常问题分为了六大类，基本上所有的异常问题都归属于这六大类。
假期效应：开学季、暑假、四大节、当地节日；
热点事件：常规热点（世界杯）、突发热点（爆款 IP）；
活动影响：双 11、618，公司层面活动；
政策影响：互联网金融监管，快递实名；
底层系统故障：数据传输、存储、清洗有无问题；
统计口径：业务逻辑更改、指标计算方式更改。
所以当我们遇到问题时，就可以按照降序在这六大类中逐一排查找到问题原因。
第三步就是闭环，当我们排查出问题原因后，一定要形成闭环，关于闭环有三个点：
持续跟踪后期数据是否再次异常，比如当我们排查出原因后，产品做相应的改进，而问题仍在就说明前期排查问题出错。
记录、沉淀、文档化，因为后续我们可能还会遇到相同问题，所以记录文档利人利己。
邮件化，只有确认没有问题再发邮件给相关方，描述影响范围和主要结论即可。
举个例子，某 App 海外版的主要用户在东南亚地区，某天 DAU 突然涨到 5000 万，与历史数据相比明显异常，问了很多人之后，发现数据采集、传输、活动、业务口径、常规热点等都没有变化。
这时你先不要困惑，我们按照问题归类逐一排查，发现爆款 IP 没有排查到，我们就按照这个点继续排查数据，果然发现因为某国宝级的明星突然去世带来了 App 大量访问。因为在海外，信息传输比较慢，而突发事件国内用户无法快速知道，所以分析师发现流量提升后应该快速反馈给业务人员，业务确认没问题后立刻调动运营资源对该明星进行全方位解析，持续蹭热点把事件发酵到最大化，养成用户口碑。
及时地响应事件后，整个 App 的 DAU 上涨了 10 个点，而一般的产品运营优化很难达到这个效果，针对这样的突发事件并不是每个分析师都能够遇到，但遇到异常数据一定要多尝试，虽然很多分析师排斥数据异常，但优秀的分析师还是能够从异常中发现业务增长点。
所以遇到问题时，要有耐心总会有所发现。
