结果表数据质量：号码状态查询的六个问题
号码状态查询的结果表不是查完就放在那里的存档，而是一份会持续变旧的台账。这篇用六个问题讲清结果表里的脏数据分哪几类、同一号码两条结论留哪条、时间戳为什么比结论重要、空值与字段缺失的区别、体检节奏怎么排，以及查出脏数据要不要补查。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
简短的回答是：把结果表当成一份会持续变旧的台账，而不是一份查完就不用再动的存档。它需要有人按节奏体检，用规则挡住新产生的脏行，也给旧行定一个清理期限。下面六个问题，是业务方拿这张表做决策之前问得最多的，顺序基本就是排查顺序。
常见的就五类：重复行、空值、口径混用、时点缺失、归属不清，前面那张图列的就是它们的来源。
重复行多半来自批次重跑，同一个号码在同一张表里落了两条结论，下游按号码取一条时取到哪条全看排序。空值是上游返回缺字段时被当成空串写进去。口径混用是八种原始状态和内部那套可用与不可用挤在同一列，两边的取值域互相覆盖。时点缺失是行上只有结论、没有查询时间。归属不清是行上缺批次号与来源标识，出了问题找不到是谁提交的。
前两类占绝大多数，通常一条去重规则加一条非空校验就能挡掉大半，剩下的三类得改表结构才收得住。
先分清这两条是怎么来的，再决定留法。
如果是重复提交造成的重复行，那就属于脏数据，按号码加批次去重，留一条。判据很简单：两条结论的状态与时间几乎一样，只是行多了。
如果是两个时点各查了一次、状态确实变了，这不是脏数据，是状态变化本身。这时候按用途取：只看当前状态给业务用，取最新一条就够；要能解释变化、要支撑投诉复查，就两条都留，各自带上查询时间与来源标识。表结构上多一列来源、多一个时间索引，比事后靠日志倒推便宜得多。
状态是时点值，不是号码的属性。同一句「正常在网」放在三天前和放在三个月前，含义完全不同。
只存结论不存时间的表，用起来是这样：业务方看到一条空号，直接把人移出触达名单，而这个号码上周已经重新启用；客服拿着三个月前的关机结论答复客户，客户当场演示能打通。这类争执最后都会回到同一个问题——这条结论是什么时候取的，如果表里答不上来，就只能重查一遍。
时间戳还有第二个用处：它是复核节奏的依据。变化快的状态给短周期，稳定的状态给长周期，这个划分全靠时间字段算。结论列的取用规则如果和状态字典有过调整，翻一下号码状态检测结果入库：状态码压平之后怎么救能对上是哪一版的口径。
不是一回事，处置方向也相反。
空值表示这一行给不出该字段的值，可能是本次查询没有这项数据，也可能是这行来自更早的版本。字段缺失表示这一版结果表里根本没有这一列，属于结构问题，通常是代码和表不同版本留下的痕迹。
把两者混在一个统计里，体检报告就会失真：空值占比高，说明数据来源或版本有问题；字段缺失，说明发布流程有问题。落库时给空值一个明确的标记值，比留空串强——空串和已下线字段在查询结果里长得一模一样，排查时很难分辨。
分三档，各管一件事。
每天跑规则，挡新增的脏行，规则清单不长但必须齐全：同一号码同一批次只能有一行；结论列取值必须在枚举范围内；查询时间必填，且不能早于批次创建时间；来源标识非空；状态列与结论列不能互相矛盾。
每周抽一批号码重查比对，看结论的翻转比例是否落在正常区间。翻转率突然抬升，多半不是接口的问题，而是名单质量在变差。
每月做一次回溯：按当前口径复算历史结论，清理过期行并按号码状态查询结果表：八千万行之后的归档里的办法压成统计值。
按错误类型分，不要一律重跑。
结构性错误要重算，比如映射表写错、状态列与结论列矛盾。这类用原始状态列复算一遍就行，零调用量，不要把号码再提交一次。
结论确实缺失的（空值那类），按业务价值抽样补查：先补最近要发起触达的那批，其余的挂上标记等下一次复核周期顺带覆盖。全量重跑的账单通常比省下来的那点准确性贵得多。
重复行直接清理，不需要补查，只需要在流水里留一条清理记录，说明清了多少行、依据是哪条规则。
一张结果表值不值得被业务信任，看三个数字：带查询时间的行占比、能归属到批次与来源的行占比、结论列取值落在枚举内的行占比。三个都在九成五以上，这张表可以直接接进决策链路；有一个明显偏低，先把规则补上再谈接业务。
另有一批号码本来就取不到结论——装在设备上的物联卡、转售企业放出的号段、境外运营商的号码。它们不应该出现在空值统计里，单独设一个原因码，体检时把这类行排除在失败率之外，否则你会发现失败率怎么修都降不下来。
数据来源如果是自己直连，维护成本会落在自己这边；起步阶段接现成服务更省事：直连三网，返回八种状态，支持携号转网识别，鉴权走请求头携带 AppCode，按次计费、即买即用，字段与错误码含义以商品详情页文档为准——【手机号在网状态 API】。
文章评论
发表评论
请先注册/登录后评论