在新西兰WhatsApp筛头像结果里，“没有头像”首先是一个待解释的观察结果，不是“号码无效”或“客户质量差”的判决。同一批+64号码中，头像空值可能来自个人隐私设置、图片已删除、检查时不可见、输入号码没有规范化，或者返回的WhatsApp映射手机号与CRM号码不同。真正有用的工作不是追求更高的头像命中率，而是找出空值由哪一层产生。
先记住三个不等式：无头像 ≠ 未开通WhatsApp；有头像 ≠ 身份已验证；+64号码 ≠ 用户当前居住在新西兰。
先问对问题：你需要的是号码判断，还是头像观察？
许多团队把“筛头像”当作一个万能验证步骤，最后却得到一张难以解释的表。如果目标是判断号码是否开通WhatsApp，应选择WS筛开通；如果目标是观察资料图片是否可见，才使用WS筛头像。任务选错后，即使Excel每一列都正常，也回答不了最初的问题。
新西兰号码管理机构NAD说明，02X主要属于非地理号码并常用于移动服务，而03、04、06、07、09等属于本地号码类别。号码资源按服务类别和代码块管理，并非任何以+64开头的数字串都能仅靠长度判定。可参考NAD对新西兰号码资源的说明。
把“空头像”拆成四种可行动的原因
| 观察到的情况 | 更合理的解释 | 下一步 |
|---|---|---|
| 号码格式异常，同时没有头像 | 输入可能没有正确进入检查范围 | 回看原始号码与+64规范化记录 |
| 已确认开通，但头像为空 | 未设置、不可见或检查时未观察到 | 保留unknown，不把它改写成“无真人” |
| 头像存在，但映射手机号不同 | 输入号码与平台观察关系需要复核 | 建立冲突队列，不自动合并CRM联系人 |
| 同一号码前后两次结果不同 | 头像或可见性会随时间变化 | 保存检查日期，以较新的观察覆盖展示，不删除历史证据 |
这四类问题的处理方式完全不同。若把它们全部压成一个“头像=0”的字段，运营人员只能凭印象解释，后续也无法判断是名单质量变化、任务差异还是个人设置变化。
一个适合实际复核的抽样办法
不要只抽查“有头像”的行。更有效的做法是分别从四个桶中取样：头像可见、头像不可见或未知、映射手机号冲突、号码格式异常。每个桶都保留来源渠道和名单进入CRM的时间，再比较问题是否集中在某个旧表单、展会名单或合作来源。
- 先冻结原始列：保留phone_raw，禁止在原列直接删0、补国家码或改成数值格式。
- 建立号码候选列：只有来源国家明确时，才把新西兰国内写法转换为国际格式；无法判断的行留在review。
- 分开跑任务：需要开通状态时先筛开通，需要资料图片时再筛头像，不用一个字段替代另一个字段。
- 按来源看空值：若某个渠道的未知率明显更高，优先检查该渠道的采集和存储方式，而不是给该人群贴标签。
例如，一份旧活动报名表里如果大量号码在表格中被保存为数值，前导字符和加号可能已经丢失。此时空头像与客户意愿无关，问题发生在导入环节。反过来，如果号码规范、开通状态明确，但头像仍不可见，就应把它视为头像观察边界。
爱普筛结果应该怎样进入CRM
爱普筛WhatsApp号码筛选中的WS筛头像对应字段为手机号、商业号、头像和WhatsApp映射手机号。业务团队上传一行一个号码的TXT，任务完成后导出Excel。为了避免错位，内部最好先为每一行生成batch_row或contact_id，再把结果导入staging表复核，而不是直接覆盖CRM主表。
CRM可以保存avatar_observed、checked_at和mapping_review等状态，但不建议把头像URL当作永久客户资料。头像可能更新，可见性也可能变化。商业号字段表示检查时观察到的账号类型，不代表该企业已经通过你的供应商审核，更不能替代合同、公司注册信息或付款记录。
新西兰隐私规则为何会影响头像使用
新西兰隐私专员办公室在其社交媒体照片收集说明中提醒企业：收集信息应与业务职能相关、确有必要，并在可行时直接从本人取得；公开可见不等于可以脱离目的无限保存和再利用。自2026年5月起，Privacy Act 2020新增的IPP 3A还涉及从本人以外来源间接收集个人信息时的通知义务，具体规则可查看新西兰隐私原则。
因此，筛头像适合用来发现数据问题、检查账号资料可见性或辅助人工核对，不适合自动推断族裔、健康、收入、宗教或政治倾向。若进一步对面部进行自动识别或分类，还可能进入新西兰生物识别处理规则的范围；普通头像可见性观察与生物识别不能混为一谈。
什么样的交付才真正有用
一份可复核的结果不应该只给“有头像/没头像”两个数字。它至少要告诉使用者：这批号码从哪里来、多少行成功规范化、多少行属于格式异常、头像字段有多少已观察和未知、映射冲突如何处理，以及检查发生在什么日期。
什么时候没有必要再次筛头像
如果业务只是发送已经约定的订单通知，且联系人和许可都仍然有效，头像变化通常不会改变执行决定；如果上一轮结果已经显示号码格式异常，应先修复来源而不是重复检查；如果团队无法说明头像字段会支持哪个具体的数据质量问题，也不应为了“补全资料”周期性重跑。
再次检查应由可说明的事件触发，例如供应商联系人交接、映射冲突需要复核，或某个采集渠道出现异常高的未知比例。把触发原因写进batch_note，后续才能区分例行监控和真正的问题调查。
这样，当下一批新西兰名单的头像覆盖发生变化时，团队能够判断变化来自渠道、号码质量还是观察条件。最值得保留的不是某张头像，而是对每个判断来源和不确定性的记录。
