WhatsApp筛号结果怎么看？字段含义、隐私边界与CRM回写顺序

一份 WhatsApp 筛号结果摆在面前，先记住一件事：整张表里，唯一能用来做“删除”这个动作的，只有“是否在 WhatsApp 上开通/注册”这一个字段。 其余的最后上线时间、头像、个性签名、账号类型，全部受用户自己的隐私设置控制，只能当作加权标签，不能当作剔除依据。很多名单的质量事故，就出在把“查不到”当成了“没有”。

下面按你实际打开文件的顺序说：先怎么分层，再逐个字段是什么意思、边界在哪，然后是处理顺序和回写字段的设计。

第一步：把结果分成硬分组和软标签两层

硬分组只有一个维度——号码在 WhatsApp 上是否注册。大多数平台会直接按“有效 / 无效”两组返回或分文件导出，字段名各家不同（可能叫 status、registered、is_valid 或中文的“已开通/未开通”），以你所用平台的文档为准，不要凭字面猜。这一层是布尔值，可以直接作用于数据库。

软标签是活跃度、资料完整度、账号类型这些附属属性。它们描述的是“这个号码对陌生人公开了多少信息”，而不是“这个号码有没有人在用”。这一层只沉淀为客户画像上的元数据，不参与删号。

把这两层分开，后面所有判断就不会串味。

逐个字段：含义与边界

是否开通（Registered / Status）

返回“未开通”通常意味着这个手机号从未激活过 WhatsApp，或者账号已经彻底注销。这组号码可以从工作名单中剔除或单独归档，避免后续系统反复对它们发起无效调用。

需要注意的是，这个状态本身有时效。号码会被运营商回收后二次放号，用户也可能新注册或注销账号，所以“已开通”是检测那一刻的事实，不是永久属性。周期性使用的名单要记录检测时间。

最后上线时间 / 在线状态（Last seen / Online）

这是最容易被误读的字段。WhatsApp 的隐私设置里，“最后上线时间和在线状态”可以由用户选择对所有人、我的联系人、我的联系人除了…、或无人可见。只要用户选了后三者之一，非联系人就拿不到这个值。

除此之外，看不到对方的最后上线还可能出于其他原因，比如双方并未互相保存为联系人，或者账号侧的可见性限制。也就是说，空值是多因一果。

正确用法：有近期时间戳 → 作为“近期活跃”的正向加权；为空 → 记为“未知”，不做任何结论，更不能据此剔除。如果你把空值当成“不活跃”写进 CRM，等于把一批注重隐私的真实用户标记成了垃圾数据。

头像与个性签名（Profile photo / About）

同样受隐私规则管控，可以设为仅联系人可见或完全隐藏。能返回头像地址、能返回 About 文本的号码，公开度高，通常是真实在用的个人号或商家号，适合排优先级时加权。

反过来不成立：没返回头像只说明这个账号对陌生人隐藏了资料。有些市场和人群普遍不对非联系人公开头像，如果你的名单集中在这类地区，按“无头像=低质量”排序会造成整体性误判。

账号类型（个人号 / WhatsApp Business）

部分检测结果能区分普通个人账号和 WhatsApp Business 商业账号。商业账号往往带有公开的企业资料、经营类目或服务简介，B2B 场景可以据此在 CRM 里直接打上“机构/商家”属性标签，做分层管理。展开的处理细节可以看WhatsApp Business 号码检测怎么做。

各平台能返回的检测项并不一样，也会调整，具体清单和计价以对应平台页为准。

如果无效率高得离谱，先回头看名单

遇到无效比例明显异常，第一反应不该是怀疑检测结果，而是检查提交前的号码格式。最常见的三类问题：号码没统一到 E.164 国际格式、保留了本地拨号的前导零或国内冠码、以及阿根廷的 9、墨西哥的 1 这类历史遗留的特殊编码。这些号码提交上去，返回“未开通”是正常的——它们本来就不是一个能被识别的号码。

格式清洗的具体规则见 WhatsApp E.164 格式转换规则，多国混合名单的拆分方式见国际号码检测的三层处理顺序。

完整处理顺序

1. 预处理：统一 E.164、去重、按国家区号拆分。多国名单分开跑，出问题时能定位到具体市场。
2. 基础检测（按需）：空号、设备类型、高风险号等号码本身的属性，先把明显不该进平台检测的号码筛掉。
3. 平台检测：提交 WhatsApp 开通状态及可得属性，按有效与无效分组取回结果。
4. 分流回写：硬分组写布尔字段，软标签写元数据。

轮到实际处理手上那份名单时，NexCheck 支持在控制台直接上传 txt 或 csv，按有效与无效分组导出，也可以走 REST API 提交、Webhook 回推结果；按条计价，具体检测项和单价在 WhatsApp 平台页上看。如果名单跨多个国家，先到区域页确认各国号码格式和当地主流平台，再决定这批号该筛哪个平台。

网页端还是 API

判断标准是频次，不是名单大小：

• 一次性、临时的名单 → 控制台上传、导出表格，人工接收结果最省事。
• 周期性跑、结果要回写系统 → 走 API 提交 + Webhook 接收回调，省掉人工搬运和轮询开销。具体对接方式见 WhatsApp 筛号 API 怎么接入，回调方式的取舍见号码检测用轮询还是 webhook 回调好。

回写 CRM 的字段怎么设计

建议至少三类字段，关键在于区分“确认为否”和“不知道”：

• whatsapp_registered：布尔值，允许为 null 表示未检测。不要用 false 兼表“没查到”。
• whatsapp_checked_at：检测时间戳。没有这个字段，你就无法判断某条记录该不该重跑。
• 属性类字段（最后上线、有无头像、账号类型）：缺省时一律存 null，不要落成 false 或 0，否则半年后没人记得那个 0 是“确实没有”还是“没拿到”。

几条别踩的结论

• 无头像 ≠ 空号，只是对陌生人隐藏。
• 无最后上线时间 ≠ 僵尸号，多半是隐私设置。
• 已开通 ≠ 名单里记的那个人还在用这个号，号码存在转手和二次放号。
• 任何状态都有时效，长期使用的名单需要设定重检周期。

把“不可推断”和“确认为否”分清楚，是这份结果里最值钱的一条纪律。软标签用来排优先级，硬分组用来清数据，两者不要混用。