在数据分析的世界里，准确识别并修复数据报表中的异常是确保决策有效性的关键。本文深入探讨了用户行为分析中的异常识别与修复手段，从理解业务背景和客观规律到具体的修复策略，为读者提供了一套全面的指南。

从《用户行为分析-构建篇》到本篇已经是第三篇了，分别围绕用户行为分析的全流程讲述了数据集构建-分析方法-异常修复这三趴，虽然三篇是围绕流程互通的，但也因为主讲的内容会分布到不同的职能上，所以有些读者群体们产生不了多少兴趣，或者说工作上还没有遇到诸如此类的问题还不太用的上，但是没有关系，我依旧期望在你需要的时候，能够在搜索结果或是收藏夹中出现它们的身影，为你提供一套标准可用的用户行为分析指南。

一、如何识别报表数据异常

为什么要留意报表中的数据异常？你听我放屁：天灾人祸你要渡过难关、泼天富贵你要想法接住、事在人为你要对比效果。简言之帮助产品运营良性发展。

1、识别与修复的重要性

数据报表会用作业务决策参考，不想被带偏就要确保准确性，所以当我们完成报表搭建以后，先不考虑业务数据是否漂亮、是否有外界因素干扰，一定要先检查从数据加工到报表建成的这个过程中是否有纰漏，如果这个过程没有问题，数据依旧异常，则要进一步观测数据采集阶段是否有问题，只有当数据从采集到加工成报表都没啥问题时，最后代入到业务场景中分析异常原因才有价值。

在工作场景中的价值

作为一名非数据分析师，你可能是PD、UE、UX、UI等，但作为产研人员你不关注业务数据有些说不过去，而掌握不同程度的数据异常识别与修复能力，可以更便捷的满足自身业务数据分析的需要。虽然张嘴提数据需求很快，但是需求什么时候落地你还得静候佳音，所以通过自助分析减少对BI同学的依赖，加快响应何尝不可；

好了，再聊回来如何识别异常～

清晰业务背景与客观规律

事实上要搞清楚你的数据报表有没有问题，最简单快捷的办法就是了解业务与产品属性后找客观规律，因此数据不要揪着那么一两天的看，也不要只停留在报表上找问题，最好是把数据的周期范围拉长，以形成参考对比便于观察趋势变化，如果数据指标比较单一，不能构建趋势或环比，那么你也可以结合业务流程、指标结构、行业标准等来看，看数据指标是否处于合理的水准。

如果上述的流程方法你一个字也没看进去，那么请看这个例子：

如果当产品内部没有主动的变量事件，外部也没有明显的被动事件影响，且数据指标还不符合客观规律或业务预期，那么大概率报表搭建的过程中出了Bug，准备找问题吧hhhh

以下是针对业务背景与客观规律的变量整理，一些常见的基本都概括了，在进行报表数据异常排查时可以参考；

通常客观规律是比较能够反映出数据异常的，因为数据有一定的标准或规律可言，另外就是配合业务背景或行业状况来解释或预测数据的变动，这两套数据异常识别方法，基本上可以用一套决策树来概括；

业务数据-多表对比验证

用户行为分析构建通常会单独创建一套行为数据采集系统，这表明相关的数据表不止一套，一般还有业务后台的数据、渠道投放数据等，这个时候我们就可以将相关的核心指标或大盘数据进行抽样对比，如果数据对不上，那就代表数据报表搭建的有问题，一般业务后台的接口数据是不会出错的，遇到数据对不上就老老实实检查报表或采集系统吧。

二、如何修复数据指标异常

一套用户行为分析报表刚构建好之时，用户行为指标异常无非就两方面；

一方面就是用户群中确实有异常的行为带来了异常的数据或趋势，这些是要结合业务营销或外界因素来找原因了，但可以肯定的是异常数据是对的，没有说谎，例如商品的优惠券配置错了，给出了惊人的优惠，导致下单量数据与趋势远超以往，数据看起来是异常的，但却是能找到对应异常原因的。

另一方面就是你的数据采集到计算加工出错了，事实上这种情况也时有发生，常见于多个同事交叉作业、采集需求不完善、数据维护不规范、工作量较大出现纰漏、数据处理不熟练等。

那么接下来就好好跟大家唠唠数据报表构建完后，如何修复这些异常问题。

修复过程我结合我个人的习惯与过往经验拆分成了六个部分，相较于专业的BI数字建模开发，可能还是有些差距的，但是也算够用，起码能够自己Hold住大多问题，剩下的疑难杂症再抱抱BI同事的大腿即可～

1、定位数据异常

这是数据异常修复的首要工作，如何识别异常已经在上一趴聊过了，那么如何定位问题主要有两个行动方向；

需要注意的是在数据验证的过程中，采用相同条件的过滤或数据范围，保证口径的统一，那么当你找到数据异常发生在底层还是在中间加工层后，那么就进入下一步骤治理工作了。

2、给数据打补丁

给数据打补丁就是加筛选条件，发现数据有异常后将异常的部分过滤掉即可，通过观察这些异常数据的规律来界定一个数据有效的范围或标准，然后在数据报表上添加数据过滤或判断，通常数据或报表工具一定会具备这些功能，在前文有个清洗调研问卷的例子还有印象吗？其实就是将无效的用户反馈剔除即可；

※你可能会好奇这些脏数据从哪里来的？

除了以上交互逻辑不完善导致用户填入的数据外，还有一些可能是来自产品内部测试、脚本测试、数据爬虫、灰产攻击、数据采集Bug等，所以如果团队内部有大量测试或脚本动作，一定开个名单把这些数据过滤掉，其他的则可以通过观察产生异常数据的账号、设备信息、MAC地址、参数内容、IP网络等信息来找规律和数据规避，例如写一个条件判断的计算列，有效为0无效为1，数据分析时过滤掉为1的即可；

3、修正函数算法

在我的过往经历中，指标度量的出错通常有两种情况，一个是你的函数能跑，但写的不符合指标的预期，另一个是你计算过程中，引用了错的字段参数，这两种情况都会使得最终的指标度量不对。

如果你函数用的比较熟练，那么通常出错的原因往往是用了不对的字段参数进行计算，如果你对业务数据不够熟悉，或是业务数据的口径不规范，都很容易出现这种问题，这种情况就需要你进行抽样与数据试验了。

a. 字段参数口径选用

最简单办法就是定位到存在有差异的数据源后，观察具备相同属性的字段参数那个更完整或更准确，例如一套数据集中有两个字段参数可以视为用户个体，但是进行列统计时两个数据不相等，那么我们就要在原始数据集上进行排查，看看数据缺失的部分是否符合逻辑或是数据采集有漏洞，然后结合业务情景或数据详情，来挑选出一个靠谱的字段参数用作业务指标度量计算，修复之后呢，也建议找个地方进行备注，特别是数据血缘比较复杂时，便于维护；

b. 指标函数验算

如果对各种函数的用法不熟悉，或是某个BI工具没用采用传统的SQL函数，导致你的指标度量计算出错概率也是很大的，一般遇到这种情况，我都是先锁定到一定范围的数据，然后通过一些简单的函数加人工算出指标值，然后找可行的函数来加工或调整出这个指标值，之后再随机采样验证一下是否准确，如果遇到实在搞不定的数据运算或函数使用，那就问问AI大模型，或者平台客服，反正我这边BI平台的语法群里的消息基本没有停过～

4、下钻指标度量

此项是针对套娃式函数运算的指标场景，即当前的指标函数计算中，用到了其他计算列或是度量，但这些计算列或度量本身又是由其他计算列或度量构成，这就意味着引用的下游计算列或度量一旦有误，上游指标全盘崩坏，这种情况也是排查和修护中比较恶心的，你得像剥洋葱一样一层一层的找问题，好在改完一个问题后，其他也能变回正常，此类问题修复可以参考以下决策树；

5、纠正数据采集

针对用户行为数据采集，如果起初的埋点采集需求没有写清楚或开发验证中有了遗漏，就会导致进行指标或用户行为路径分析时缺少关键数据或是数据对不上，这就是典型的数据采集事故，即上报完整性有问题、上报准确性有问题，如果产品迭代后，相关埋点没有及时迭代更新也会出现诸如此类的问题。

你以为这种问题是少数？实际上很多时候开发者完成行为埋点开发后，业务方都没有仔细测试验证过，都是简单看两眼就好了没问题了，然后在做数据报表或相关分析时，才开始查缺补漏找开发返工或补充，提过行为埋点需求的同学们，试问自己，每次埋点开发完后有仔细测试验收过么？有的话，继续保持！

6、培训和交流「交流中」

这一趴从企业流程管理或是个人发展学习都是有益的，特别是多个同学交叉作业的情景，无规范无维护后续越乱套我们越难受，让改一套报表遇到点儿问题都要找半天，真的还不如新建一套报表来的舒服，所以数据采集加工、口径统一、语法技巧等都是可以多交流的，甚至沉淀内部材料或分享都是不错的。

就例如指标的函数加工，之前我为了输出业务的期望指标，我写了好几套计算列才把结果套出来了，但是后来请教BI后，对方只用了两套语法就把度量指标弄出来了，看完后我表示妙啊～

至于现在，基本的数据分析或报表构建我都能自助解决，完全不依赖数据相关的同事，同样的数据需求，如果我有时间的话，别人的还在等数据同事那边的排期，我这边就开始了，人家开始时，我这边已经结束了。

三、行为分析的延展应用

前文分享了如何进行基础的用户行为分析，实际上行为分析的妙用不止于此，如果这些行为数据妥善应用还能为业务带来不少价值，如通过机器深度学习构建预测模型、更深入的偏好分析应用、异常或潜在威胁的行为监控等。

1、异常行为监控

用户行为异常分析可以帮助业务发现不正常的用户行为，不同类型的异常行为对业务也会造成不同程度的威胁或负面影响，因此可以构建一套用户行为监控系统（根据业务需要提需求或接入第三方服务即可，不是让你写代码哈），根据不同类型的用户行为定制相应的响应策略，这样可以减少潜在的威胁以提升安全性或用户行为规范性，通常来讲这些异常可以分为两大类；

一类是用户不合规的行为，前者可以通过评估行为的恶劣程度来进行账号警告、冻结等来处理。

另一类则是灰产攻击，后者的容忍度相对会更低，一旦通过行为或其他数据确认后，就会进行拦截屏蔽或是相关账号封禁处理。

至于这些异常如何识别，在第一部分的【清晰业务规律与客观规律】或第二部分的【如何给数据打补丁】都有提过，基本上就是用户行为异常或设备属性异常，那么在发现问题以后，最好就是将这些异常的特征记录在案，并通过算法或一些自动化手段，融合到异常行为监控系统中，一旦发现符合特征的潜在威胁就提前告警或拦截屏蔽等，并且持续的优化迭代，以减少人工投入的成本。

2、用户偏好系统

相比于预测模型，用户偏好系统大家肯定更熟悉一些，一般可以分成三个部分，即用户画像构建、用户偏好分析、个性推荐系统，这里就不展开一个个聊了，其用途与构建的思路方法我用表格整理了一下可供参考，如果有兴趣可以专门找一下相关的资料看看；

3、行为预测模型

行为预测模型的本质是机器深度学习或AI相关的应用，说人话就是不定期的把业务数据整理好了喂个算法服务，然后算法根据数据产生一套预测结果，然后你把结果用于业务决策或定制化营销上。

因为训练模型需要一定成本，所以训练前需要明确有业务上的需要，以及有合适的行为数据可用于加工后进行模型训练，那么具体如何继续模型训练我就不展开了，很多人可能疑问这些行为预测模型具体有什么东西，能起到什么用途，对此整理了一下五点可供参考；

四、连续三篇全流程与决策树总结

整个流程事件的步骤与决策方法概括；

三章内容整合路书：