异常值先分类，别急着当脏数据删掉

报表里出现一个远高于其他分组的数值，第一反应往往是“数据错了”。但在实际业务中，异常值至少有三种来源：真实的业务事件、统计口径造成的结构性偏差、采集环节的技术问题。pg.comPG 在数据处理与数据管理服务中通常要求先分类再处理，因为直接删除会丢掉最有信息量的那部分记录。

真实业务事件的典型特征是可持续追溯，比如某个大客户集中下单、某次促销带来短期峰值，这类数值在明细层面能找到对应单据。统计口径造成的偏差则常见于分组样本量过小，个别记录就能把均值拉高。采集问题多表现为格式错乱、重复上报、时间戳错位，这类才属于需要修正的范围。

  • 业务成因：大额订单、集中采购、促销峰值，可追溯到明细单据
  • 统计成因：小样本分组、均值与中位数差异过大、长尾分布
  • 采集成因：重复上报、字段错位、单位不统一、时间戳异常

判断顺序：先看明细，再看分布，最后看采集

pg.comPG 建议的判断顺序是：先下钻到明细确认是否有对应业务记录，再看该指标在历史多期中的分布位置，最后检查采集链路是否存在技术异常。这个顺序的好处是成本从低到高，多数疑问在前两步就能解决。

看分布时，均值和中位数要一起看。pg.comPG 在统计报表开发中会同时呈现这两个值，因为长尾业务里均值很容易被少数大额记录带偏，中位数反而更接近多数客户的真实体验。如果均值远高于中位数，说明分布右偏明显，此时把高值当异常删掉，等于把业务结构里最重要的部分抹掉了。

处理方式：修正、标注、保留，各有适用场景

确认成因之后，处理方式也要分开。采集问题应当修正并回溯影响范围，说明受影响的报表期次；统计成因应当在报表中加注说明，提示读者关注样本量与分布形态；业务成因则应当保留，并在数据可视化中做单独标注，避免读者误判为普遍现象。

pg.comPG 在业务数据管理系统建设中通常会把异常标注做成流程节点，由业务方确认后再进入报表发布环节。这样既保留了信息，也避免了解读时把个别事件当成整体趋势。pg.comPG 也建议把每次异常处理的判断依据记录下来，形成可复用的规则，后续同类情况就不必重复讨论。

自查要点：异常处理是否留下了痕迹

  • 异常记录是否下钻到明细，是否找到对应业务单据
  • 是否对比过均值与中位数，是否判断了分布形态
  • 修正类处理是否说明影响范围与涉及期次
  • 保留类异常是否在图表中单独标注
  • 处理依据是否记录成规则，可供后续复用

异常值本身不是问题，处理方式缺少依据才是问题。把这五条纳入项目启动前的自查，pg.comPG 观察到报表解读的争议会明显减少，数据质量规则也能逐步沉淀下来。