客户支持
中文
2026年6月起：关于WhatsApp用户名与BSUID需知的一切
如果您的业务系统仍将电话号码作为客户身份标识，这一更新将带来破坏性影响！
自2026年6月起，WhatsApp将推出用户名功能，这将改变用户身份识别方式。
随着用户名功能的推出，用户无需分享电话号码即可与企业进行消息往来或通话。这意味着电话号码将不再是唯一标识符，企业将开始接收名为 BSUID（业务范围用户标识）的新标识符。
这看似微小改动...实则影响深远！
若您的CRM系统、聊天机器人及自动化工作流仅依赖电话号码，此变更将破坏客户识别与追踪机制。与此同时，用户名功能让客户能更便捷地发现并联系企业，无需保存号码，隐私性更佳。
本指南将详解变更内容、BSUID运作机制、未做准备的系统风险，以及如何正确升级系统而不过度复杂化。
接下来，让我们了解WhatsApp推出用户名功能的动因。
WhatsApp为何推出用户名功能？
并非所有客户都愿意向每个联系企业公开手机号。WhatsApp正着手解决此问题。
此前，客户通过WhatsApp联系企业时默认需共享电话号码。对注重隐私的用户而言，这始终是个痛点。他们可能只想咨询问题、了解产品或联系客服，却不得不暴露个人号码。
用户名功能应运而生！
通过该更新，用户可创建用户名来替代电话号码与企业沟通。此举赋予用户更多隐私控制权，从一开始就提供更安心的体验。
这项变更同样惠及企业。
WhatsApp不仅为用户推出用户名功能，企业也可采用用户名，使客户更易发现和联系。客户无需知晓或保存企业电话号码，直接搜索用户名即可发起对话。
这降低了沟通门槛，提升企业可发现性，简化客户触达路径。
但更深层的改变在于后台机制： 企业识别客户的方式。
下面我们将解析具体变更内容，以及为何BSUID成为核心要素。
哪些方面将发生变化？
本次更新将改变一个重要环节： 企业如何在WhatsApp上识别客户
用户现在可以选择用户名，并通过它与企业联系而无需分享手机号。因此一旦用户名功能上线，手机号码将不再被自动共享。
取而代之的是，企业将开始收到一个名为 BSUID（业务范围用户ID）的新后台标识符。对于使用云API的企业，这将成为可替代客户手机号用于工作流的新身份层。
简而言之：
过去 → 手机号 = 客户身份
现在 → 手机号或BSUID = 客户身份
现在 → 手机号或BSUID = 客户身份
这才是真正的转变！
如果新用户使用用户名与您的企业发起对话，您可能只会收到BSUID。系统不会自动获取其手机号。
如果您的业务仍需手机号（例如发送OTP），必须在对话中明确请求用户分享。最终决定权在用户手中。
不过，这 并不 意味着手机号会完全消失！
如果您的企业已通过历史对话、其他渠道/平台、广告点击、订单记录、账户注册、CRM数据库或用户先前自愿分享获得客户手机号，仍可使用该号码联系客户（无论用户是否启用用户名功能）。因此本次更新主要改变 新用户发起的对话 的运作方式。
认证消息（验证码/OTP）必须通过手机号发送
还有一个重要限制：认证消息仍需手机号。
仅凭BSUID无法发送OTP或验证码认证消息。若该流程对业务至关重要，您需要明确的方式请求并存储用户手机号。
某些情况下，WhatsApp仍可能与企业共享手机号，例如：
- 用户主动选择分享
- 用户与企业之间存在历史对话
- 企业保存在用户的WhatsApp通讯录中
因此企业现在需要同时支持两种情况：
- 仅通过BSUID识别的客户
- 通过电话号码和BSUID识别的客户
正因如此，这不仅仅是一次产品更新，更是一次系统升级。
接下来，让我们深入了解BSUID本身及其背后的运作机制。
什么是BSUID（业务范围用户标识符）
为支持用户名功能，WhatsApp引入了一种名为 BSUID（业务范围用户标识符）的新标识符。当电话号码不可用时，这将成为企业识别用户的基础方式。
BSUID是 唯一ID 专为特定业务分配的用户标识，旨在建立企业与客户间的安全连接。即使没有用户电话号码，您仍可通过该ID发送消息并追踪用户。
关键点在于：
同一用户对于 不同企业会拥有不同BSUID。
同一用户对于 不同企业会拥有不同BSUID。
这是有意为之的设计。
该机制确保隐私性——企业A无法通过BSUID追踪用户在企业B的活动或交互，每个业务关系都是相互隔离的。
BSUID运作原理
- 由WhatsApp自动生成
- 会出现在webhook有效载荷中（作为user_id）
- 即使缺少电话号码仍可生效
- 与特定业务组合绑定
因此从系统角度看，这就成为您的 新用户标识符，用于传入对话。
BSUID格式（示例）
BSUID遵循固定结构：
- 以用户的ISO 3166 alpha-2 两位字母国家代码开头
- 后接一个 点号（.）
- 然后是一串 唯一字母数字字符串（最长128字符）
Example:
US.13491208655302741918在API中使用时， 必须完整使用该值，不可更改。
任何修改或截断都会导致请求失败。
核心规则须知
- BSUID具有 业务组合-用户对的唯一性 （业务组合曾用名"业务管理器"）
- 当用户 更改电话号码时会重新生成 （将触发系统状态消息webhook）
- 其作用范围 限定于特定业务组合 （不能跨组合使用）
- 即使 用户未设置用户名，仍会出现在webhook中
BSUID的限制
BSUID功能强大，但不能完全替代电话号码。
- 您 无法发送认证类消息（如OTP、验证码） 使用BSUID
- 这些流程仍需电话号码
- 因此如果您的应用场景依赖OTP，必须向用户收集电话号码
观看此视频了解BSUID详情：
接下来我们看看哪些内容不会改变，让您明确稳定的部分。
不变更的内容
虽然本次更新改变了用户识别方式，但WhatsApp大部分核心功能保持不变。根据WhatsApp官方通知，以下特性将维持原状：
消息收发机制
- 消息模板的使用方式不变。
- 各类消息类型支持（文字、图片、视频、文档等）保持不变。
- 消息发送API接口结构基本一致，仅需确保标识符参数兼容BSUID。
- 已通过现有对话获取用户电话号码的企业不会丢失该信息，仍可继续使用这些号码联系客户。
会话计费规则
- 24小时会话窗口机制不变。
- 会话计费方式不变。
- 无论客户使用电话号码还是用户名，计费逻辑保持一致。
其他注意事项
- 电话号码仍是WhatsApp运作的组成部分。
- 若用户未采用用户名，企业将同时收到其电话号码和业务范围标识符。
这意味着企业应将主要精力放在客户识别与数据关联上；核心消息通信能力和业务逻辑将继续照常运作
接下来我们看看企业适应新标识系统时将面临的挑战。
企业面临的挑战
一旦理解了BSUID，真正的问题就变成了：企业如何在这个新框架下继续准确识别客户？
因为从这里开始事情变得棘手。
挑战一：无法直接获取新用户电话号码
当新用户使用用户名联系时，您只会收到一个 BSUID。
默认情况下您无法获取其电话号码。
您仍可使用BSUID进行回复并继续对话。但如果业务需要电话号码（例如OTP或验证），现在您必须 在聊天中明确索取 并等待用户同意。
挑战二：将BSUID与现有客户数据映射
当前大多数CRM系统都以电话号码为核心构建。
- 客户档案
- 聊天记录
- 订单
- 用户分群
所有数据都以电话号码为主键进行关联。
现在引入BSUID后，您需要决定：
- 是将BSUID作为新字段添加？
- 还是创建电话号码与BSUID之间的独立映射层？
这不仅是技术决策，更会影响 数据一致性、查询逻辑和系统复杂度。
挑战三：当客户在不同标识符间切换时保持对话连续性
对用户而言没有任何变化，仍是同一次对话。
但对您的系统而言，可能出现断层。
示例：
- 首次互动 → 通过BSUID识别
- 后续 → 用户分享电话号码
若系统未能正确关联两者，同一用户会被视为 两个不同的客户
后果：
- 重复记录
- 聊天记录断裂
- 糟糕的客户体验
挑战4：验证与OTP流程处理
BSUID不能用于认证消息
因此，若您的流程依赖：
- OTP验证
- 登录验证
- 账户关联
您必须首先 收集用户的电话号码
这意味着您当前的流程可能需要重新设计以：
- 明确请求授权
- 获取号码
- 正确存储并映射
接下来，我们看看如果这些挑战未妥善处理会实际导致哪些问题。
忽视后果（如果您忽略这点）
若不适配BSUID，系统不会显性报错，而是会静默失效
以下是开始出现的问题：
- 您可能会错过对话
通过用户名访问的新用户无法在系统中正确映射。
- 消息流中断
服务消息和CTWA（点击到WhatsApp广告）流程可能无法如期触发。
- 聊天记录断开
同一用户可能显示为多个身份。
- CRM数据不可靠
客户档案可能无法正确存储或映射数据。
- 重复用户增加
一个用户=跨电话号码和BSUID的多条记录。
- 自动化停止工作
基于电话号码的工作流将无法触发。
- 端到端工作流中断
从潜在客户捕获到后续跟进，整个流程开始崩溃。
- 销售团队失去可见性
潜在客户无法被正确识别或追踪。
这就是为什么影响比看起来更大。
这不仅是数据问题，它影响整个客户旅程。
接下来，我们看看如何解决这个问题并正确处理客户识别。
客户识别解决方案
这里没有放之四海皆准的方法。
企业现在需要处理 两种客户识别场景 并为两者构建方案。
场景一：新客户首次通过用户名(BSUID唯一标识)发起联系
当新客户使用用户名发起对话时，您的系统可能仅接收到 BSUID。
此时，BSUID将成为该客户档案的起点标识。
处理方案：
- 您的数据模型需要支持 多标识符关联 同一客户。
- 您的CRM系统应能够 基于BSUID创建客户档案。
- 您的系统需要支持 通过BSUID进行查询识别。
- 若业务需要电话号码（如配送地址验证或发送验证码），应在对话流程中适时索要。
- 若用户提供号码，需将该号码 与原有BSUID档案关联。
场景二：已存有客户电话号码的情况
若贵司已存有客户电话号码，可继续沿用现有方式。
此部分流程保持不变。
即使用户启用了用户名功能，您仍可通过既有号码发送消息。但若该用户后续通过用户名发起对话，系统需能将新获取的 BSUID 与现有电话号码记录关联。
处理方案：
- 您的数据模型仍需支持 客户多标识符关联。
- 当出现BSUID时，需将其关联至现有客户记录。
- 您的系统应支持通过 电话号码或BSUID双向查询。
- 优先考虑 用于外发消息的电话号码，特别是验证或认证流程
目标很简单：
一个客户应始终保持为一个客户，即使他们使用两个标识符出现。
一个客户应始终保持为一个客户，即使他们使用两个标识符出现。
这就是您系统现在需要支持的逻辑。
在上线前，值得在测试环境中验证这些场景，确保边缘情况得到正确处理。
接下来，我们看看实施时间表及各阶段应采取的行动。
时间表与行动计划
WhatsApp正在分阶段推出此功能，只要及早准备，您就有充足时间应对。
时间线
- 2026年3月31日 → BSUID将开始出现在Webhook中。
- 2026年5月 → BSUID测试开放（您可以开始使用BSUID发送消息）。
- 2026年6月 → 测试国家/地区的用户可开始采用用户名。用户名功能开始推广。
- 2026年下半年 → 全球用户可开始采用用户名。
企业应对措施
建议分阶段处理。
准备阶段（当前）
- 学习理解BSUID机制及技术细节。
- 梳理各业务流程中电话号码的使用场景。
- 明确电话号码与BSUID的协同处理方案。
- 评估修改现有系统所需的工作范围和工作量。
- 制定数据库调整和API兼容性计划。
- 开始技术研究和解决方案设计。
- 协调内部团队（产品、工程、营销）并规划您的商业用户名策略。
实施阶段（功能上线前）
- 更新CRM和数据库以支持BSUID。
- 完成API集成层的兼容性改造。
- 实施电话号码授权请求流程。
- 确保验证码消息通过电话号码发送。
- 完成测试环境验证。
- 准备分阶段发布（灰度发布）计划。
测试
- 运行真实场景的端到端测试。
- 验证：
- 基于BSUID的用户创建
- 电话号码收集流程
- 标识符之间的映射
- 消息和自动化流程
上线阶段（功能正式发布后）
- 分阶段推出（不要一次性切换所有功能）。
- 监控系统运行状况，例如资料创建准确性、OTP成功率和工作流性能。
- 处理用户反馈并解决异常情况。
- 优化客户识别逻辑。
- 持续提高数据关联的准确性。
- 监控电话号码授权率，并优化请求的时机和消息内容。
- 认领并设置您的商业用户名。
上线前检查清单
上线前请确保：
- BSUID已集成至各系统。
- 无电话号码仍可收发消息。
- 所有工作流均已针对两种标识符测试。
- 聊天机器人和客户旅程可在需要时请求电话号码。
- 现有工作流已审核更新以避免中断。
优先级划分
- 高优先级 → CRM与数据库结构调整、API兼容性修改、验证码发送逻辑调整（影响核心功能）。
- 中优先级 → 客服系统适配、营销系统更新（影响业务效率）。
- 低优先级 → 数据报表优化、历史数据清理（可逐步完善）。
切勿临时抱佛脚。
越早适配，过渡越顺畅。
更多资源获取途径
实施时请勿依赖假设，务必参考官方文档。
以下是关键入门资源：
- BSUID指南
https://docs.ycloud.com/reference/bsuid
→ 涵盖BSUID工作原理、格式及API用法
- Webhook更新（BSUID字段）
https://docs.ycloud.com/reference/webhook-updates-bsuid
→ 了解BSUID在webhook负载中的呈现方式及集成变更
- Meta开发者文档（BSUID）
https://developers.facebook.com/documentation/business-messaging/whatsapp/business-scoped-user-ids
→ WhatsApp API中BSUID的官方使用参考
这些应作为您更新系统时的首要参考依据。
接下来，让我们快速总结本次更新对您业务的实际影响。
总结！
这并非一次小更新。
它标志着WhatsApp用户识别方式的重大变革。
如果您的系统仅支持电话号码识别，您将面临用户、数据和会话的流失。
立即开始支持BSUID！
术语表
以下是您在webhook和API中会遇到的关键术语的简明解释：
- contacts（新数组）
包含消息相关用户的列表，相当于webhook中的"客户信息板块"。
- profile
用户基础信息（位于contacts数组内）。
- username
新属性。用户的WhatsApp用户名（若用户已设置）。
若用户未设置用户名，该字段不会显示。
- wa_id
新属性。用户的电话号码。
若电话号码可用，将在此处显示。
若用户使用用户名且未共享号码，该字段可能缺失。
- user_id (BSUID)
新属性。未来最重要的字段。
这就是 BSUID，代表您业务场景下用户的唯一标识符。
该字段始终存在，当电话号码不可用时应用此标识用户。
- parent_user_id
一个更高级别的 BSUID，可以跨多个业务组合工作（如果启用）。
大多数企业不会使用此功能，除非他们管理多个业务组合。
简单理解方式：
- wa_id → 电话号码（可能可用也可能不可用）
- user_id → BSUID（始终可用，新的默认值）
- username → 用户公开显示的内容
这些字段将是您的系统在未来识别和跟踪用户所依赖的内容。
Frequently Asked Questions
如果客户使用用户名，企业是否仍能获取他们的电话号码？
默认情况下不会。您将收到一个BSUID来代替。
不过，用户可以选择在对话过程中分享他们的电话号码，某些情况下WhatsApp可能仍会提供该号码。
不过，用户可以选择在对话过程中分享他们的电话号码，某些情况下WhatsApp可能仍会提供该号码。
企业能否继续使用已有的客户电话号码？
是的。如果您已经拥有客户的电话号码，可以继续使用它来发送消息。
此次更新主要影响新用户发起的会话。
此次更新主要影响新用户发起的会话。
认证消息（验证码）可以发送到BSUID吗？
OTP等认证消息必须通过电话号码发送。
在触发此类流程之前，您需要从用户那里收集电话号码。
在触发此类流程之前，您需要从用户那里收集电话号码。
现有客户数据会丢失吗？
不会。您的现有数据保持不变。
引入BSUID是为了支持新的交互方式，而非取代您现有的客户记录。
引入BSUID是为了支持新的交互方式，而非取代您现有的客户记录。
BSUID会影响消息送达率吗？
不，消息传递的工作方式相同。
BSUID仅改变用户识别方式，不影响消息传递机制。
BSUID仅改变用户识别方式，不影响消息传递机制。
更新系统需要多少工作量？
这取决于您现有系统的复杂程度。我们建议先进行全面评估，涵盖影响范围、技术难度和测试工作量，然后再制定详细的时间表和资源计划。中小型企业可能需要1-2名开发人员参与，而大型企业则可能需要跨团队协作。
有哪些重要事项需要了解？
在正式上线前，有几个实际注意事项需要牢记。
OTP和身份验证仍需电话号码
BSUID不能用于验证流程。如果您的使用场景依赖OTP，则必须收集用户的电话号码。
部分用户仍会共享其电话号码
并非所有交互都仅使用BSUID。您的系统应同时处理两种标识符。
通讯录将同时存储两种标识（即将更新）
未来WhatsApp可能会通过联系人历史记录帮助关联电话号码与BSUID。
不再仅依赖电话号码
这是关键转变。您的系统应将BSUID视为核心标识符，而非备用方案。
消费者或企业是否必须采用用户名？
不，用户名将是可选的。
密钥究竟是什么？何时需要提供它们？
设置用户名的用户可选择配置密钥，这为防范不必要的信息提供了额外保护层。来自WhatsApp Business应用的新用户或企业发起联系时，若未预先保存该用户的联系人信息，则需提供密钥。请注意，使用WhatsApp Business Platform的API企业无需知晓用户的用户名密钥，因为BSUID（或电话号码）将验证现有连接并绕过密钥验证。
YCloud 能提供哪些支持？
YCloud 助您完成这一过渡，提供以下支持：
- BSUID 机制技术文档与最佳实践指南
- API 接口兼容性支持与升级方案
- 系统改造技术咨询与实施建议
- 上线过程中的技术支持和问题排查
若您不确定如何适配系统，YCloud 团队可帮助您加速实现。
为何选择YCloud？
YCloud是您能找到的最佳BSP服务商
- YCloud是Meta官方认证BSP
- 极具竞争力的会话价格
- 集营销、销售与客服于一体的全功能平台，免费入驻
- 免费客户支持服务
相关文章
让您的商务沟通更简单！
已加入
