本页面提供了创建有效且引人入胜的 RCS Business Messaging 体验的最佳实践，涵盖 技术实现和 对话设计。
技术指南
检查设备的功能
在与用户开始对话之前，请验证用户的设备是否可以接收 RCS 消息。如需确定用户的功能，请发送 功能检查， 并相应地调整智能体的互动方式。仅以用户设备支持的方式与用户互动。如果用户的设备未启用 RCS，请设置通过其他渠道（例如短信）进行通信的后备方法。
遵守消息大小上限
RCS for Business 消息及其包含的媒体文件的大小存在上限。如需了解详情，请参阅 消息大小上限 。
防止发送重复消息
为避免向用户发送重复消息，您的系统必须先确认消息未送达，然后再尝试回退到短信。
请遵循以下最佳实践，以提高系统的可靠性并防止重复消息：
- 将连接池生命周期设置为与 DNS 存留时间 (TTL) 匹配： 使用连接和客户端对象池来重复使用现有连接和客户端对象。为避免在 DNS 更新后使用过时的 IP 地址，请将连接或对象在池中保留的最长时间设置为与 API 的 DNS 存留时间匹配。
- 不要假设连接超时意味着失败： 不要假设连接 超时意味着 RCS for Business 消息未送达。消息可能仍在服务器端处理。
- 验证递送回执： 在触发后备消息之前，请务必检查递送回执。
- 将 TTL 与连接超时匹配： 尽可能将消息 TTL 设置为与连接超时匹配。
- 在回退之前撤消消息： 在发送 回退短信之前，请务必尝试撤消原始消息。如果撤消失败，请处理失败，因为这可能表明消息已送达给用户。
- 重试发送消息：如果消息因可重试的错误或
连接超时而失败，请重试发送操作。使用初始
messageID来 防止重复，并 实现指数退避算法 来间隔尝试。
检查是否有重复的收到的消息
在检查和回复用户发来的消息时，请检查 messageId 并验证您是否已收到并回复该消息。
对于分布式系统，有两种发送消息的方式：
- 最多一次：系统发送一次消息，但如果在此过程中出现网络 或通信错误，则可能无法收到消息。
- 至少一次：系统可能会多次发送消息，但即使出现网络或通信错误，也可以收到 消息。
Google Cloud Pub/Sub 使用至少一次 系统。虽然这可能会导致收到重复消息，但通过跟踪 messageId 字符串来消除重复消息非常简单。如果您已收到消息，则可以安全地忽略收到的任何具有相同 messageId 的其他消息。
为所有发送的消息使用唯一 ID
当您的智能体向用户发送消息时，您在 API 调用中添加的 messageId 对于每条消息都必须是唯一的。
如需详细了解如何接收消息，请参阅 处理收到的事件。
请勿使用过时的 IP 地址
您的系统在连接到 RBM API 时必须始终使用正确且最新的 IP 地址。各种编程平台使用默认 DNS 缓存超时，该超时时间可能比 Google 的 DNS TTL 设置长得多，这可能会导致您的系统尝试连接到过期的 IP 地址，从而导致超时。RBM 网域 DNS 缓存 TTL 为 300 秒 。
如需确保您的连接逻辑遵循我们的 300 秒 TTL，请按以下步骤操作。
- 将连接池超时时间与 TTL 匹配： 如果您使用连接或客户端对象池，请将其最长生命周期设置为 300 秒（或更短）。这会强制您的系统在对象刷新时提取新的 IP 地址。
- 确保 DNS 刷新： 确认您的平台或 HTTP 客户端库设置为每 300 秒或更短时间刷新其 DNS 缓存。
- 检查当前 TTL： 我们建议以程序化方式检查 RBM API 网域 TTL，以确保您使用的是正确的最大值。您需要检查与您的部署区域对应的网域：
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort
使用指数退避算法实现重试
在调用任何 API 时，调用可能会因基础架构问题、服务过载、QPS 限制和其他错误而失败。如需从失败的 API 调用中顺利恢复，请使用指数退避算法实现重试。
使用指数退避算法重试时，您的基础架构会自动执行以下操作：
- 识别失败的 API 调用。
- 设置初始等待时长和最大重试次数。
- 暂停等待时长。
- 重试 API 调用。
评估 API 调用响应：
- 如果成功，则继续执行工作流中的下一步。
- 如果失败，则增加等待时长并返回到第 3 步。
- 如果在达到最大重试次数后失败，则进入失败状态。
理想的等待时长和理想的最大重试次数因用例而异。 根据您的基础架构和工作流延迟要求确定这些数字。
使用区域端点优化 API 性能
如需优化 API 性能以获得更好的延迟，请使用离用户区域最近的端点。
下表提供了有关根据用户的电话号码使用哪个区域 RCS for Business 端点的建议。
| 电话号码前缀 | 推荐的端点 | 地理区域 |
|---|---|---|
| +1 | us-rcsbusinessmessaging.googleapis.com | 美洲 |
| +2 | europe-rcsbusinessmessaging.googleapis.com | 欧洲 |
| +3 | europe-rcsbusinessmessaging.googleapis.com | 欧洲 |
| +4 | europe-rcsbusinessmessaging.googleapis.com | 欧洲 |
| +5 | us-rcsbusinessmessaging.googleapis.com | 美洲 |
| +6 | asia-rcsbusinessmessaging.googleapis.com | 亚洲 |
| +7 | europe-rcsbusinessmessaging.googleapis.com | 欧洲 |
| +8 | asia-rcsbusinessmessaging.googleapis.com | 亚洲 |
| +9 | asia-rcsbusinessmessaging.googleapis.com | 亚洲 |
| 默认 | us-rcsbusinessmessaging.googleapis.com | 美洲 |
确定目标端点后，请尽可能将服务器放置在离该端点最近的位置。您可以在 https://www.google.com/about/datacenters/locations/ 页面上查看可用位置的列表。
如需详细了解如何确定智能体的区域，请参阅 创建智能体 文档。
对话界面和用户体验
对话界面，而非应用界面
RCS for Business 智能体非常适合在对话界面中为用户提供高效且具体的任务。设计最佳的智能体可确保互动集中、清晰易懂，并且结构类似于自然对话。
智能体不能依赖应用或网页的可视界面，也不应尝试模仿它。相反，智能体需要依赖精心设计的对话，通过口头提示、建议和良好的错误处理来满足用户的需求。
智能体也不应模仿电话树，或依赖用户使用代表给定操作的数字进行响应的界面。用户应该能够像在对话中与另一个人交流一样，自然地与智能体交流。
发起对话
对话的开始会设定用户对智能体功能的预期。以强烈的语气开始对话：展示智能体的个性，预先加载用户关心的信息，并分享智能体的功能。为用户提供与智能体互动和继续对话的明确选项。
展示智能体的个性：通过问候用户并 介绍您的品牌来设定基调。如果您为智能体创建了角色，例如虚拟助理或数字礼宾，请明确说明它是聊天机器人，而不是真人。您可以将智能体名称设置为与角色匹配。虚拟形象是强化形象的好方法。它可以是您的徽标，但图形卡通风格的角色也很不错。
分享智能体的功能：良好的问候消息可以明确对话提供的内容。它从较高的层面介绍了智能体的功能。它还包括 建议的回复 和 操作 ，以引导用户进入特定路径。使用这些建议来帮助用户浏览对话并了解智能体可以协助完成的任务。
撰写清晰且一致的消息
发送易于用户理解和回复的消息。创建提示用户回复的消息文本。保持一致的风格、格式和节奏，以建立用户信任。
创建消息文本时，请注意以下其他最佳实践：
不要创建死胡同。每条消息都应引导用户执行有意义的下一步操作。
- 如果用户历程中的某个任务包含多个步骤，请使用话语标记来引导用户完成整个过程。
例如，现在…、并且…、明白了！给您…
例如，“好的。您的客户经理将接手后续事宜。”
例如，“太棒了！我想我知道您在找什么。”并 提供指向您网站的链接。
使用表示认可的字词或短语来确认用户的消息。
例如，“好选择！”、“好的”“好的”或“明白了”。
使用用户的姓名（如果已知）或代词“您”直接称呼用户。避免将用户称为“我”，因为这可能会造成混淆。
对于标题和标签，请使用句首字母大写格式，而不是标题格式。
例如，“账号对账单”，而不是“对账单”。
使用缩写，即使对于语气严肃或庄重的智能体也是如此。
例如，“it's”比“it is”更具对话感。
谨慎使用感叹号。
列举内容时应使用顿号，即“A、B 和 C”，而非“A、B、和 C”。
将数字写成数字。
例如，“1、2、3”，而不是“一、二、三”。
使用表情符号时，请确保轻松愉快的语气适合用例。
例如，预订拖车或查询健康检查结果的用户可能没有心情。
按顺序保留消息
如果您按顺序发送多条消息，用户按顺序收到这些消息非常重要。与纯文本消息相比，包含媒体的消息需要更长时间来处理。为确保用户按正确的顺序收到消息，请等到收到消息的 200 OK 响应后再发送序列中的下一条消息。
使用建议的回复和操作创建引人入胜的对话
建议的回复 和 操作 是引导和增强用户对话的强大工具。它们可以跟随消息或复合信息卡，并提供继续或更改对话主题的选项。
建议的回复：通过提供 预定义选项，帮助用户快速回复您的智能体。尽可能使用建议的回复，尤其是在需要特定回复时。
建议的操作：允许您的智能体与设备功能集成， 从而简化致电支持人员或查找位置等任务。
请遵循以下关键注意事项，以创建更具吸引力且更高效的对话：
- 相关性：确保建议与当前对话一致。
- 简洁性：限制建议数量，避免用户不知所措。
- 清晰性：对建议文本使用清晰简洁的语言。
帮助用户
您的智能体应回复用户发来的 HELP 消息，并向他们介绍智能体的功能。根据智能体的功能量身定制的建议回复列表可以将糟糕的用户体验转变为有用的体验。
确保您的徽标和主打图片显示效果良好
- 在徽标周围留出足够的空间，以适应裁剪并保持视觉完整性。
- 避免拉伸或扭曲徽标或主打图片，因为这可能会对品牌认知度产生负面影响。
- 在浅色模式和深色模式下测试徽标 和主打图片，以获得最佳可见性和 美观性。
如需更多资源来帮助您设计徽标或排查问题，请参阅 徽标设计准则。
徽标
- 设计时请考虑圆角方形渲染。RCS for Business 徽标在对话列表、对话界面和对话详情中显示为“圆角方形”，以符合 Google 和行业标准。
- 将徽标居中放置在图片中，以确保品牌元素在裁剪后仍清晰可见。
- 经过验证的智能体会在智能体名称旁边自动显示验证对勾标记。此标记受保护，以防他人冒充，并且无法手动添加。
- 对于背景透明的徽标，请确保在浅色和深色背景下都有足够的对比度，以适应深色模式。如果不确定，请使用纯白色背景。
主打图片
- 使用 45:14 的宽高比，以防止不必要的裁剪。
设计主打图片时，请考虑徽标重叠，以免关键元素被遮盖。
尊重用户不希望收到消息的意愿
维护用户信任意味着尊重用户的通信偏好设置。 当用户表明他们希望停止接收消息时，您的智能体必须尊重他们的选择。这包括理解并适当回应各种选择停用的表达方式，例如所有相关语言中的“STOP”。
请参考您业务所覆盖的国家/地区的相关法律和最佳做法， 了解该如何回应“STOP”及其他强制命令。
例如，请参阅 CTIA 最佳实践。
处理取消订阅和订阅事件
Google 信息提供了内置的取消订阅 和订阅 功能，让用户可以控制自己的对话。当用户选择取消订阅时，您的智能体会收到 UNSUBSCRIBE Webhook 事件。SUBSCRIBE 事件表示用户希望重新与您的智能体互动。
如需详细了解如何处理 取消订阅 和 重新订阅 事件，包括负载详情、业务规则和示例，请参阅 用户生成的事件 文档。
处理选择停用
RCS for Business 平台不提供直接管理用户选择退出列表的方式。您有责任维护自己的数据库，其中包含选择通过取消订阅或其他形式的选择停用方式停止接收消息的用户。
继续对话
如果用户删除了与您的智能体的对话，他们必须通过其他渠道（例如网站选择加入、短信短代码或其他意见征求机制）重新发起联系。这种新的互动表明他们对接收消息的兴趣重新燃起。