看到+7就把号码标成俄罗斯，是哈萨克斯坦WhatsApp名单中最常见也最基础的归属错误。哈萨克斯坦继续与俄罗斯共享全球编号第7区；2026年正式公布的新安排进一步明确两国使用的资源范围。号码清洗器必须识别完整范围，而不是只读国家码。
共享+7不是临时异常
哈萨克斯坦政府在2026年官方说明中指出，相关安排已刊登于ITU第1341号业务公报，+7 0、+7 6和+7 7编号资源分配给哈萨克斯坦。俄罗斯则使用其他约定范围。对数据库而言，这意味着country_code=7永远不足以单独完成国家归属。
归属判断需要读取+7之后的资源
解析流程先保留phone_raw，再分离+7与后续数字，依据带发布日期的范围表生成plan_country_candidate。不要在导入阶段把所有+7统一写成RU；一旦错误国家进入CRM，它还会污染语言、时区、合规路由和统计报表。
为旧数据建立可逆的修复决策树
| 记录情况 | 决定 | 备注 |
|---|---|---|
| 显式+7且属于哈萨克斯坦当前资源 | country_plan=KZ候选 | 不等于当前所在地 |
| 显式+7且属于俄罗斯约定资源 | country_plan=RU候选 | 仍保留来源市场 |
| 范围表未覆盖或长度异常 | unresolved | 不得按名单名称强行归属 |
| CRM已有国家与规划冲突 | review | 保留新旧值和规则版本 |
2026更新应触发差量重算
给每条归属结果保存range_version和attributed_at。当范围安排更新时，只重算受影响的+7前缀记录，并输出before_country、after_country与change_reason。不要覆盖旧值而不留痕，否则无法解释历史报表为何变化。
号码规划国家与业务市场并存
哈萨克斯坦号码持有人可能在俄罗斯、德国或其他国家；俄罗斯号码也可能出现在阿拉木图的业务名单里。建议并存phone_plan_country、source_market、declared_location和preferred_language。只有后面三类证据能回答具体业务情境，不能从+7范围自动推导。
全格式筛选不负责修复国家归属
爱普筛WS全格式可包含手机号、活跃时间、活跃天数、性别、年龄、头像、肤色、头像类型、商业号与WhatsApp映射手机号。它不替代号码规划解析。应当先完成KZ、RU和unresolved分流，再把符合业务用途的移动候选生成TXT批次。
把宽表分成三个权限区域
- 基础号码区：原始值、规范化候选、规划国家、规则版本；
- 时效观察区：活动时间、活跃天数、检查日期和失效日；
- 受限画像区：头像、年龄、性别、肤色、头像类型和商业号，按用途限权访问。
并非每个团队成员都需要访问全部字段。分区也能防止分析人员把规划国家与个人画像混成一个“哈萨克斯坦用户”标签。
映射变化先检查归属是否随之改变
若映射手机号不同，重新解析返回号码所属的+7范围，并把input_plan_country与mapped_plan_country同时展示。跨范围变化可能意味着格式、号码迁移或记录关系需要复核；在确认之前，不自动合并客户，也不继承原号码的许可。
TXT只传规范化候选
TXT一行一个号码，不包含姓名、国家标签、语言或订单。内部manifest保存input_id、raw_hash、plan_candidate和batch_id。Excel回来后先进入staging，只有映射与状态规则通过的记录才写入下游表。
用国家归属混淆矩阵验收规则
抽取已由可靠来源确认的KZ、RU与异常样本，分别检查错误归属、未解决和规则外范围。尤其关注旧系统曾统一标RU的+7 6与+7 7记录。验收目标是降低可解释的归属错误，而不是消灭所有unresolved。
哈萨克斯坦案例提醒团队：国际国家码并不总是一国一码。正确的全格式项目必须把共享区号、资源范围、版本日期和业务来源同时保留下来，才能避免一个早期国家标签把后续所有分析带偏。
