号码状态查询的六个报表问题：成功率该怎么算
成功率这类指标没有唯一算法，只有一种算法加一句说明。这篇用六个问题固定号码状态查询的报表口径：分母用哪个数、无结论算哪一档、跨天批次怎么切、两家服务方的数怎么合。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
先给答案：成功率这类指标没有唯一算法，只有一种算法加一句说明。报表出问题多数不是数字算错了，而是分母、归类、时间窗这三样在不同人手里不一样。下面六个问题按报表从建到用的顺序排开，每个都给一个能直接照做的定法。
名单条数、去重后的条数、实际调用次数，这三个数算出来的成功率能差出好几个百分点。名单条数包含重复号码与格式错误的行，拿它当分母，成功率会被格式问题拉低，看着像接口不行，其实是清洗环节没做。
稳妥的定法是分成两栏：对外那一栏按去重后的号码数算，用来衡量名单质量；对内那一栏按实际调用次数算，用来衡量通道健康度。两栏并存不冲突，冲突的是只留一栏还想同时回答两个问题。
都不算。取不到结论表示这一次请求没拿到有效结果，可能是号段本身不在覆盖范围，也可能只是一时波动。把它塞进失败里，失败率会被无结论的号码淹没，接口抖动这类真问题反而看不见；塞进成功里，数据质量的问题又被藏起来了。
做法是单列一档，通常叫未知或待定，并且带上原因大类。分类不用太细，能分出「号段不覆盖」与「本次未取到」两类，后续排查就有方向。
先查两次的口径有没有变，再看两次的时间窗。同一批号码在不同时段跑出不同比例很常见，关机、通话中这类状态本身就会翻转。差别超过经验值时，值得按状态分层看一遍，号码状态查询结果比例异常：六个问题给的顺序是先看无结论、再看瞬时状态、最后看稳定状态。
确实要报一个数就报最近一次，并且注明查询时刻。历史报表不做重算——重算会把不同口径的数字混进同一张趋势图。
看谁在用。运营与业务看日线，方便和别的业务数据对齐；技术排查看批次线，因为一批任务的名单是一起澄清的，结论也一起回来。跨天的批量任务最麻烦，凌晨开始跑、早上才结束，按自然日切会把一批拆成两天，两天的数字都不好看。
常见的折中是给批次加一个归属日期，规则定死在任务里：以任务启动时刻所属的日期为准。这条规则写进文档之后，跨天任务就不用每周被问一遍。
过渡期同时用两家的时候，这个问题一定会被问。答案是不能直接合：两家的状态划分、无结论的判定、计费与重试的口径都不同，直接并成一条线，波动来自口径而不是服务本身。
可行的做法是分开两条线各自成图，再挑几个定义最明确的共同指标做一张对照图，比如去重后的待查量、明确不可达的数量。过渡期一结束就把旧线封存，别让它继续影响趋势判断。
三个就够：去重后的待查量、明确不可达的数量、取不到结论的数量。业务方要回答的无非是这批号码能不能用、能用的有多少，三个数字直接把答案给出来。成功率、响应时间、失败率属于技术指标，混进业务报表只会引来更多追问。
如果业务坚持要看成功率，就把说明写在指标旁边，标明分母是哪一个。指标名称后面加一句口径说明成本很低，省下的是每周一次的「这个数为什么和上次不一样」。结论本身怎么落到每一行、被问起时怎么解释，号码状态查询结果的血缘：结论从哪来讲的是这层。
有几个误解顺带说清。一是只用一栏成功率：对业务说百分之九十几，技术按另一套分母算出来是百分之七十几，两边争同一件事。二是把无结论并进失败，导致抖动与号段不覆盖这两类完全不同的问题混在一起，排查时无从下手，结果表数据质量：号码状态查询的六个问题里分过哪些属于数据质量、哪些属于通道问题。三是口径改了不记版本，季度对比时拿两套定义算出的数字比高低。三个误解指向同一件事：指标不是算出来的，是定义出来的。
判断一张报表能不能用，看三处：分母写没写、归类分没分档、时间窗写没写。三处齐了，报表就经得起追问；缺一处，早晚要返工。
还有一类号码要在口径里单独放：转售企业放出的号段、只给设备联网用的卡片、登记地挂在境外运营商的号码，请求会正常发出去，但状态判定这一步不会发生，报表上要把它们归到取不到结论那一栏，别混进失败率。
起步阶段不用自己造轮子，【手机号状态查询服务】这类服务直连移动、联通、电信三网，返回八种状态并支持携号转网识别，鉴权走请求头携带 AppCode，按次计费、即买即用，字段与取值定义以商品详情页文档为准；指标怎么定义，仍然取决于你自己的报表要回答什么问题。
文章评论
发表评论
请先注册/登录后评论