NexCheck-筛号平台
想知道手上这份名单里哪些号码开通了 WhatsApp，可靠的路径只有一条：先把号码改写成 E.164 国际格式 → 剔除固话和非移动号 → 用批量检测服务查平台开通状态 → 按字段分列回写系统。顺序不能颠倒。格式没统一之前跑出来的“未注册”，很大一部分是格式问题，不是账号真的不存在。
先说单个号码：wa.me 能用，但只能一个一个来
把完整国际号码拼进 wa.me/ 后面打开，如果提示号码无效，通常说明该号没有注册 WhatsApp；能进入会话界面则说明账号存在。销售在跟进某个重点客户前用它核对一下是合适的。
但它撑不起名单作业：需要人工点击、依赖本地已登录的账号、结果不是结构化字段，也没有时间戳。更要紧的是，如果用脚本或模拟器把这个动作跑成高频批量操作，很容易触发 Meta 的风控，结果是探测账号被封、出口 IP 被限制，名单反而一条都没清干净。名单量超过几十条，就应该走批量任务的路子。
第一步：把号码改写成 E.164
WhatsApp 按完整国际号码识别用户，规则是：国家代码 + 去掉本地拨号前缀的号码，不带空格、连字符和括号，去掉开头的 0，也去掉 00、011 这类国际长途冠字。
实际名单里最常见的四类脏数据：
- 本地写法带前导
0，例如英国的07911 123456，正确写法是447911123456； - 带分隔符和括号，例如
+1 (415) 555-0132； - 保留了国际冠字，例如
0086138...或01144...； - 干脆没有国家代码，只有本地号段——这类必须先确认名单来源国，否则只能整段丢弃或单独标记。
两个必须记住的国家特例：阿根廷（国家代码 54）需要在国家代码和区号之间加一个 9，并去掉移动号常见的 15 前缀；墨西哥（国家代码 52）在国际格式中需要保留 +52 后面的 1。忽略这两条，整批阿根廷或墨西哥号码都可能被判成未注册，而且这种错误在结果里看不出异常——它们会安静地落进“无效”那一组。
各国号码位数、有效号段和前缀规则不同，同一份名单混了多个国家时，建议先按国家代码拆成多个子文件分别处理，出问题也容易定位是哪个市场的规则写错了。具体到某个国家的号码格式，可以查 NexCheck 的区域方案页。归一化的改写规则可以参考站内这篇：海外号码筛选前怎么做E.164归一化？4类脏号码改写规则。
第二步：剔除固话和非移动号，顺手去重
WhatsApp 主要面向移动电话号码。固定电话并非完全不能注册，但只在 WhatsApp Business App 或 Business API 体系下通过语音验证才有可能，普通个人账号体系里不成立。所以名单里的座机、总机、服务热线，在送去查开通状态之前就该被挑出来。
做法是先跑一遍号码基础检测——空号、设备类型（移动/固话）、高风险号这类基础字段，把明显不该进入下一步的号码分走。按条计价的检测，这一步直接决定后面花多少钱。
去重也放在这里，而不是更早。原因很实际：同一个号码写成 0138...、+86 138...、86138... 三种形态时，只有归一化之后才会暴露成重复项。先去重后归一化，重复项会一条不少地留下来。
第三步：跑平台开通状态检测
到这一步，你手上应该是一份纯 E.164、按国家分组、去过重的移动号名单。提交方式有两种：
- 控制台上传：整理成 txt 或 csv，一列号码，无表头或表头规范，直接上传建任务。适合一次性清洗、市场侧临时名单。文件准备的细节可以看WhatsApp CSV筛号：上传前6处文件准备要点。
- REST API 提交：适合要把检测接进 CRM、需要定期复检的场景。提交后异步执行，任务完成由 Webhook 回推结果，不用一直轮询。
NexCheck 的检测按平台组织，单批不限量，结果按有效与无效分组导出。WhatsApp 这个平台当前能查哪些检测项、每项单价多少，以平台页为准：WhatsApp 能查什么。这里不写死字段清单，是因为可查项会随平台自身的可见性策略调整——某个属性今天能取到，平台改了公开规则之后就可能取不到，按半年前的文档写死映射关系，迟早会在回写环节出错。
第四步：看懂返回的字段
号码状态检测常见的返回维度大致是这几类：
- 是否已开通/注册：这是你最关心的那一列；
- 账号类型：个人号还是商业号（WhatsApp Business），这一列对判断名单构成很有用——B 端名单里商业号占比高是正常的，C 端名单里突然大量商业号，往往说明名单来源有问题；
- 注册时间、活跃度：部分平台可得，用来给名单分层；
- 封禁状态；
- 性别、年龄等公开属性：各平台差异很大，不是每个平台都有。
有两个边界要写进你的判断逻辑。一是头像、签名这类公开属性受用户隐私设置约束，查不到不等于号码没注册，只能说明该用户没有对外公开。二是“未注册”至少有三种成因：号码确实没开通、格式仍不合规（尤其是前面说的国家特例）、平台侧可见性限制。把这三种情况都归因成“这个人没用 WhatsApp”，会让你误删一批真实客户。合理的做法是：如果某个国家的未注册率明显高于其他国家，先回头检查那一批的格式规则，而不是直接判名单质量差。
第五步：回写别只存一个布尔值
只在 CRM 里加一个 has_whatsapp 的是/否字段，用一次就废了。建议至少落这几列：
| 列 | 用途 |
|---|---|
| 原始号码 | 出问题时能追溯客户填的是什么 |
| E.164 号码 | 后续所有系统的统一主键 |
| 国家代码 | 分市场统计、定位格式问题 |
| 是否注册 | 主结果 |
| 账号类型 | 个人号/商业号分流 |
| 检测时间 | 决定这条结果什么时候该失效 |
| 任务 ID | 对账和复查 |
检测时间这一列尤其不能省。号码注销、运营商回收、携号转网都存在时延，一个已经销户的号码在一段时间内仍可能显示为注册状态，各地运营商的回收周期也不一致。有了检测时间，你才能定“超过 N 个月的结果需要复检”这样的规则，而不是把一年前的结论当成现状。结果落库的字段设计可以参考批量号码验证别只看有效无效，结果要按多列落库。
网页端还是 API：按频次和落库方式选
- 一次性或低频清洗，结果人工下载后导入——控制台上传就够了，不用为此排开发排期。
- CRM 里持续有新号码进来、需要定期复检——走 API，提交任务后用 Webhook 接收结果直接写库。轮询和 Webhook 的取舍取决于任务量和延迟容忍度，站内这篇分了档：号码检测用轮询还是webhook回调好；接入的具体流程见WhatsApp筛号API怎么接入。
一个折中的做法是：历史存量名单用控制台跑一次，增量走 API。存量那批往往格式最乱，需要人盯着看几轮结果再定规则，反复改代码不划算。
两条合规边界
第一，名单必须是你自己的客户或联系人数据，来源和用途要合法。检测服务只在任务范围内处理你提交的号码，但数据本身的合法性在你这一侧。涉及欧盟等地区的联系人时，先确认你的处理有合法依据。
第二，不要试图用自建脚本、模拟器或批量注册的探针账号去绕过平台限制做探测。除了封号和 IP 被限制的直接后果，这类方式拿到的结果也不稳定——风控介入之后返回的“未注册”可能只是被限流，你无从分辨。用规范的批量检测通道，结果至少是可解释、可复查的。
按上面的顺序走完，你得到的不是一份“能发/不能发”的名单，而是一份带国家、账号类型和检测时间的结构化数据。要开始处理手上这批号码，可以先在 WhatsApp 平台页确认当前可查的检测项，再决定先跑基础检测还是直接上平台状态检测。
评论(0)