发送前号码侦察：lookup 保护预算

多数「送达」工单其实是名单卫生问题，只是披上了网络事故的外衣。调路由、怪走廊之前，先问：这条消息该不该发。号码侦察——核对形态、线路类型、明显垃圾——是认真的 B2B 团队保护预付费钱包和 OTP 转化的方式。先发再查，等于把每个死号都伪装成一次网络故障。

IOSOR 把 lookup 放进与消息相同的 white-label prepaid 模型：充值同一钱包、只调用 live 能力、错误对客户端安全。月平台用量接近 USD 1,000+ 时，可避免支出样本以及 lookup→send 关联会进入更紧密的商务复盘。先拿证据，再谈扩量。

lookup 是什么——以及不是什么

lookup 是发送前情报，不是收件箱保证。它帮你：

• 丢掉格式错误或不可能的目的地
• 在策略需要时标出 VoIP 与 mobile
• 在 SMS / verify 尝试之前减少死号支出

它不能替代同意、内容合规或走廊健康。目录 live 却没有发送决策钩子，只是一份报告，不是控制。详见 发送前先做号码查询。把 lookup 当「已送达」证明会误导产品：线路类型无法保证用户打开 OTP。没有决策钩子的 live 能力，财务月底看到的仍是说不清的借记。

产品团队忽视的预算保护算术

把 lookup 与 短信分段记账 配对，让财务读同一套故事。一本无法解释「为何对死号尝试两次」的预付费钱包，不是预算工具——只是收据打印机。一次 lookup 借记对比两次死号 SMS，应出现在同一张表上。接近 USD 1,000+ 时，说不清的双次尝试会成为商务复盘里的硬伤。

把 lookup 放在漏斗的哪一层

1. 注册 / 导入 — 入库前丢掉明显垃圾。
2. OTP 之前 — 尤其是高成本目的地类别。
3. 活动之前 — 批量卫生，而不是半夜救火。

缓存要克制：过期 TTL 会误伤好用户。写清刷新策略与负责人。lookup 仍为 in setup 就不是生产闸门——能力尚未就绪时，不要对外承诺发送前卫生。导入管道若跳过 lookup，脏名单会在第一次活动时一次性烧钱包。

OTP 与 verify 的回报

verify 在被滥用时很贵。lookup 加上冷却策略，优于通道跳转。对照 OTP 路径上的 lookup 回报 与 OTP 前先分清 VoIP 与手机。把 lookup 当作第一次借记前的过滤器，而不是钱包烧完后的复盘。没有 lookup 的通道跳转，只是把同一堆垃圾搬到第二条走廊。OTP 重发若无视 lookup 结果，冷却形同虚设。

危险信号

• lookup 像一笔说不清的附加费
• lookup 结果与发送决策无关联
• 满口「HLR」却没有对客户安全的错误
• 用 lookup 顶替合规
• 死号仍被自动重试
• 目录仍为 in setup 却承诺 lookup
• 客户端错误出现上游品牌名称

从 IOSOR 开始

在大量发送营销活动或高成本的验证码流程之前，请在控制台中配置发送前号码查询网关。将实时的查询响应直接路由至发送前分发过滤器，以瞬间剔除无效格式与未分配的线路类型。启用查询网络钩子以记录运营商情报，并在发出单条短信前优化您的重试逻辑。

IOSOR 要点

发送前号码侦察将盲目的短信群发转化为主动的预算保护屏障。在触发验证码或批量推送前评估线路类型与未分配的目的地，能够减少资金浪费并保持良好的送达率指标。通过在控制台配置实时查询接口，运营商可以有效识别虚拟号、固定电话及无效号段，从而在计费发生前拦截高风险请求。请务必将号码查询功能直接集成到您的用户注册流程及验证码前置路由网关中，并根据业务需求设定清晰的生存时间缓存策略，以平衡查询成本与数据时效性。切勿将宝贵的营销资金浪费在反复重试已知无效的号码上，也不要误认为号码查询可以完全替代合规的用户选择加入机制。为了优化全球发送成本，建议定期导出账本记录并对比查询前后的转化率差异。在执行大规模发送任务前，请参考 /learn/sms-delivery-best-practices 了解更多关于路由优化的细节。同时，针对不同国家和地区的运营商特性，开发者应在 UTC 时间窗口内动态调整查询频率，确保在不影响用户体验的前提下最大化预算利用率。更多关于 API 集成的技术文档可查阅 /learn/lookup-api-integration 指南。